Amazon detectou exploração do PHP2Shell quatro dias antes da divulgação
A Amazon Threat Intelligence registrou tentativa contra o PHP2Shell em 17 de outubro no MadPot, quatro dias antes dos CVEs e dos patches públicos.
Foto: Rafael Minguet Delgado (Pexels)
A Amazon Threat Intelligence identificou uma tentativa de exploração do PHP2Shell em 17 de outubro de 2026 na telemetria do MadPot, a rede de honeypots da empresa, quatro dias antes da divulgação pública das falhas CVE-2026-109618 e CVE-2026-109619. O acesso partiu de um endereço de IP ligado a uma rede comercial de anonimização.
O embargo técnico estava previsto para cair em 21 de outubro às 14h UTC. No mesmo dia, provas de conceito e novas tentativas surgiram horas antes do patch oficial — e, depois do aviso, a exploração passou a ser ampla. A Cloudflare relatou milhões de tentativas e a Amazon recomenda investigar atividade suspeita a partir de 17 de outubro, não só a partir da data do aviso.
O que aconteceu
Segundo o AWS Security Blog, assinado pelo diretor de segurança da informação (CISO) da Amazon Integrated Security, CJ Moses, a tentativa de 17 de outubro ocorreu enquanto a vulnerabilidade ainda estava sob embargo. O fato de um honeypot ter sido alvo a partir de IP anonimizado sugere ação de um ator de ameaça, embora continue sem resposta clara como esse ator obteve informação sobre o exploit antes da divulgação.
Em 21 de outubro, a Amazon Threat Intelligence detectou várias provas de conceito, a mais cedo por volta das 2h UTC — cerca de 12 horas antes da liberação do embargo às 14h UTC. Entre 2h e 8h UTC, houve novas tentativas contra o MadPot a partir de outras infraestruturas anonimizadas, com cargas úteis e escolhas de anonimização distintas, o que aponta para vários atores, e não para um único grupo. A análise técnica segue em andamento, e não está claro se alguma dessas tentativas teria funcionado em sistemas reais.
Após o fim do embargo e a publicação do patch, novas provas de conceito apareceram em poucas horas e foram usadas quase de imediato contra os sensores da Amazon. O PHP2Shell, segundo a empresa, já está sendo explorado de forma ampla na internet. As falhas afetam o próprio interpretador PHP — não um plugin isolado — e, conforme a cobertura do The Register, carregam nota crítica de severidade 9,2, com risco de execução remota de código sem autenticação.
A Cloudflare registrou milhares de tentativas nas dez horas anteriores ao anúncio público, dezenas de milhares em 45 minutos, centenas de milhares em duas horas e, depois, milhões. A empresa também viu atacantes ajustarem cargas úteis para tentar contornar proteções de firewall de aplicação web (WAF). A Hadrian alertou em 21 de outubro que a exploração em escala já ocorria, em grande parte via o caminho de progresso de upload de sessão do PHP.
A Amazon afirma que seu sistema interno de inteligência de ameaças detectou e restringiu varreduras maliciosas ligadas à falha, analisando mais de 200 bilhões de eventos por minuto e integrando dados do MadPot. A remediação completa, diz a empresa, é atualizar para as versões corrigidas do PHP — não há solução só por configuração que cubra os dois CVEs. Enquanto isso, recomenda avaliar o bloqueio de uploads multipart, buscar requisições POST com a string PHP_SESSION_UPLOAD_PROGRESS, revisar logs e procurar execução inesperada de processos ou alteração de arquivos em servidores web.
O que isso pode mudar
O episódio pode reforçar a ideia de que a data pública do aviso não é o ponto zero da exploração. Embargos protegem defensores só até alguém achar o mesmo bug; com o PHP2Shell, a Amazon sugere que a comprometimento pode ter começado antes do advisory. Isso pode empurrar líderes de segurança a medir janelas de patch e mitigação em horas, e não em SLAs de sete ou 30 dias, sobretudo em sistemas expostos à internet.
A empresa também aponta que a análise assistida por inteligência artificial (IA) barateia transformar o diff de um patch ou um aviso técnico em exploit funcional, o que poderia encolher ainda mais o intervalo entre divulgação e ataque em massa. Investigações a partir de 17 de outubro e detecções que não dependam só de assinatura de um CVE específico podem se tornar prática padrão. Se a curva observada pela Cloudflare se repetir em falhas críticas do runtime, a pressão sobre administradores e fornecedores de WAF tende a crescer nas primeiras horas — e a confiança no calendário coordenado de divulgação pode ser revista com mais ceticismo.
Fontes: AWS Security Blog; The Register
Leia mais em: mundodosnegocio.com.br