Pânico no PHP: duas falhas críticas colocam 70% da internet em risco e todo mundo está em polvorosa

Se você esteve online hoje, nem que seja por um momento, viu o pânico: uma vulnerabilidade crítica está ameaçando “pwnar” praticamente todos os sites do planeta.

A Finlândia começou a desligar sites governamentais na quarta-feira, a NSA está recomendando que todas as organizações que usam PHP desativem seus sites, e os Países Baixos e a França fizeram o mesmo. E não, não foi uma ciberguerra.

O culpado era o PHP, uma linguagem de programação da qual a maioria das pessoas nunca ouviu falar. Você quase certamente a usou hoje, no entanto: ela roda cerca de 70% de todos os sites cuja linguagem do lado do servidor é conhecida, segundo a W3Techs.

O PHP é o software que trabalha nos bastidores do servidor de um site — o computador que armazena o site e monta cada página que você solicita. Todo site WordPress, por exemplo, fica em um servidor PHP, segundo a empresa de segurança WordPress Wordfence.

Ah, por falar nisso, a Wordfence também está fora do ar.

Dois bugs recém-descobertos no próprio PHP permitem que um estranho execute seus próprios comandos naquele servidor sem nunca fazer login. O pessoal de segurança chama isso de execução remota de código não autenticada. Todo o resto pode chamar de "agora é outra pessoa que está dirigindo".

Se esse servidor armazena sua conta, seu endereço ou seu histórico de pedidos, bem, isso também é deles. A provedora de hospedagem GoDaddy alertou que as falhas poderiam permitir que atacantes roubassem dados, desfigurassem sites ou assumissem servidores por completo.

“Uma falha como essa poderia permitir que um atacante executasse seu próprio código em um servidor afetado pela internet, o que pode levar ao roubo de dados, à desfiguração de um site ou a uma tomada completa de controle”, diz a GoDaddy.

O que o PHP anunciou

A PHP Foundation, a organização sem fins lucrativos que financia o desenvolvimento da linguagem, deu o alerta na terça-feira. Em uma declaração compartilhada no X, ela disse: "A equipe de segurança do PHP está dando um aviso prévio: Próximo lançamento de segurança qua, 21 de outubro de 2026, 14:00UTC, duas vulnerabilidades críticas, ambas classificadas como CVSSv4 9.2. Usuários do PHP são incentivados a se preparar para atualizar. Lançamento antecipado se os detalhes se tornarem públicos ou houver evidência de exploração ativa."

Esse 9.2 vem do CVSS, o Common Vulnerability Scoring System (Sistema Comum de Pontuação de Vulnerabilidades), que classifica o quão perigoso um bug é com base em coisas como a facilidade com que ele pode ser alcançado pela internet e quanto dano ele pode causar. A escala vai de 0 a 10, e qualquer coisa a partir de 9,0 é rotulada como crítica — então esses dois são praticamente o pior que pode ser sem atingir um 10 perfeito.

A correção chegou por volta das 13:35 UTC de quarta-feira, alguns minutos antes do previsto, como versões do PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O aviso de segurança não se deu ao trabalho de ser sutil: "Todos os usuários do PHP são fortemente incentivados a atualizar imediatamente."

Mas lançar uma correção e fazer com que todos implementem a solução não são a mesma coisa, então recomenda-se cautela.

Como os bugs funcionam

O primeiro bug, CVE-2026-109618, aparece quando o PHP fica sem memória no meio do processamento de uma requisição e depois trata esses dados parcialmente construídos como se estivessem finalizados. O segundo, CVE-2026-109619, permite que sobras da requisição de um visitante permaneçam na memória depois de já deverem ter sido descartadas, onde a próxima requisição pode tropeçar nelas.

Pense em um cozinheiro que continua lendo pedidos de comandas que já estão no lixo. Coloque uma comanda falsa na lixeira, e o cozinheiro prepara o que quer que você tenha escrito nela. Neste caso, o “pedido” é o código do atacante, e o servidor o executa.

O PHP afirmou que o risco é maior em servidores que usam uma configuração comum do Apache chamada mod_php, onde um exploit demonstrado funciona "antes que qualquer código da aplicação seja executado". Em outras palavras, as próprias defesas do site, como telas de login e plugins de segurança do WordPress, nem sequer são acionadas.

Pesquisadores da fundação PHP apontaram o recurso de progresso de upload do PHP, aquilo que rastreia quanto de um arquivo você já enviou, como uma das formas confirmadas de entrada. Ele está ativado por padrão há mais de uma década, e poucos sites realmente o utilizam.

Um vazamento, depois ataques

Nada disso deveria ser público ainda. Na terça-feira, alguém publicou no fórum Hacker News que duas falhas no PHP seriam divulgadas naquela quinta-feira, admitindo que não tinham "nenhuma evidência além de 'fonte: confia, mano.'"

Acontece que o mano estava certo. A empresa de segurança watchTowr confirmou que os bugs eram reais e estavam sob embargo — um acordo para manter os detalhes em sigilo até que uma correção estivesse pronta — e o PHP antecipou seu lançamento em um dia.

"Estamos vendo ataques iniciais surgindo e atualizando as mitigações à medida que novos vetores aparecem", escreveu o CTO da Cloudflare, Dane Knecht, no X na madrugada de quarta-feira, quase seis horas antes do patch ser distribuído. A Cloudflare enviou regras de firewall de emergência, filtros que bloqueiam padrões de ataque conhecidos, para todos os clientes, mas Knecht as chamou de "apenas um paliativo".

Governos apertam o botão de desligar

O centro estatal de TI da Finlândia, Valtori, começou a tirar serviços web públicos do ar como precaução, informou a emissora pública Yle, enquanto a agência nacional de cibersegurança dos Países Baixos derrubou seu próprio site.

O Ministério do Interior da França declarou que os sites das prefeituras foram "temporariamente tirados do ar enquanto aguardam o lançamento de um patch de segurança pelo publicador do framework".

O CERT-EU, a equipe de emergência cibernética da UE, disse às organizações que não conseguiram aplicar o patch para "considerarem isolar aplicações voltadas para a internet das redes públicas até que uma correção esteja disponível". Isso é o jargão burocrático para "tire da tomada". Agências na Austrália, no Japão e no Reino Unido disseram praticamente o mesmo, segundo a Reuters.

O que as postagens virais erraram

Tópicos virais no X afirmavam que versões do PHP "que remontam a 2004" eram vulneráveis. Isso remete a estimativas iniciais de que tudo desde o PHP 5 era afetado, o que o CERT-EU admitiu ser baseado em postagens de redes sociais.

A empresa de segurança para comércio eletrônico Sansec situa o intervalo no PHP 5.4 e posteriores. Ou seja, 2012, não 2004—ainda assim, bem antigo.

O PHP só distribui versões oficiais para as versões 8.2 e mais recentes, o que torna a alegação de "nenhuma correção para versões antigas" meio verdadeira. Dada a gravidade desta falha, sua equipe de segurança também publicou patches de código-fonte básicos para 7.4, 8.0 e 8.1, e as distribuições Linux estão fazendo backport de correções próprias.

A empresa de segurança Mallory contabilizou cerca de 884.000 hosts voltados para a internet anunciando PHP 8.1 ou anterior em 20 de outubro, ou 59% dos aproximadamente 1,5 milhão que exibem publicamente uma versão. Um único servidor de hospedagem compartilhada pode abrigar muitos sites, então o número de sites por trás deles é maior.

Alguns tópicos também incluíram o Node.js, uma tecnologia web diferente que por acaso agendou sua própria atualização de segurança, não relacionada, para o mesmo dia. Azar no timing.

Mesmo as versões corrigidas não chegarão a todos os servidores de uma só vez. "Se você depende do https://rpms.remirepo.net mantido por voluntários, pedimos que migre agora para os pacotes da distribuição ou para a compilação a partir do código-fonte, para que possa aplicar as atualizações imediatamente. O repositório não terá atualizações hoje", disse a PHP Foundation em sua declaração, referindo-se a uma popular fonte de pacotes PHP mantida por voluntários para servidores Linux no estilo Red Hat.

Você realmente deveria se preocupar?

Você não deve entrar em pânico, mas também não deve dar de ombros. Um site invadido, por exemplo, não precisa tocar em uma blockchain para esvaziar sua carteira. Em 2024, atacantes redirecionaram os front-ends dos protocolos DeFi Compound e Celer para páginas que drenavam carteiras conectadas, e a Curve Finance sofreu um ataque semelhante em 2025.

Aqueles foram sequestros de DNS, não bugs do PHP, mas o truque é o mesmo: o site parece certo, a URL parece certa, e o botão "aprovar" envia seus tokens para outro lugar. Um servidor comprometido pode servir exatamente esse tipo de página.

Hackers podem ser muito criativos, muito rápido, quando se trata de exploits de dia zero.

Bugs como esses também estão ficando mais fáceis de encontrar, com modelos de IA de ponta cada vez mais usados para encontrar vulnerabilidades de software, e especialistas disseram ao Decrypt em junho que muitas mais vulnerabilidades podem surgir à medida que essas ferramentas se espalham.

O que acontece a seguir, e o que fazer

Assim que um patch se torna público, os atacantes podem comparar o código antigo e o novo para ver exatamente o que foi corrigido, e a equipe forense da empresa de cibersegurança Sansec disse que espera "ataques em massa começarem dentro de 15 minutos após o lançamento". Quando uma falha diferente do PHP se tornou pública em junho de 2024, a Akamai registrou tentativas de exploração contra seus servidores-isca em menos de 24 horas.

Então a pessoa comum deveria entrar em pânico? Não exatamente. Seu telefone, navegador e laptop não precisam de um patch de PHP; o trabalho recai sobre quem administra os sites que você usa.

Se você administra um site, pergunte ao seu provedor de hospedagem se o PHP foi atualizado, e não conte com o WordPress para fazer isso por você: o Wordfence alertou que as atualizações automáticas não aplicarão esta correção e disse aos proprietários de sites para descobrirem quem é responsável por atualizar o PHP em seus servidores. Qualquer pessoa na versão 8.1 ou anterior precisa planejar uma atualização.

"A única coisa que posso dizer é que a única mitigação é aplicar o patch / atualizar o PHP", disse a desenvolvedora do núcleo do PHP Gina Peter Banyard no Mastodon. "Infelizmente sei demais."

E se você está no PHP 8.2, a correção que você acabou de receber é uma das suas últimas: essa versão chega ao fim de vida em 31 de dezembro de 2026, após o qual não recebe mais patches de segurança.