Amazon viu tentativas de ataque ao PHP2Shell quatro dias antes da divulgação

Alguém tentou explorar o PHP2Shell quatro dias antes de a maioria dos defensores saber que ele existia. Segundo a Amazon, sua rede de honeypots MadPot registrou uma tentativa contra as duas falhas do PHP em 17 de outubro de 2026. As correções e a divulgação pública só chegaram em 21 de outubro, às 14h UTC. A Amazon agora diz que as falhas estão sendo exploradas em larga escala.

O PHP corrigiu as duas falhas, CVE-2026-109618 e CVE-2026-109619, no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 na quarta-feira. As duas têm nota 9.2 e podem permitir que um atacante execute código em um servidor web sem fazer login. Pela linha do tempo da Amazon, um servidor corrigido na quarta-feira pode ter sido atacado antes disso.

O que a Amazon viu

O MadPot é a rede de honeypots da Amazon, servidores-isca criados para atrair atacantes e registrar o que eles fazem. No post do AWS Security Blog, a Amazon detalha o que seus sensores registraram.

Horário (UTC)	O que aconteceu
17 de outubro	O MadPot registra a primeira tentativa, de um endereço ligado a uma rede comercial de anonimização
20 de outubro	Os números CVE circulam no Hacker News e nas redes sociais, segundo a Tenable
21 de outubro, por volta das 02h	Surge o primeiro exploit de prova de conceito, cerca de 12 horas antes das correções
21 de outubro, das 02h às 08h	Chegam mais tentativas de outra infraestrutura anonimizada
21 de outubro, 14h	O embargo termina e as correções são publicadas

As tentativas de 21 de outubro usaram cargas e infraestruturas variadas, o que, segundo a Amazon, sugere mais de um atacante. Depois da publicação, novos exploits surgiram em poucas horas e chegaram aos sensores da Amazon quase de imediato.

A Amazon é cautelosa sobre o que não sabe. Seus sensores são iscas, então ela não pode dizer se as primeiras tentativas teriam funcionado em sistemas reais. A Amazon também escreve que "continua incerto como o agente obteve informações do exploit antes da divulgação". A tentativa de 17 de outubro aconteceu três dias antes do vazamento dos números CVE.

Como o embargo desmoronou

Um embargo é o período discreto em que um projeto e seus parceiros preparam correções antes de anunciar uma falha. O embargo do PHP2Shell não se sustentou.

Segundo a Tenable e o The Hacker News, a PHP Foundation planejou primeiro o lançamento para 22 de outubro. Ela antecipou a data em um dia depois que os números CVE vazaram. O The Register informa que a fundação também acusou a Chainguard, que publica imagens de contêiner, de lançar builds corrigidos antes do prazo combinado. "Qualquer atacante podia agora estudar a correção em forma binária enquanto todos os outros usuários do PHP ainda esperavam o lançamento", disse a fundação, segundo o The Hacker News. As reportagens não trazem uma resposta da Chainguard.

O tamanho da onda de ataques

Matthew Prince, CEO da Cloudflare, publicou números no X. A Cloudflare viu milhares de tentativas nas 10 horas antes do anúncio. O número subiu para dezenas de milhares nos 45 minutos seguintes e para centenas de milhares em duas horas. Prince agora fala em "milhões".

A empresa de hospedagem Pantheon bloqueou mais de 60.000 requisições suspeitas, informa o The Hacker News. A Cloudflare diz que os atacantes mudam suas cargas o tempo todo para escapar das regras do firewall. Nenhum desses números confirma uma invasão bem-sucedida. Eles mostram tentativas bloqueadas ou registradas.

O The Hacker News cita CJ Moses, CISO da Amazon Integrated Security, sobre por que isso continua acontecendo: "A análise com ajuda de IA torna mais barato transformar o diff de um patch ou um alerta em um exploit que funciona."

O que isso significa para desenvolvedores

Se você roda PHP, sua investigação começa em 17 de outubro, não no dia em que aplicou o patch. A Amazon diz isso com clareza: "Comece as investigações a partir da exploração mais antiga conhecida, não da data de divulgação."

• Aplique o patch primeiro. Instale 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinicie cada worker do PHP para que o código novo rode de fato. Segundo a Amazon, só a atualização corrige totalmente as duas falhas.
• Procure o padrão conhecido nos seus logs. A Amazon recomenda buscar requisições POST que contenham a string PHP_SESSION_UPLOAD_PROGRESS em envios de formulário. A empresa de segurança Hadrian diz que a maioria dos ataques que observa abusa desse caminho de progresso de upload das sessões.
• Procure sinais de que algum código rodou. Verifique os servidores em busca de processos inesperados e arquivos alterados. O FBI recomenda observar processos do PHP que abrem shells de comando ou baixam arquivos.
• Use soluções paliativas só enquanto atualiza. A lista do próprio PHP inclui a configuração session.upload_progress.enabled=0 e reiniciar os workers. A Amazon também sugere bloquear uploads de arquivos multipart se o seu aplicativo puder viver sem eles.
• Não confie em código de exploit público. A JFrog relata exploits falsos do PHP2Shell e malware de brincadeira no GitHub. A Tenable alerta que o código em circulação pode esconder malware.
• Investigue os endereços IP divulgados, mas não confie só em bloqueá-los. A Amazon publica seis deles, mas recomenda investigar em vez de bloquear, porque pertencem a serviços de anonimização compartilhados.