PHP em pânico: falha desde 2004 ameaça 70% da web

70% da web em cima de um código de 2004. E ele quebrou

PHP virou de novo o centro de uma emergência que ninguém queria reviver. A NSA soltou um alerta direto nesta semana falando de duas falhas críticas no PHP, com patches já liberados pela PHP Foundation, e com uma recomendação que assusta qualquer operador: se você não consegue corrigir agora, tire o site do ar até conseguir. Não é exagero de fornecedor de segurança tentando vender relatório. É o tipo de aviso que só aparece quando o risco de exploração remota é real e o tamanho da superfície exposta é absurdo. Estamos falando de algo em torno de 70% dos sites da internet, mais de 33 milhões de instalações por algumas estimativas, incluindo uma fatia enorme de WordPress, hospedagens compartilhadas e sistemas legados que ninguém toca há anos.

O fato é simples e brutal. Duas vulnerabilidades permitem que um atacante mexa no sistema de arquivos do servidor ou alcance o banco de dados usado pela aplicação web. Na prática, isso significa leitura e escrita fora do lugar, potencial execução e vazamento de dados, dependendo da configuração. O pior detalhe é a idade do problema. As falhas estavam presentes em todas as versões desde o PHP 5, lançado em 2004. Vinte e dois anos de código rodando no mundo inteiro com o mesmo ponto fraco escondido. Quem ainda está em PHP 8.1 ou anterior já estava sem suporte antes disso, e agora vai ter que encarar uma migração forçada para a versão atual, a 8.5.12, com tudo o que isso implica de quebra de compatibilidade.

O fato sem enfeite

A descoberta veio de dois lados ao mesmo tempo, e os dois lados usaram IA para achar o que humanos não tinham achado em duas décadas. De um lado, a empresa de testes Calif, participando da iniciativa Patch the Planet da OpenAI, encontrou uma das falhas usando o modelo GPT-5.6 Sol. Do outro, o time da Wiz, que pertence ao Google, usou seu agente Wiz Atlas combinado com Gemini 4 Argon e também GPT-5.6 Sol para mapear múltiplas vulnerabilidades no PHP. As duas frentes seguiram disclosure responsável, trabalharam com o time do PHP nos patches antes de abrir qualquer detalhe e depois juntaram esforços para validar as correções com ajuda de Automattic, Akamai, AWS, Cloudflare, Fastly, Imperva, Microsoft e Vercel. O WordPress já avisou que a falha não é específica do CMS, mas quem roda WordPress precisa corrigir o servidor e cobrar a hospedagem, porque não adianta atualizar plugin se o interpretador embaixo continua vulnerável.

Até o momento da divulgação, não havia relato de exploração ativa. A OpenAI afirma que os pesquisadores chegaram antes dos criminosos. Isso dá uma janela curta de respiro, mas não muda o cenário. Agora que os detalhes técnicos circulam, a corrida começou. De um lado, milhões de administradores tentando atualizar. Do outro, gente adaptando exploit para cada versão, cada configuração, cada layout de memória. A NSA não costuma mandar tirar site do ar à toa. Quando ela fala isso, é porque sabe que a automação do ataque vai ser mais rápida que a rotina normal de patch.

Como funciona na visão de quem opera

Em termos de arquitetura, o PHP continua sendo na maioria dos casos um interpretador acoplado ao servidor web, via FPM, mod_php ou containers, com acesso direto a arquivos, sessões, uploads e conexões de banco. Pelos indícios divulgados até agora, tudo indica que estamos diante de falhas de manipulação de memória e de validação de caminhos que permitem escapar do diretório esperado e alcançar áreas sensíveis. Não temos ainda um detalhamento completo linha por linha para todas as versões, mas o padrão é conhecido de quem já debugou C embaixo do PHP: um pequeno deslize em parsing ou em cópia de buffer vira uma porta enorme quando combinado com upload de arquivo, include dinâmico ou serialização mal filtrada.

O ponto novo é a latência entre descobrir e explorar. Antes, adaptar um exploit desse tipo para PHP 7.4 numa hospedagem com uma compilação específica, depois para PHP 8.0 em outro sistema operacional, depois para 8.2 com extensões diferentes, dava um trabalho manual imenso. A Wiz foi explícita sobre isso. Com LLMs, essa barreira cai. O modelo ajuda a reescrever o payload para versões, configurações e layouts de memória diferentes em horas, não em semanas. Isso muda o cálculo de custo do atacante. O que antes era caro e restrito a grupos avançados vira scriptável. E muda também o custo da defesa, porque não basta corrigir só a versão que você acha que está exposta. Qualquer instância antiga esquecida num subdomínio, num ambiente de homologação aberto ou num container parado vira ponto de entrada.

Atualizar para 8.5.12 parece simples no papel, mas quem opera sabe que não é. Sair de 7.4 ou 8.0 para 8.5 quebra coisa. Funções depreciadas, mudança de comportamento em strings, em datas, em tratamento de null, em extensões como imagick, redis, memcached, drivers de banco. Em hospedagem compartilhada, você nem sempre controla a versão. Depende do painel, do provedor, da fila de atualização deles. Em VPS e Kubernetes, depende de rebuild de imagem, teste de regressão, rollback planejado. E tem o WordPress com temas e plugins abandonados que travam o upgrade. É aí que mora o gargalo real, não no patch em si, mas em tudo que está amarrado em volta dele.

O que isso muda na prática

Quem ganha no curto prazo são os provedores grandes e os times que já vivem em versão suportada, com pipeline de atualização e WAF bem ajustado. AWS, Cloudflare, Fastly, Akamai e companhia já entraram no esforço de mitigação, e regra virtual no edge pode comprar tempo. Quem perde são os pequenos, o freelancer com 40 sites em um painel barato, a agência com cliente que não paga manutenção, a empresa com intranet em PHP 5.6 que ninguém tem coragem de tocar. Para esse grupo, a conta chega de uma vez: ou atualiza correndo ou assume o risco de invasão com acesso a arquivos e banco.

O que fazer agora sem se enrolar

A ação prática é direta e precisa ser feita hoje, não no próximo sprint. Primeiro, inventarie tudo. Liste cada domínio, subdomínio, IP e container e anote a versão exata do PHP respondendo. Muita gente vai achar servidor esquecido. Depois, priorize o que está exposto na internet com upload, login, formulário ou API pública, porque é ali que o exploit chega primeiro. Atualize para 8.5.12 em ambiente de teste, rode sua suíte básica, cheque logs de erro e só então promova. Se a hospedagem não oferece 8.5 ainda, abra chamado agora e ative mitigação temporária no WAF, bloqueie endpoints desnecessários e restrinja acesso a admin por IP.

• Inventário completo: descubra todas as versões de PHP expostas, incluindo homologação e sites antigos.
• Patch prioritário: corrija primeiro o que recebe input externo e tem acesso a banco ou arquivos sensíveis.
• Plano B: se não dá para corrigir hoje, isole, coloque atrás de WAF com regras atualizadas ou tire do ar como a NSA sugeriu.

Não confie só em esconder versão no header. Isso não protege nada contra esse tipo de falha. Revise permissões de arquivo, desative funções perigosas se o seu app permite, separe usuário do pool FPM por site e garanta backup testado antes de mexer. Parece básico, mas é o básico que evita que um patch apressado vire um downtime maior que o ataque.

A tensão que ninguém quer encarar

Aqui está a parte incômoda. Essa crise foi evitada por causa da IA e ao mesmo tempo só virou crise por causa da IA. Sem os agentes da OpenAI e da Wiz vasculhando código legado em escala, essas falhas de 2004 poderiam ficar quietas por mais dez anos. Com LLMs capazes de adaptar exploits em massa, elas viraram emergência global em um dia. Isso resolve ou só move o gargalo? A gente agora consegue achar bugs antigos muito mais rápido, mas também barateou o ataque na mesma proporção. Escala para os dois lados. E o custo compensa? Para quem mantém open source crítico com pouco financiamento, como o próprio PHP, depender de iniciativas pontuais de grandes labs para fazer auditoria profunda não parece sustentável. Funciona quando dá manchete, mas e o resto da pilha que ninguém está olhando com GPT-5.6 ou Gemini?

Tem outro ponto que me incomoda como operador. A internet correu para virtual patching no edge, e isso é ótimo para ganhar 48 horas. Só que regra de WAF não é correção. Ela filtra padrão conhecido. Se o exploit mudar de forma com ajuda de IA, a regra de ontem pode não pegar a variante de amanhã. A correção real continua sendo atualizar o interpretador. E atualizar 33 milhões de sites não acontece em uma semana. Vai ter cauda longa de servidor vulnerável por meses, talvez anos, igual vimos com Log4Shell e Heartbleed. A diferença é que agora o adversário também tem copiloto.

Conclusão

No fim, o recado é seco: se seu PHP não está em 8.5.12, você está exposto a uma falha ancestral que a IA tornou explorável em escala. Corrija o que dá hoje, isole o que não dá e não conte com obscuridade. E fica a pergunta que vai nos perseguir nos próximos meses: quantas outras fundações da web ainda guardam um bug de 20 anos esperando o próximo agente de IA para ser encontrado, ou para ser usado?