Uma falha no núcleo do PHP foi achada por IA, explorada 4 dias antes do patch e tirou sistemas de governos do ar

Duas vulnerabilidades no núcleo do PHP — CVE-2026-109618 e CVE-2026-109619, ambas de execução remota de código sem autenticação, com nota 9,2 — foram corrigidas em 21 de outubro, nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP roda cerca de 70% dos sites do mundo e as falhas estavam no código havia mais de uma década: quase toda versão é afetada (inclusive a família 5.x) e, segundo a pesquisa que as descobriu, até uma aplicação "Hello World" na versão vulnerável podia ser comprometida — porque o defeito não está no código da aplicação, e sim no interpretador que roda por baixo dela. A descoberta, reportada ao time do PHP em agosto, saiu de modelos de IA de fronteira usados na análise; duas empresas de segurança chegaram às falhas de forma independente.

A reação foi global e imediata. O governo brasileiro emitiu alerta no dia 21 para órgãos públicos atualizarem; a Anatel suspendeu o acesso externo ao SEI, e os TRFs 1, 4 e 6 retiraram sistemas de processos do ar por precaução. Na França, sites de administrações locais ficaram inacessíveis a pedido da agência nacional de cibersegurança; nos EUA, a NSA orientou corrigir ou desligar os sistemas vulneráveis. Até aqui, a fundação responsável pelo PHP afirma não ter conhecimento de execução remota de código bem-sucedida em produção — o que se observou foi tentativa de exploração, não comprometimento confirmado.

Fonte: Wiz · AWS Security Blog · G1

Por que isso importa

O detalhe mais duro saiu no relatório de ameaças da AWS: uma tentativa de exploração foi registrada em 17 de outubro — quatro dias antes do comunicado público — partindo de uma rede comercial de anonimização, e provas de conceito apareceram cerca de 12 horas antes do fim do embargo, de vários atores diferentes. A própria fundação do PHP relatou que detalhes vazaram antes do patch. A conclusão é incômoda e vale além deste caso: o comunicado oficial não marca o início da exploração, e a distância entre o patch e o exploit funcionando está encolhendo. Para o setor regulado, isso quebra o pressuposto de SLA de 7 ou 30 dias para sistemas expostos à internet.

Há uma segunda lição de arquitetura. Nenhuma organização escreveu o PHP — ele veio junto, como componente de terceiro, em portais, sites, intranet, ERP, ambiente de ensino e lojas virtuais. É uma classe de risco de cadeia: a falha mora num pedaço de software compartilhado que não passa pelo code review da sua equipe e não aparece no diff do seu repositório. Quem não sabe exatamente o que roda por baixo das próprias aplicações descobre pelo noticiário.

O que a organização deveria testar e monitorar

• Inventário de componentes expostos: quais versões de runtime e bibliotecas estão publicadas na internet, quem mantém e quando foi a última atualização.
• Tempo real de remediação de sistemas voltados à internet, medido em horas — não em dias.
• Logs de servidor web e trilha de acesso: requisições POST com o campo de progresso de upload de sessão, criação inesperada de arquivos executáveis e processos novos em servidores de aplicação.
• Janela de investigação retroativa: começar pelas datas mais antigas de exploração conhecidas, não pela data do comunicado.
• Detecções que não dependam de assinatura de CVE específico — as primeiras tentativas costumam vir antes delas.
• Validação de que os controles de borda realmente bloqueiam, e não apenas existem no desenho.

Esse é o padrão do setor que vale acompanhar: a superfície de risco muitas vezes não está no que a empresa construiu, mas no que ela herdou.