A IA achou duas falhas críticas no PHP antes dos atacantes. Agora a janela depende do seu processo de patch

A frase mais importante do aviso de segurança do PHP desta semana é uma só: não existe mitigação completa, e atualizar é a única opção segura.

Em 21 de outubro, o projeto PHP lançou as versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir duas vulnerabilidades críticas, a CVE-2026-109618 e a CVE-2026-109619, com nota 9,2 no CVSS v4.0. Nas condições certas, as duas permitem que um atacante sem autenticação execute código no servidor. Elas estão no próprio runtime do PHP, então atingem toda aplicação construída sobre ele: sites em WordPress, Drupal e Joomla, ferramentas internas, portais de clientes e o PHP que roda dentro de produtos de fornecedores que ninguém lembra de ter comprado.

Elas foram encontradas com IA de fronteira. É essa a parte da história que vai se repetir.

O que aconteceu

As duas falhas são disparadas quando uma requisição faz o PHP falhar no meio do caminho, por exemplo ao estourar o limite de memória ou causar um erro fatal, e dependem de uma requisição seguinte reaproveitar o mesmo worker. O PHP diz que toda instalação que atende requisições web está em risco, incluindo PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed, com o maior risco no mod_php. A Wiz, que publicou sua pesquisa no mesmo dia, afirma que quase toda versão desde o PHP 5.4 tem pelo menos um dos problemas e relata cadeias de exploração sem autenticação contra WordPress, Drupal e Joomla.

A descoberta envolveu vários participantes. Segundo a PHP Foundation, a Calif, empresa de segurança que trabalha no programa Patch the Planet da OpenAI, reportou a causa raiz em 11 de agosto usando o GPT-5.6 Sol, e a OpenAI e a Wiz reportaram outros caminhos de ataque nas semanas seguintes. A Wiz diz que encontrou as duas falhas de forma independente, com seu agente Wiz Atlas, o Gemini 4 Argon e o GPT-5.6 Sol. A Foundation também escreve, com uma franqueza pouco comum, que a causa raiz já tinha aparecido numa auditoria de 2024 e que a correção ficou “parada por meses” por causa de “uma falha estrutural” no seu processo de decisão e de recursos.

A janela foi menor do que o planejado

A OpenAI apresenta o caso como uma IA de fronteira que encontrou as falhas antes dos atacantes, abrindo o que ela chama de janela do defensor. A janela existiu, e fechou antes da hora:

• Os detalhes começaram a vazar por volta das 15h UTC de 20 de outubro, segundo a Foundation, que antecipou o lançamento em um dia, para as 14h UTC de 21 de outubro.
• Um fornecedor de imagens de contêiner publicou imagens com a correção mais de seis horas antes do lançamento coordenado, o que entregou o patch aos atacantes em formato binário.
• A Cloudflare, que colocou regras de web application firewall no ar cerca de nove horas antes da divulgação, diz que depois observou tráfego de ataque contra seus clientes, com payloads sendo modificados para driblar as regras.

A Foundation não registrava exploits funcionais no momento do lançamento, e a OpenAI diz não saber de nenhum atacante que tenha encontrado as falhas antes. As duas afirmações eram verdadeiras quando foram feitas. Nenhuma delas é motivo para esperar. A avaliação da Wiz é a que deve orientar o plano: essas cadeias de exploração são complexas, e os modelos de fronteira “reduziram substancialmente essa barreira”.

O que não conta como correção

Atualizar o WordPress ou os plugins. A falha está abaixo da aplicação. A Cloudflare é explícita: atualizar o código do site ou os plugins não resolve. Se o PHP é gerenciado por um provedor de hospedagem, é o provedor que precisa atualizar o runtime.

Uma regra de WAF. Regras de firewall da Cloudflare e de outros compram tempo, e os atacantes já estão trabalhando para contorná-las. O PHP lista mudanças de configuração provisórias para quem não consegue atualizar na hora, e diz claramente que elas reduzem a exposição sem tornar a instalação segura.

Uma versão sem suporte. O PHP 8.1 e anteriores não recebem correções oficiais. O time de segurança do PHP publicou backports mínimos de código-fonte para as versões 7.4, 8.0 e 8.1, para quem compila a partir do fonte, e algumas distribuições Linux fazem backport das correções, mas a resposta padrão para esses sistemas é migrar de versão. O PHP 8.2 chega ao fim de vida em 31 de dezembro de 2026.

O que fazer hoje

1. Encontre cada runtime de PHP, não cada site. O inventário que importa é o de runtimes: servidores, contêineres, imagens base, plataformas hospedadas e appliances. Sites de marketing e intranets antigas são os pontos cegos de sempre.
2. Atualize primeiro o que está exposto à internet. Priorize pela exposição e, depois, pelo que o sistema alcança se for comprometido.
3. Reconstrua as imagens, não só os hosts. Um contêiner gerado no mês passado a partir de uma imagem base sem correção continua vulnerável depois que o host é atualizado.
4. Peça confirmação por escrito aos fornecedores. Empresas de hospedagem, fornecedores de SaaS e fabricantes de appliances que rodam PHP devem confirmar a versão que usam agora e quando atualizaram.
5. Procure sinais de tentativas. A Wiz aponta requisições multipart incomuns seguidas de erros de limite de memória, respostas HTTP 500 repetidas, cookies PHPSESSID malformados e reinícios de workers sem explicação. Os logs da aplicação podem mostrar pouco, porque as falhas rodam abaixo dela.

A OpenAI publicou um verificador de versões do PHP como uma skill do Codex para ajudar a identificar versões expostas. É uma conveniência. A lista oficial de versões corrigidas é a do PHP.

Por que isso vai acontecer de novo

A OpenAI escreve que essas falhas “estão entre várias vulnerabilidades significativas que já encontramos e estamos trabalhando para corrigir”, e que espera que achados parecidos “aumentem muito nos próximos meses”. Leve isso ao pé da letra. Quando a IA barateia encontrar e explorar falhas em código antigo e muito usado, o gargalo passa para o lado dos defensores: os mantenedores voluntários, como o próprio relato do PHP mostra, e o pipeline de patch de cada empresa.

Já argumentamos que a capacidade de verificação, e não a de geração, define o ritmo da IA em produção. A segurança agora tem o mesmo formato: a descoberta acelera, e a etapa lenta é confirmar, corrigir e implantar. E processos de patch pensados para ciclos mensais são mais um exemplo de sistemas dimensionados para o ritmo humano. A pergunta para todo líder de segurança depois desta semana não é se o time consegue atualizar o PHP. É quantos dias o próximo patch de emergência de um runtime fundamental leva, de ponta a ponta, e quem é dono de reduzir esse número.