A correria com o PHP prova que corrigir falhas em ritmo humano não funciona mais
Duas falhas do PHP achadas por IA tiraram do ar governos e grandes sites. A lição real: descobrir ficou mais rápido que corrigir, e é nessa brecha que os defensores perdem.
Imagem gerada por IA
O que isso diz sobre o estado da segurança na internet quando a atitude responsável é desligar o seu site? Esse foi o conselho de agências do mundo todo nesta semana, e muitas organizações o seguiram.
A semana em que o mais seguro era desligar tudo
Duas falhas críticas no PHP, a linguagem por trás de uma enorme parcela da web, foram encontradas com ferramentas de IA. Segundo a BBC, a PHP Foundation lançou uma correção na quarta-feira, e agências como o NCSC do Reino Unido disseram que organizações sem como corrigir de imediato deveriam considerar tirar sistemas do ar. A Finlândia desligou temporariamente seus serviços web públicos do governo, a agência cibernética da Holanda tirou do ar o próprio site, e partes da Wikipédia ficaram inacessíveis. A NSA alertou que esses bugs costumam dar um caminho direto ao sistema de arquivos ou ao banco de dados de um servidor.
As falhas passaram despercebidas por mais de uma década. Detalhes vazaram nas redes sociais antes da divulgação planejada, o que forçou um anúncio apressado. O CTO da Cloudflare disse já estar vendo os primeiros ataques.
O bug não é a notícia; o relógio é
Bugs antigos e profundos existem em qualquer base de código grande. O que mudou é quem os encontra e com que rapidez. A Wiz afirmou que modelos de ponta permitiram a seus pesquisadores desenvolver exploits funcionais em várias aplicações em poucas horas. A OpenAI, que diz que suas ferramentas ajudaram a achar as falhas, escreveu que essas mesmas capacidades "também podem ajudar atacantes a desenvolver rapidamente ferramentas ofensivas e exploits".
Agora compare com o lado de quem defende. O The Record informa que um dos bugs remonta a uma auditoria de 2024 e depois ficou parado por meses, enquanto uma equipe pequena de desenvolvedores principais lidava com dilemas de compatibilidade. Não os culpamos. O raciocínio deles parece sensato para um mundo em que ninguém conseguia transformar o bug em arma rapidamente. Esse mundo acabou.
Na nossa visão, esse é o descompasso central: descobrir agora leva semanas ou horas, enquanto corrigir por consenso, empacotar e depois implantar em milhares de organizações leva meses. Quem está nessa brecha fica exposto.
Desligar sites é sintoma, não estratégia
Tirar um site do ar funciona, e achamos que as agências estavam certas em dizer isso. Mas é um freio de emergência, não um plano. Don Smith, da Sophos, apontou o problema real: antes de aplicar a correção, é preciso encontrar todos os lugares em que o PHP roda, inclusive dentro de sistemas de gerenciamento de conteúdo, plataformas de hospedagem e produtos de terceiros, às vezes sem que a organização saiba.
Isso é um problema de inventário, e não dá para resolvê-lo no dia em que o alerta sai. Suspeitamos que organizações que sabiam o que executavam conseguiram corrigir ou isolar em horas, enquanto as outras tiveram de adivinhar, e adivinhar é como se chega a um apagão.
Há também um grupo mais difícil: os sistemas legados. O The Record diz que as correções cobrem apenas o PHP 8.2 e posteriores, e cita estimativas da Cisco Talos de que cerca de 50% dos sistemas PHP vulneráveis podem não receber correção. Esses operadores não conseguem sair da situação com automação numa versão sem suporte. Para eles, a janela de exposição não se fecha; ela simplesmente fica ali. Essa é a parte subestimada da história.
Defensores devem tratar inventário e velocidade como controles
Primeiro, trate o inventário como um controle de segurança. Conheça cada instância de PHP, inclusive as que fornecedores embutem, e pergunte diretamente a eles.
Segundo, automatize a parte chata: implantações em etapas, reversões testadas e caminhos de emergência pré-aprovados, para que uma atualização crítica não espere por um comitê. Os mantenedores precisam do mesmo; a PHP Foundation diz que está mudando sua estrutura interna para que bugs graves cheguem mais cedo à liderança.
Terceiro, aposente versões sem suporte antes do próximo alerta, não durante ele.
Há um contraponto justo. A OpenAI observa que, até onde sabe, a IA de ponta encontrou essas falhas antes dos atacantes, dando vantagem inicial aos defensores, e se comprometeu com US$ 1 bilhão em acesso subsidiado para organizações com poucos recursos de segurança. É animador, embora seja a leitura da própria empresa, e o vazamento e os ataques iniciais mostram com que rapidez uma vantagem evapora. O CEO da Chainguard disse que o setor precisa "descobrir como passar por elas de forma mais rápida, coordenada e melhor", e concordamos. A OpenAI também diz esperar que descobertas semelhantes aumentem muito nos próximos meses. Encare isso como uma previsão, mas plausível.
O veredito: esta semana foi um ensaio. Organizações que corrigem em horas vão tratar a próxima como uma terça-feira qualquer. Todas as outras vão ensaiar o apagão de novo.
Ainda não há temas: abra o primeiro.
Mais matérias
A confiança dos navegadores ainda é frágil demais para falhar tão silenciosamente
O comprometimento da eMudhra mostra que o HTTPS pode continuar exposto fora do navegador, onde a revogação é irregular, os repositórios de confiança ficam defasados e os usuários quase não percebem a diferença.
Falha CVSS 10 do GitLab transforma CI/CD em sistema de produção
Uma vulnerabilidade crítica do GitLab lembra que a infraestrutura de desenvolvimento pode virar um caminho para ataques à cadeia de suprimentos.
O problema do QPACK no HTTP/3 mostra como velocidade amplia a superfície de ataque
O HTTP/3 traz conexões mais rápidas e multiplexação, mas ataques ao QPACK mostram como a complexidade pode transformar recursos de desempenho em falhas caras.
As correções emergenciais do PHP expõem a base frágil da web
Duas falhas críticas do PHP que vazaram mostram que corrigir sistemas é apenas metade do problema quando sites dependem de hospedagem, plugins e servidores antigos sem gestão.



