Às 14h de ontem, 21 de outubro, o projeto PHP publicou quatro versões novas — 8.5.12, 8.4.27, 8.3.36 e 8.2.35 — e junto um aviso que quase nunca aparece com esse tom: "todos os usuários de PHP são fortemente encorajados a atualizar imediatamente". Não é rotina de terça-feira. São duas falhas críticas que permitem execução remota de código sem autenticação, catalogadas como CVE-2026-109618 e CVE-2026-109619, com nota CVSS 9.2 — e elas afetam todas as versões de PHP lançadas na última década, desde a 5.4.

PHP roda WordPress, Drupal, Joomla, Magento, a MediaWiki da Wikipédia. A Cloudflare estima que ele esteja em cerca de 70% dos sites do mundo. Ou seja: a maior parte da internet herdou, no mesmo dia, a mesma rachadura.

E o detalhe que faz essa história valer um post: quem encontrou as falhas foram modelos de fronteira. A Wiz Research usou Gemini 4 Argon e GPT-5.6 Sol; a Calif chegou ao mesmo defeito de forma independente com GPT-5.6 Sol. A IA achou a agulha — e agora todo mundo precisa decidir se vai tirar o feno do caminho.

A rachadura está no encanamento, não na torneira

O ponto que separa esse caso de "mais um plugin para atualizar": o defeito não está no seu site, está no motor que roda embaixo dele. Você pode ter o WordPress mais atualizado do mundo, com o tema mais enxuto e o plug-in mais cuidadoso, e ainda estar vulnerável se o PHP da máquina estiver na versão errada. A Wiz é explícita: uma aplicação "Hello World" rodando numa versão afetada é tão vulnerável quanto uma loja virtual.

A analogia que eu uso é de prédio. Você troca a fechadura do apartamento, reforça a porta, coloca câmera na entrada. Mas se a estrutura do edifício tem uma viga comprometida, o problema não é do seu apartamento — é do prédio inteiro, e nenhuma fechadura resolve. Aqui o vergalhão é o tratador de erros do PHP, presente desde pelo menos 2012.

Como a falha funciona, sem jargão

Quando uma requisição chega, o PHP reserva memória, processa, e depois limpa tudo. Se no meio do caminho acontece um erro fatal — acabou a memória, estourou o tempo, o cliente desconectou —, o motor não encerra com cuidado: ele simplesmente salta para fora da operação, deixando o que estava pela metade exatamente como estava. Esse mecanismo se chama longjmp, e a Fastly explica bem o problema: ele não avisa as funções em andamento, não dá chance de limpar nada.

O problema é o depois. O mesmo processo worker atende a próxima requisição, encontra esse estado meio-inicializado — ou um ponteiro para memória que já foi liberada — e confia nele como se fosse dado válido. Um atacante que controla o que fica nesse lixo controla o que o PHP vai executar. Duas consequências práticas:

  • Vazamento de memória: dá para ler a memória do processo, que contém senhas, tokens de sessão, chaves de API e certificados — inclusive de outros usuários. A Wiz demonstrou isso numa resposta PHPSESSID, sem precisar executar código.
  • Execução remota: com o vazamento para remover a incerteza de endereço, o ataque sobe para execução de comando. A Wiz demonstrou RCE pré-autenticação em WordPress, Drupal e Joomla, nas imagens Docker mais recentes de cada um.

O detalhe mais cruel está no log. Segundo a Fastly, o único registro deixado é um erro rotineiro de memória — Allowed memory size exhausted ... in Unknown on line 0. "Unknown, linha 0" quer dizer que estourou durante o próprio parse da requisição, antes de qualquer linha do seu código. Times de operação veem isso toda semana e aprenderam a ignorar.

Quem achou: a IA, e o que o anúncio diz

A cronologia, segundo a Wiz: em 19 de agosto a descoberta saiu de um prompt mirando funções do PHP alcançáveis a partir de bases de código populares. Em 20 de agosto o RCE sem autenticação foi confirmado contra Drupal; em 21 de agosto, contra WordPress. Em 24 de agosto o achado foi reportado ao time de segurança do PHP, que reconheceu em 21 de setembro e publicou o patch em 21 de outubro. Sessenta e três dias entre achado e correção.

A Wiz descreve por que isso era impraticável antes: transformar o defeito em exploit exigia encadear vários bugs e se adaptar ao layout de memória de cada alvo, testando e depurando de novo a cada versão. Com modelos, "desenvolver e adaptar exploits funcionais entre múltiplas aplicações em horas" virou rotina. A fala de Raluca Ada Popa, chefe de segurança do Gemini no Google DeepMind, resume o enquadramento oficial: "por mais de uma década essas vulnerabilidades críticas ficaram sem solução porque descobrir e explorar era incrivelmente complexo".

Linha do tempo do disclosure do PHP2Shell, de 19 de agosto a 21 de outubro de 2026
Gráfico: CheriffAI · datas de Wiz Research e PHP.net

A OpenAI foi além do blog e montou a narrativa completa: fala em "janela do defensor" — a IA encontrou antes dos atacantes, o que deu tempo de preparar patch, WAF e orientação —, anunciou US$ 1 bilhão em acesso subsidiado via Daybreak para defensores, e diz esperar que achados parecidos "aumentem abruptamente nos próximos meses".

O que a medição mostra

Aqui é onde a história deixa de ser só boa notícia — e onde vale separar o anúncio do que foi medido.

1. Houve ataque antes do patch. A Fastly afirma que há "evidência de ataques ativos in-the-wild antes da divulgação; estes não são problemas teóricos". Se a janela do defensor existiu, ela não foi suficiente para manter todo mundo fora.

2. O segredo vazou. A Cloudflare registra que "a vulnerabilidade vazou antes da data oficial de lançamento" e que observou tráfego de ataque contra seus clientes, com atacantes "mutando o payload para tentar burlar nossas proteções". A empresa tinha WAF no ar desde o começo de outubro, cerca de 9 horas antes da divulgação, e passou a proteger automaticamente a partir das 3h02 UTC de 21 de outubro — inclusive plano gratuito. É a prova de que coordenação funciona; é também a prova de que ela não fecha todas as portas.

3. O patch fecha os caminhos conhecidos, não o design. A Fastly é categórica: o zend_bailout chamando longjmp está espalhado por toda a base de código e é alcançável por tráfego HTTP comum. "Corrigir os caminhos específicos que os pesquisadores demonstraram não torna o mecanismo seguro." A recomendação é esperar ataques e variantes novas "nesta semana e na próxima, no mínimo".

4. A mesma capacidade arma os dois lados. O próprio comunicado da OpenAI reconhece: "as mesmas capacidades também podem ajudar atacantes a desenvolver rapidamente ferramentas ofensivas e exploits". Quando adaptar um exploit a uma nova versão de PHP deixa de custar semanas de especialista, a complexidade deixa de ser defesa.

O que fazer agora

Se você tem qualquer coisa rodando PHP em produção, isso não é leitura de fim de semana. O caminho, na ordem:

  1. Descubra a versão. Em servidor com acesso: php -v. Em hospedagem compartilhada, no painel (cPanel, Plesk) ou perguntando ao suporte — você não tem root, e é ele quem atualiza.
  2. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se estiver em 7.4, 8.0 ou 8.1, o projeto publicou backports manuais em source; se estiver abaixo de 7.4, não há patch do PHP — a correção depende do seu fornecedor de pacotes.
  3. Não confunda "atualizei o WordPress" com "atualizei o PHP". A correção é no runtime. Plugin atualizado não fecha essa porta.
  4. Se não dá para atualizar hoje, o PHP lista reduções de exposição — que ele mesmo chama de parciais: memory_limit=-1 via php_admin_value (para remover o gatilho de OOM controlável), session.upload_progress.enabled=0 com reinício de todos os workers, fatal_error_backtraces=0 no 8.5, e post_max_size baixo (8M se não há upload; 32M se há). A Fastly acrescenta pm.max_requests=50 no PHP-FPM para encurtar a janela de corrupção entre requisições.
  5. Ligue o WAF e mantenha ligado mesmo depois de atualizar. As regras da Cloudflare cobrem todos os planos, inclusive o gratuito.
  6. Cace sinal de comprometimento: erros de OOM em "Unknown on line 0", cookies PHPSESSID anormalmente grandes ou malformados, rajadas de segfault em curto intervalo e — o sinal mais forte — worker do Apache/PHP gerando processo de shell.
Painel com CVSS 9.2, 70% dos sites, PHP 5.4+ e as versões corrigidas do PHP
Gráfico: CheriffAI · dados de PHP.net, Wiz Research, Cloudflare e Fastly

O que isso significa para quem tem site no Brasil

O parque brasileiro é exatamente o perfil de risco que a Fastly descreve: muito WordPress em hospedagem compartilhada, agências pequenas cuidando de vários clientes, lojas em WooCommerce com post_max_size generoso para aceitar foto de produto, portais de clínica e escola com upload de documento. Nesses ambientes o PHP costuma estar dois ou três anos atrás da versão atual, porque atualizar dá trabalho e "está funcionando".

Duas consequências concretas. A primeira é técnica: num servidor compartilhado, a falha é multiplicativa — um PHP velho atende dezenas de sites, e todos herdam o risco. A segunda é jurídica. Se o ataque dá execução de código, o próximo passo natural é skimmer em checkout, ou seja, dado de cartão de cliente. Isso traz PCI DSS e, no Brasil, notificação de incidente pela LGPD.

A ação de maior retorno hoje, e a mais barata, é uma pergunta ao seu provedor: qual versão de PHP o meu site está rodando, e ela já foi atualizada para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35? Quem não sabe a resposta está exposto por omissão.

O ponto cego que ninguém vai medir

O que me interessa nesse caso não é a falha — é o que ela revela sobre o custo de ser defensável. Durante uma década, esse defeito ficou parado porque provar que ele era explorável custava mais do que qualquer atacante comum tinha. A IA derrubou esse custo. O efeito não é só "mais falhas encontradas": é que a lista de coisas que pareciam seguras encolhe, e o gargalo passa do achado para o deploy. Achar virou barato; corrigir em 70% da web continua caro.

A frase mais honesta do material todo não é a da janela do defensor. É a da Fastly: as correções refletem apenas os bugs encontrados e explorados até hoje, e a condição arquitetural que os permitiu vai continuar ali depois do patch. Isso vale para PHP e vale para o resto: enquanto a gente mede a IA pelo que ela encontra, o número que importa é quanto tempo leva até o último servidor do mundo receber a correção. Esse número ninguém anunciou.

Fontes