Falha crítica no núcleo do PHP, achada com IA, afeta 70% dos sites da web

Duas equipes, dois modelos de IA, a mesma falha grave

Em agosto de 2026, o pesquisador Ryan Austin, da empresa de segurança Calif, encontrou duas vulnerabilidades graves no motor do PHP usando o modelo GPT-5.6 Sol, dentro do programa Patch the Planet da OpenAI. Quase ao mesmo tempo, a Wiz (comprada recentemente pelo Google Cloud) chegou às mesmas falhas por outro caminho: combinando o Gemini 4 Argon, o próprio GPT-5.6 Sol e uma ferramenta interna chamada Wiz Atlas.

As falhas receberam o apelido de PHP2Shell e dois identificadores oficiais: CVE-2026-109618 e CVE-2026-109619. O detalhe que importa para quem mantém código em produção é onde o problema mora: não é um plugin de WordPress nem uma falha de autenticação de alguma aplicação específica. É o próprio motor do PHP, na forma como ele trata condições de falta de memória e erros fatais.

O defeito está no motor, não na sua aplicação

Isso muda a gravidade do problema. Uma falha em um plugin afeta quem usa aquele plugin. Uma falha no motor da linguagem afeta qualquer coisa escrita em cima dela, de WordPress e Drupal a sistema interno feito sob medida. Os pesquisadores demonstraram execução remota de código sem autenticação contra WordPress, Drupal e Joomla, além de vazamento de memória remoto que foi comparado ao Heartbleed, a falha de 2014 que expunha dados sensíveis direto da memória de servidores.

Vale a ressalva que a própria cobertura da Latent Space faz: os exemplos demonstrados são contra essas três plataformas específicas. Isso não significa automaticamente que toda instalação de PHP do planeta tem o mesmo caminho de exploração idêntico e imediatamente disponível. O risco é real e amplo, mas a extensão exata depende de versão, configuração e exposição de cada ambiente.

Como cada lado chegou lá

A OpenAI também credita o acesso aos modelos ao programa Daybreak for Frontline Defenders, um subsídio de US$ 1 bilhão para dar a pesquisadores de segurança acesso a modelos e produtos de ciber segurança da empresa, anunciado cerca de dois meses antes do caso vir a público. É importante separar as duas coisas: Patch the Planet é a iniciativa de remediação, Daybreak é o mecanismo que dá acesso aos modelos.

Um relatório promocional do Google também afirma que o Gemini 4 Argon achou mais do que o dobro de vulnerabilidades que modelos de base em testes da Wiz, mas o material disponível não traz o conjunto de dados, os parâmetros de comparação nem a taxa de falsos positivos. É uma alegação de fabricante, não um benchmark independente auditável.

Dois meses de bastidor antes do anúncio

A OpenAI descreve cerca de dois meses de trabalho coordenado entre pesquisadores, mantenedores do PHP, provedores de segurança e governos antes da divulgação pública. A Cloudflare implantou regras de WAF (firewall de aplicação web) cobrindo os vetores de ataque conhecidos antes mesmo do lançamento oficial do patch, e liberou essa proteção para todos os clientes, inclusive do plano gratuito.

Segundo relato da própria cobertura do caso, o CTO da empresa resumiu a situação dizendo que as regras cobriam os vetores de ataque conhecidos, estavam disponíveis para todos os clientes (incluindo o plano gratuito) e vinham sendo atualizadas conforme surgiam os primeiros ataques. Ele chamou isso explicitamente de paliativo e orientou os operadores a aplicar o patch às 14h UTC.

O patch oficial foi programado para as 14h UTC (23h no horário do Japão) de 21 de outubro de 2026. A NSA publicou alerta recomendando que operadores se preparassem para atualizar imediatamente e, caso isso não fosse possível a tempo, tirassem o sistema do ar até conseguir aplicar alguma mitigação. A OpenAI publicou depois um repositório com uma skill para o Codex pensada para ajudar times a verificar se seus sites estavam afetados, uma ferramenta de apoio, não um substituto do aviso oficial do mantenedor do PHP.

O que fazer agora, na prática

Para quem administra infraestrutura em PHP, o caminho que faz sentido seguir é:

1. Levantar onde o PHP roda de verdade: hospedagem gerenciada, contêineres, appliances, workers em background e aplicações antigas esquecidas costumam ficar de fora do inventário.
2. Checar a versão exata instalada em cada ambiente, não assumir que está atualizada porque o painel de controle diz isso.
3. Se a atualização imediata não for possível, aplicar mitigação temporária via WAF, sabendo que ela cobre vetores conhecidos, não necessariamente todos os caminhos de exposição.
4. Aplicar o pacote corrigido assim que disponível pelo canal oficial da distribuição usada (não por print de rede social) e reiniciar os processos PHP, não só o servidor web na frente deles.
5. Investigar sinais de exploração anterior separadamente: corrigir a falha não prova que nenhum dado foi acessado antes do patch.

Um script simples de inventário, só para visualizar a escala do problema numa operação com muitos hosts:

# roteiro que eu seguiria para mapear versões de PHP numa lista de hosts
for host in $(cat hosts.txt); do
  echo "== $host =="
  ssh "$host" php -v
done

O material da Latent Space não traz a matriz exata de versões corrigidas nem o commit do patch, então a instrução "atualize para a versão X" só pode vir do aviso oficial da distribuição que você usa (Debian, Ubuntu, Alpine, o pacote da sua hospedagem), não de um resumo de notícia.

O que ainda não está provado

Há um debate aberto sobre se PHP2Shell é realmente do tamanho de Heartbleed ou do log4shell, a falha de 2021 que forçou uma onda parecida de correções emergenciais em sistemas Java. A cobertura da Latent Space trata isso como "objeto de debate", não como fato assentado, e o próprio texto da OpenAI usa a expressão "ao que sabemos" ao afirmar que o modelo achou a falha antes de atacantes, o que não é prova de que nenhum atacante já a conhecia antes.

Também circulou a estatística de que CVEs (identificadores públicos de vulnerabilidade) passaram de cerca de 4.000 por mês para 15.000 desde abril de 2026, citada por uma pesquisadora de segurança no Twitter. O número não tem verificação independente no material disponível, e volume de divulgação não é a mesma coisa que volume de exploração bem sucedida.

O trade-off que fica para quem desenvolve

A ideia mais arriscada que circulou nos bastidores desse caso foi usar a própria falha de execução remota de código para corrigir automaticamente servidores vulneráveis em massa, sem autorização dos donos. Isso não é um plano de remediação válido: mesmo com boa intenção, é acesso não autorizado, risco de causar queda de serviço, aplicar correção errada, destruir evidência de um ataque anterior e gerar responsabilidade civil em múltiplas jurisdições.

O dilema real, levantado por mais de uma pessoa no debate, é que atualizar PHP com muita frequência expõe times a pacotes comprometidos na cadeia de suprimentos, enquanto atrasar a atualização deixa a vulnerabilidade conhecida aberta. Não existe atalho: o time de TI precisa de processo de patch testável e repetível, não de reação a cada manchete de segurança que aparece com IA no meio.

Fonte: Latent Space