PHP2Shell: falhas críticas no core do PHP encontradas por IA afetam WordPress, Drupal e Joomla

Duas organizações de segurança diferentes, usando modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → diferentes, chegaram à mesma descoberta alarmante no mesmo período: o interpretador do PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) →, a linguagem que sustenta a maior parte dos CMS usados no Brasil (WordPress, Drupal, Joomla, e boa parte do e-commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → nacional), tinha duas falhas graves escondidas no tratamento de erros fatais e condições de falta de memória. Não em um plugin, não na lógica de autenticação de uma aplicação específica: no próprio motor que interpreta o código PHP. É esse detalhe que torna o caso, batizado de PHP2Shell, diferente da enxurrada normal de CVEs de WordPress.

A descoberta foi relatada pelo Latent Space, no boletim AINews, reunindo posts de pesquisadores, da OpenAI e da Cloudflare entre 20 e 21 de outubro de 2026. O quadro que emerge já tem patch publicado (a versão corrigida saiu ontem, 21 de outubro), mas ainda carrega lacunas importantes que vale conhecer antes de tratar o caso como mais um log4shell.

O que é o PHP2Shell, de fato

As falhas receberam os identificadores CVE-2026-109618 e CVE-2026-109619. Segundo a descrição técnica reportada pelos pesquisadores, os bugs ficam no modo como o PHP lida internamente com erros fatais e condições de out-of-memory, não em código de aplicação. Isso significa que o problema não é "um plugin mal escrito": é o chão sobre o qual WordPress, Drupal, Joomla e qualquer outra aplicação PHP são construídos.

Os pesquisadores demonstraram dois cenários de exploração:

• RCE pré-autenticação (execução remota de código sem precisar de login) contra WordPress, Drupal e Joomla, os três CMS mais usados em sites PHP no mundo.
• Vazamento remoto de memória, no estilo do histórico Heartbleed, afetando potencialmente qualquer aplicação PHP, não só os três CMS citados.

Vale separar o que foi demonstrado do que foi generalizado: a execução remota de código foi mostrada contra os três CMS específicos. O vazamento de memória é uma alegação mais ampla dos pesquisadores, sobre qualquer app PHP, mas isso não equivale a dizer que todo deployment tem exatamente o mesmo caminho de exploração, pronto para ser usado.

Duas equipes, dois caminhos, a mesma falha

A parte mais interessante do caso, para quem acompanha segurança aplicada a IA, é que duas organizações encontraram os mesmos bugs de forma independente, dentro da mesma janela de tempo:

A OpenAI descreve o Patch the Planet como uma iniciativa de hardening em larga escala, viabilizada pelo programa Daybreak for Frontline Defenders, um subsídio de US$ 1 bilhão em acesso a modelos e produtos de ciberdefesa anunciado cerca de dois meses antes. É importante não confundir os dois nomes: Daybreak é o mecanismo de acesso aos modelos; Patch the Planet é a iniciativa de remediação que usou esse acesso.

Do lado do Google, a empresa divulgou que, em testes da Wiz, o Gemini 4 Argon encontrou mais que o dobro de vulnerabilidades em comparação com modelos de referência. É um número de marketing: o material consultado não expõe o conjunto de dados, os limites de orçamento computacional nem a contabilidade de falsos positivos por trás dessa comparação, então não dá para tratar como avaliação independente.

Os dois meses até o patch

Segundo relatos de pesquisadores da OpenAI, incluindo Eric Wallace e Greg Brockman, o trabalho de remediação levou cerca de dois meses, com notificação confidencial antecipada a governos e agências externas antes da divulgação pública. Um pesquisador envolvido afirma ter trabalhado diretamente com a PHP Foundation para reforçar o patch, que exigiu uma mudança significativa no próprio motor do PHP, não um ajuste cosmético.

A Cloudflare implantou mitigações no seu WAF antes mesmo do lançamento oficial do patch, cobrindo os vetores de exploração já conhecidos e disponibilizando isso para todos os clientes, incluindo o plano gratuito. O CTO da empresa foi explícito ao classificar essas regras como paliativo, não solução, e orientou os operadores a aplicarem o patch definitivo às 14h UTC do dia 21 de outubro (23h no horário do Japão, mesma janela citada em avisos em japonês para operadores se prepararem).

A NSA, por sua vez, recomendou atualização imediata e, para quem não conseguisse mitigar a tempo, considerar tirar sistemas do ar temporariamente. É um conselho condicional: antes de desligar qualquer coisa, o que importa é checar versão afetada, exposição real e mitigações disponíveis, não o tom alarmista de um post específico sobre o caso.

Modelos avançados encontrando a falha antes dos atacantes dão aos defensores tempo para se preparar.

Advanced models finding a flaw before attackers, giving defenders time to prepare.OpenAI, comunicado sobre o conceito de "Defender's Window"

A própria OpenAI qualificou essa afirmação com a ressalva "to our knowledge" ("até onde sabemos"), o que é relevante: não há como provar que nenhum atacante conhecia a falha antes da divulgação.

O que ainda não se sabe

Antes de tratar o caso como um log4shell confirmado, vale listar o que o material consultado não estabelece:

• A matriz exata de versões afetadas e corrigidas do PHP.
• Os vetores de CVSS (severidade técnica oficial) de cada CVE.
• Se houve vazamento de detalhes antes do patch programado, e o que exatamente vazou.
• A diferença entre exploração bem-sucedida e simples varredura de rede em busca de alvos vulneráveis.
• A causa real de cada instabilidade reportada (uma compilação viral, não confirmada por fonte oficial, menciona cerca de 1,5 milhão de servidores ainda vulneráveis segundo a Censys, além de instabilidades em serviços como Wikipedia e Archive.org, sem confirmação de que o PHP2Shell foi a causa em cada caso).

Esse é o ponto central para quem lê isso em uma redação técnica: divulgação de segurança de alto perfil sempre carrega um pouco de marketing, e o próprio material da fonte original reconhece que o grau de alarme (comparável a log4shell ou Heartbleed) ainda está em debate.

O que muda pra quem mantém PHP no Brasil

O PHP continua sendo a base de boa parte da web construída no país, via hospedagem compartilhada, WordPress corporativo, e-commerces em Magento ou soluções próprias, e sistemas legados de prefeituras e órgãos públicos. Para esse público, o caso traz três lições práticas, independente de quanto do alarme é justificado:

1. WAF não substitui patch. As regras da Cloudflare cobrem vetores conhecidos, mas o próprio fornecedor chamou isso de paliativo. Caminhos alternativos de entrada e a exposição direta da origem continuam existindo.
2. Inventariar onde o PHP roda é o trabalho real. Containers, workers em segundo plano, appliances, aplicações antigas esquecidas: a dificuldade relatada por operadores no material consultado não foi encontrar o patch, foi encontrar todos os lugares onde o PHP está rodando.
3. Ferramentas de verificação existem, mas não substituem o processo. A OpenAI publicou um repositório com uma skill para o Codex que ajuda a checar se um site foi afetado. É um apoio ao diagnóstico, não prova de que o runtime específico já foi corrigido.

A sequência defensável, segundo a reconstrução do próprio material, é: obter o aviso oficial do PHP e da distribuição usada, inventariar runtimes expostos, aplicar proteções temporárias quando justificado, instalar o pacote corrigido vindo de fonte autenticada, verificar o processo que está de fato rodando em produção, e investigar sinais de comprometimento separadamente da correção em si.

O pano de fundo: mais CVEs, mais fadiga de patch

O caso não é isolado. Segundo dados citados no material (não verificados de forma independente aqui), o volume mensal de CVEs publicados teria saltado de cerca de 4 mil para 15 mil desde abril de 2026, coincidindo com o uso cada vez mais comum de IA tanto para encontrar quanto para explorar falhas. Isso alimenta um debate real entre pesquisadores: atualizar com mais frequência expõe times a risco de supply chain (pacotes comprometidos entrando no meio do processo de patch), enquanto atualizar devagar deixa vulnerabilidades conhecidas abertas por mais tempo.

Há também uma disputa de política de acesso entre os grandes laboratórios: a OpenAI concedeu acesso amplo a pesquisadores vetados via Daybreak, enquanto a Anthropic teria restringido por quatro meses o acesso amplo a modelos de classe equivalente para reforçar salvaguardas de cibersegurança antes de liberar. O material consultado não resolve qual abordagem produziu mais valor defensivo líquido; só mostra que o debate está aberto, e que, pelo menos neste episódio, o acesso mais permissivo chegou primeiro ao achado.

Para quem desenvolve e mantém aplicações PHP, a lição que fica não é alarmismo, é operacional: a superfície de ataque do código que já existe está sendo auditada por IA numa escala sem precedente, e isso tende a continuar por pelo menos um ano, segundo a própria leitura da fonte. O trabalho de patchar, inventariar e verificar vai aparecer com mais frequência, goste-se ou não do grau de drama em volta de cada divulgação.

Fonte: Latent Space