⚡ Em uma frase
O PHP corrigiu em 21/10 duas falhas no próprio interpretador que permitem executar código no servidor com uma única requisição, sem login, e a única proteção completa é atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

A equipe de segurança do PHP lançou na quarta-feira (21/10) as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir duas vulnerabilidades críticas que ficaram conhecidas como PHP2Shell: a CVE-2026-109618 e a CVE-2026-109619, ambas com nota 9.2 no CVSS v4.0. As duas permitem execução remota de código sem autenticação, e o problema está no interpretador, não no site: segundo o comunicado oficial, todas as instalações que servem requisições web estão expostas, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.

O risco é maior no mod_php, onde já existe um exploit demonstrado em que uma requisição não autenticada dispara o ataque antes de qualquer código da aplicação rodar. Na prática, um site com código seguro continua vulnerável se o PHP por baixo dele não foi atualizado. Atualizar WordPress, Drupal ou Laravel não resolve: é o pacote do PHP (ou a imagem do contêiner) que precisa mudar, seguido do reinício de todos os processos do PHP.

Três grupos reportaram as falhas de forma independente: a Calif (empresa de pesquisa em segurança), a primeira a avisar o PHP, o Codex Security (agente de segurança da OpenAI, criadora do ChatGPT) e a Wiz Research (braço de pesquisa da Wiz, empresa de segurança em nuvem). Todos relatam ter usado modelos de IA no trabalho. Os detalhes de como cada um usou a ferramenta, e quanto ela pesou, estão mais abaixo.

O que dá errado no PHP

As duas falhas nascem do mesmo ponto: o tratamento de erros fatais, principalmente o de falta de memória (OOM, out of memory). Pelo comunicado do PHP:

  • CVE-2026-109618 (corrupção por falta de memória): o tratamento de OOM pode interromper o PHP enquanto dados internos da requisição estão só parcialmente inicializados, e a limpeza da requisição passa a tratar esses dados inválidos como válidos.
  • CVE-2026-109619 (estado global obsoleto): um estado interno que pertence à requisição sobrevive depois que a memória dele foi liberada, e a requisição seguinte atendida pelo mesmo processo pode usá-lo antes da reinicialização normal.

A Wiz detalha caminhos de ataque como um use-after-free (uso de memória já liberada) no controle de progresso de upload de sessão e um vazamento da memória do processo pelo cookie PHPSESSID, que funciona mesmo quando a aplicação nunca chama session_start(). Os pesquisadores demonstraram execução remota de código sem login contra WordPress, Drupal e Joomla.

Quem está afetado

  • PHP 8.2 a 8.5: vulnerável abaixo de 8.2.35, 8.3.36, 8.4.27 e 8.5.12
  • PHP 7.4, 8.0 e 8.1: afetados, sem versão oficial; a equipe do PHP publicou correções mínimas em código-fonte no GitHub (plataforma de hospedagem de código da Microsoft), para quem compila o próprio PHP, e distribuições e fornecedores de suporte estendido receberam os patches antes
  • PHP 7.3 e anteriores, incluindo o PHP 5: afetados e sem correção, segundo a watchTowr (empresa de cibersegurança); a saída é migrar para um ramo suportado
  • Alcance: a Wiz afirma que todas as versões lançadas na última década têm pelo menos uma das falhas, desde o PHP 5.4; a Unit 42 (equipe de inteligência de ameaças da Palo Alto Networks, empresa de cibersegurança) contou mais de 22,6 milhões de instâncias expostas, segundo a TechTarget (site de notícias de tecnologia para empresas)

Vazamento antes da hora e exploração

A divulgação estava marcada para 22/10, e o PHP chegou a pré-anunciar a correção para 21/10 às 14h UTC. Os detalhes vazaram na internet em 20/10, antes do patch, e a publicação foi antecipada, segundo a watchTowr. A empresa diz ter reproduzido as duas falhas e registrado exploração das duas em sua rede de honeypots (servidores-isca) no próprio dia 21.

A Amazon Threat Intelligence (equipe de inteligência de ameaças da Amazon) foi além: seu honeypot MadPot registrou uma tentativa de exploração em 17/10, quatro dias antes da divulgação, vinda de um IP anonimizado, segundo a Help Net Security (site de notícias de segurança da informação). Como a falha estava sob embargo, não se sabe como o atacante obteve os detalhes.

🚨 Atenção
Atualizar o PHP é a única proteção completa. Para quem não pode atualizar já, o comunicado do PHP lista três medidas paliativas, mas avisa que elas "não tornam a instalação segura":
1. Desligar o progresso de upload de sessão: session.upload_progress.enabled=0.
2. Tirar o limite de memória do próprio PHP (memory_limit=-1) e deixar esse controle com o contêiner ou o cgroup.
3. Reduzir o post_max_size para 8M, ou para 32M se o site recebe uploads.
Essas configurações só têm efeito no php.ini, no pool do PHP-FPM ou na configuração do servidor; por ini_set() ou .user.ini, não valem.
A NSA (Agência de Segurança Nacional dos EUA) foi mais longe: para quem não consegue atualizar, recomendou tirar o site do ar temporariamente, segundo o Washington Post (jornal americano).

De 2024 a outubro: quem achou o quê

O relato da PHP Foundation (organização sem fins lucrativos que financia o desenvolvimento do PHP), publicado no dia da correção, reconstrói a ordem dos fatos:

  • 2024: um desenvolvedor do núcleo do PHP, contratado pela fundação, encontrou os primeiros sinais do problema de falta de memória por trás da CVE-2026-109618, enquanto corrigia outra falha
  • 11/08/2026: Ryan Austin, da Calif, reportou uma execução remota de código com a mesma causa
  • 24/08: a Wiz reportou novos caminhos de ataque
  • 18/09: a OpenAI, que tinha reportado a mesma causa de forma independente, enviou mais caminhos de ataque
  • 21/10: saem as versões corrigidas

A PHP Foundation reconhece que a correção demorou. A equipe desenvolveu várias abordagens concorrentes, cada uma com um custo (quebra de compatibilidade, novo risco de negação de serviço, mudanças em extensões de terceiros), e o trabalho travou e recomeçou ao longo de meses. O texto chama isso de "falha estrutural, causada tanto pelo processo de decisão da equipe de segurança quanto pela falta de recursos".

O que a IA fez, e o que não fez

As três equipes descrevem papéis diferentes para a IA, e a mais modesta é justamente a que chegou primeiro.

Calif. O ponto de partida foi humano: Ryan Austin conhecia uma falha de 2004 no limite de memória do PHP, descoberta por Stefan Esser, e saiu atrás de variantes que tivessem sobrevivido. Ele pediu a um assistente de IA formas de estourar o memory_limit, e um agente revisando o código de alocação e encerramento apontou o problema de ordem que abriu a falha. Depois, a equipe pediu ao modelo que generalizasse o padrão, o que levou a uma segunda falha, no progresso de upload de sessão. A Calif afirma que não usou "nenhum harness especial nem acesso a modelos que não estivessem disponíveis para todos" e que "nenhum modelo é capaz de desenterrar 'todos os bugs' com prompts simples". O trabalho foi feito dentro do Patch the Planet, programa da OpenAI de apoio a mantenedores de código aberto.

Wiz. A Wiz diz ter usado a própria plataforma Wiz Atlas, o Gemini 4 Argon, do Google, e o GPT-5.6 Sol, da OpenAI, e credita aos modelos contribuição na descoberta, no desenvolvimento do exploit, na detecção de ataques e na validação do patch. Onde o relato dela dá mais peso à IA é no ataque: os modelos adaptaram o exploit a versões do PHP, configurações e layouts de memória diferentes, permitindo, segundo a empresa, adaptá-lo "para várias aplicações em horas". A Wiz afirma que provar a exploração exigia "uma cadeia de passos excepcionalmente complexa, no limite do que pesquisadores humanos conseguiriam fazer na prática", e que um pesquisador com IA fez em uma semana o que antes levaria meses de uma equipe de ponta. As duas afirmações são da Wiz, que vende a plataforma usada, e não têm verificação independente.

OpenAI. A empresa diz que o GPT-5.6 Sol ajudou a detectar as falhas e que a IA as encontrou "antes dos atacantes, dando tempo aos defensores para se preparar", segundo a TechTarget. Ao Washington Post, reconheceu que as mesmas capacidades "também podem ajudar atacantes a desenvolver rapidamente ferramentas ofensivas e exploits", e indicou ter achado outras vulnerabilidades importantes, ainda em correção.

PHP. Do lado de quem corrige, a PHP Foundation diz que usa IA para validar relatos e agrupar os que têm a mesma causa, mas que "uma pessoa toma cada decisão e trabalha em cada patch".

Mais relatos, mais trabalho para quem corrige

No mesmo relato sobre a correção, a PHP Foundation aponta outro efeito da pesquisa assistida por IA: o volume. A equipe de segurança do PHP passou a receber muito mais relatos e já descartou mais de 100 que eram inválidos, duplicados ou impossíveis de reproduzir.

O fenômeno não é só do PHP. Em junho, o FIRST (fórum internacional de equipes de resposta a incidentes de segurança) elevou sua previsão para cerca de 66 mil CVEs em 2026 e atribuiu o salto principalmente à IA: "ferramentas de IA começaram a caçar falhas de software por conta própria", segundo a Help Net Security. Como exemplos, o FIRST citou o Mythos, da Anthropic (criadora do Claude), o GPT-5.4-Cyber, da OpenAI, e um sistema assistido por IA da Mozilla (organização sem fins lucrativos que desenvolve o Firefox) que encontrou e corrigiu 271 bugs no navegador. O próprio FIRST ressalva que parte do aumento é administrativa, porque o GitHub e a VulnCheck (empresa de inteligência sobre vulnerabilidades) ampliaram a catalogação e registraram falhas antigas, e que só uma fração pequena das CVEs chega a ser explorada.

No kernel Linux, foram 432 CVEs divulgadas em apenas dois dias de julho, um domingo e uma segunda-feira, segundo a Open Source For You (revista indiana sobre código aberto), e Linus Torvalds (criador do Linux) afirmou que envios gerados por IA deixaram as listas de segurança do kernel "quase impossíveis de administrar".

🎯 O que isso muda

  • Para quem tem site em PHP: a ação é atualizar o PHP do servidor e reiniciar os processos; em hospedagem compartilhada, a versão é escolhida no painel da hospedagem ou depende do provedor aplicar o patch
  • Para quem usa PHP 8.1 ou anterior: não há versão oficial corrigida; o caminho é migrar de ramo ou depender de backport do fornecedor
  • O que observar: a Wiz diz que a causa raiz pede uma correção mais ampla e que existem outras variantes; o PHP já publicou, em 23/10, um aviso sobre um terceiro vetor, a CVE-2026-115560, de exploração considerada improvável, a ser corrigida no próximo ciclo normal

Fontes

PHP — anúncio da versão de segurança e advisory (21/10/2026)
https://www.php.net/archive/2026.php

The PHP Foundation — Today's PHP security release and how we're strengthening PHP security (21/10/2026)
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

Calif — PHP2Shell (consultado em 25/10/2026)
https://calif.io/php2shell/

Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities (21/10/2026)
https://wiz.io/blog/php2shell-php-rce

watchTowr — PHP2Shell RCE Exploited (21/10/2026)
https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/