Falha crítica no PHP é explorada em massa horas após divulgação, diz Cloudflare

O que aconteceu

Na quarta-feira (21), desenvolvedores 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) → divulgaram publicamente vulnerabilidades críticas que, segundo a Reuters via Economic Times, estavam escondidas no código da linguagem havia anos. Elas só foram descobertas agora porque foram identificadas com o uso de inteligência artificial↳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 →. Os mantenedores liberaram correções emergenciais no mesmo dia e orientaram todos os usuários a atualizar imediatamente.

A velocidade da exploração chamou atenção. O CEO da Cloudflare, Matthew Prince, publicou em sua conta no X um retrato da escalada de ataques observada na rede da empresa nas horas em torno do anúncio.

Nas 10 horas antes do anúncio público, vimos milhares de tentativas de explorá-la em toda a nossa rede. Isso saltou para dezenas de milhares nos 45 minutos após o anúncio, centenas de milhares dentro de 2 horas, e milhões agora.

In the 10 hours before it was publicly announced, across the network we saw thousands of attempts to exploit it. That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now.Matthew Prince, CEO da Cloudflare

O detalhe que mais interessa a quem opera infraestrutura: as tentativas de exploração já existiam antes da divulgação pública ficar oficial, o que sugere vazamento de informação sobre a falha ou varredura automatizada de patches em repositórios antes do anúncio formal.

Quem já foi atingido

O impacto não ficou restrito a teoria de segurança. Sites de governo na Europa saíram do ar na quarta-feira depois da divulgação, segundo a reportagem. No Japão, a resposta institucional foi rápida e visível:

• O banco Mitsubishi UFJ Financial Group suspendeu temporariamente alguns serviços de internet banking como medida de emergência.
• O Ministério das Finanças do Japão também suspendeu temporariamente conteúdo e serviços de seu site enquanto aplicava medidas de segurança.
• A primeira-ministra japonesa, Sanae Takaichi, pediu publicamente que operadores de sites verifiquem se usam PHP e se preparem para aplicar a correção.

Uma primeira-ministra comentando publicamente sobre uma correção de linguagem de programação é um sinal de escala: a base instalada de PHP sustenta parte relevante da infraestrutura web de bancos, governos e varejo em praticamente todo o mundo, Brasil incluído.

O que a fonte não diz (e por que isso importa)

A reportagem não traz o número de CVE, a lista de versões afetadas nem o número da versão com a correção. Isso é uma lacuna real, não um detalhe menor: sem o CVE, times de segurança não conseguem automatizar a varredura de dependências nem confirmar com precisão se seu ambiente está exposto.

Na prática, isso significa que o primeiro passo de qualquer time que roda PHP em produção hoje não é aplicar um patch específico, mas sim consultar o anúncio oficial da equipe do PHP (php.net) e os changelogs da própria distribuição ou gestor de pacotes (apt, dnf, ou a imagem base do container) para identificar a versão exata liberada.

O que fazer se você roda PHP em produção

Com a informação disponível até agora, a sequência de ações recomendável para quem mantém aplicações PHP em produção é a seguinte:

1. Verificar a versão de PHP em uso em todos os ambientes (produção, staging, CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → e imagens de container versionadas).
2. Checar o anúncio oficial em php.net e aplicar a atualização de segurança assim que ela for identificada para a sua branch de versão.
3. Revisar logs de acesso em busca de padrões anômalos de requisição, já que a Cloudflare registrou exploração ativa em larga escala desde antes do anúncio público.
4. Se usar um WAF ou CDN com regras de mitigação para a falha, habilitar essas regras como camada adicional enquanto o patch é testado e implantado.
5. Priorizar sistemas expostos diretamente à internet (painéis administrativos, APIs públicas, sites institucionais) na fila de atualização.

Em resumo: a urgência aqui não é retórica de fornecedor de segurança. É um caso em que bancos e ministérios de governo já tiraram serviços do ar por precaução, e a telemetria de uma das maiores redes do mundo mostra exploração em massa nas primeiras horas após a divulgação.

O ângulo que fica em aberto

A descoberta da falha via inteligência artificial, mencionada de passagem na reportagem, é um dado que merece acompanhamento à parte: significa que ferramentas de análise automatizada estão encontrando vulnerabilidades que escaparam de anos de revisão humana em um projeto maduro e amplamente auditado como o PHP.

Isso tem duas leituras possíveis para quem desenvolve: de um lado, mais olhos (inclusive artificiais) sobre código legado tende a reduzir o estoque de falhas desconhecidas ao longo do tempo; de outro, a mesma técnica que encontrou a falha para corrigi-la pode ser usada por atacantes para encontrar a próxima antes da divulgação responsável. Nenhuma das fontes disponíveis até agora detalha qual ferramenta ou método de IA foi usado na descoberta, então esse ponto segue como pergunta aberta, não resposta.

Fonte: ET Tech (Índia)