No dia 21 de outubro, o PHP lançou de uma só vez quatro versões de segurança: 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que corrigem as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas com nota 9.2 no CVSS v4.0. Um atacante remoto, sem precisar estar autenticado, consegue explorá-las, e o pior desfecho é a execução remota de código. No comunicado, o projeto afirma que não existe uma mitigação temporária completa; atualizar é a única correção definitiva.
Quem descobriu o conjunto de falhas foi a empresa de segurança em nuvem Wiz, que deu ao caso o nome de PHP2Shell. Durante a caça às falhas, a equipe de pesquisa da Wiz usou a própria ferramenta Wiz Atlas, além do Gemini 4 Argon, do Google, e do GPT-5.6 Sol, da OpenAI.
O problema está no próprio motor
Por trás dos dois CVEs há quatro defeitos no total: um use-after-free no desserializador de progresso de upload, a leitura remota da memória do processo, um use-after-free no backtrace de erros fatais e uma confusão de tipos (type confusion) no OPcache. A raiz comum está na forma como o PHP trata erros fatais, sobretudo os causados por esgotamento de memória.
Quando uma requisição é encerrada de forma anormal, dados corrompidos permanecem no estado interno; o mesmo processo worker, ao tratar a requisição seguinte, reaproveita esse estado obsoleto, o que provoca vazamento ou corrupção de memória. Mesmo sem executar código, o atacante pode ler senhas, tokens e chaves de API da memória do processo.
A falha está no motor do PHP e não tem relação com o quão seguro é o código da aplicação por cima. A Wiz demonstrou a exploração nas imagens de contêiner mais recentes de WordPress, Drupal e Joomla; até uma página que apenas exibe Hello World pode ser atingida, e o vazamento de memória ocorre mesmo que a aplicação nunca tenha chamado session_start(). A faixa afetada remonta ao PHP 5.4: toda versão lançada na última década cai em pelo menos um dos problemas.
Onde a IA ajudou
A linha do tempo da Wiz: a primeira falha foi encontrada em 19 de agosto, reportada à equipe de segurança do PHP em 24 de agosto, confirmada pelo PHP em 21 de setembro, quando começou a preparação da correção coordenada, e divulgada publicamente em 21 de outubro. Do relatório ao patch no ar passou quase dois meses, a maior parte gasta com correção e coordenação.
Segundo a Wiz, o Argon participou das etapas de descoberta das falhas, escrita de exploits, detecção de ataques e verificação de patches; os grandes modelos ajudaram os pesquisadores a adaptar o código de exploração a diferentes versões do PHP, configurações e layouts de memória e, quando falhavam, analisavam a causa e iteravam. Nas palavras da Wiz:
"Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."
(Os modelos de fronteira reduziram bastante essa barreira, transformando uma falha antiga em um exploit utilizável.)
A Wiz afirma que um único pesquisador fez em uma semana o que antes exigia meses de trabalho de equipes de ponta. A OpenAI também publicou um texto sobre essa divulgação coordenada; reportagens públicas mencionam que ela lançou ainda uma habilidade do Codex para ajudar sites a verificar se são afetados, mas os cenários exatos que ela cobre não podem ser conferidos item a item no momento.
O dilema dos sites antigos na China
Um grande número de sites de pequeno e médio porte, sites corporativos e fóruns na China roda em PHP, muitas vezes em ambientes instalados com um clique por painéis de hospedagem, e não é raro que a versão esteja parada no 7.x. Pela lista oficial de lançamentos, os patches desta vez cobrem apenas quatro ramos, do 8.2 ao 8.5; o 7.x deixou de ter suporte há muito tempo e não recebe correção oficial, e o 8.2 também só é mantido até 31 de dezembro deste ano.
Para os sites que ainda não atualizaram, a Wiz lista alguns sinais para investigação: requisições multipart anômalas seguidas de erro de limite de memória excedido, HTTP 500 recorrente, cookies PHPSESSID anormalmente grandes ou malformados e reinicializações frequentes e anormais dos processos worker do PHP. Cloudflare, Fastly, Google e outros fornecedores já ativaram regras de proteção, de modo que sites atrás de uma CDN conseguem bloquear parte dos ataques, mas a conclusão oficial não muda: o assunto só está resolvido quando o patch é aplicado.
Fontes: comunicado de segurança oficial do PHP, blog de pesquisa da Wiz, CocoLoop, comunicado de segurança da OpenAI; foram verificados os números das versões corrigidas, os identificadores CVE, as notas CVSS v4.0 e o alcance das versões afetadas.