Se esteve hoje na internet, certamente viu o pânico: uma vulnerabilidade crítica ameaça comprometer praticamente todos os sites do planeta.

A Finlândia começou a desativar sites governamentais na quarta-feira, a NSA está a recomendar que todas as organizações que usam PHP desliguem os seus sites, e a Holanda e a França fizeram o mesmo. E não, não foi uma guerra cibernética.

O culpado foi o PHP, uma linguagem de programação de que a maioria das pessoas nunca ouviu falar. Mas quase de certeza usou-a hoje: é responsável por cerca de 70% de todos os sites cuja linguagem de servidor é conhecida, segundo a W3Techs.

O PHP é o software que funciona nos bastidores do servidor de um site — o computador que armazena o site e constrói cada página que o utilizador pede. Todo o site WordPress, por exemplo, está hospedado num servidor PHP, de acordo com a empresa de segurança para WordPress Wordfence.

Aliás, a própria Wordfence também está fora do ar.

Duas falhas recentemente descobertas no próprio PHP permitem que um estranho execute os seus próprios comandos no servidor sem precisar de iniciar sessão. Os especialistas em segurança chamam a isto execução remota de código não autenticada. Para o resto, é como se alguém estivesse "no controlo".

Se esse servidor armazena a sua conta, a sua morada ou o seu histórico de encomendas, bem, isso também passa a ser deles. A empresa de alojamento GoDaddy alertou que as falhas podem permitir que invasores roubem dados, desfigurem sites ou assumam o controlo total dos servidores.

"Uma falha como esta pode permitir que um invasor execute o seu próprio código num servidor afetado pela internet, o que pode levar ao roubo de dados, à desfiguração de um site ou à tomada total do controlo", afirma a GoDaddy.

O que o PHP anunciou

A Fundação PHP, organização sem fins lucrativos que financia o desenvolvimento da linguagem, emitiu o alerta na terça-feira. Num comunicado partilhado no X, a equipa de segurança do PHP informou: "A equipa de segurança do PHP está a avisar com antecedência: a próxima atualização de segurança será lançada na quarta-feira, 21 de outubro de 2026, às 14h UTC, corrigindo duas vulnerabilidades críticas, ambas classificadas como 9.2 no CVSSv4. Os utilizadores do PHP são aconselhados a preparar-se para atualizar. O lançamento será antecipado caso os detalhes se tornem públicos ou haja evidências de exploração ativa."

A classificação 9.2 vem do CVSS, o Sistema Comum de Pontuação de Vulnerabilidades, que avalia o grau de perigosidade de uma vulnerabilidade com base em fatores como a facilidade com que pode ser explorada pela internet e o dano que pode causar. A escala vai de 0 a 10, e qualquer valor acima de 9.0 é considerado crítico — portanto, estas duas vulnerabilidades são extremamente graves, quase atingindo a pontuação máxima de 10.

A correção foi implementada por volta das 13h35 UTC de quarta-feira, alguns minutos antes do previsto, para as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 do PHP. O aviso de segurança não se preocupou em ser subtil: "Todos os utilizadores do PHP são fortemente encorajados a atualizar imediatamente."

Mas lançar uma correção e fazer com que todos a apliquem não são a mesma coisa, pelo que se recomenda cautela.

Como os bugs funcionam

O primeiro bug, CVE-2026-109618, manifesta-se quando o PHP fica sem memória a meio do processamento de um pedido e, posteriormente, trata esses dados parcialmente processados como se estivessem completos. O segundo, CVE-2026-109619, permite que dados residuais do pedido de um visitante permaneçam na memória depois de deverem ter sido descartados, podendo causar problemas no pedido seguinte.

Imagine um cozinheiro que lê pedidos a partir de comandas que já estão no lixo. Coloque uma comanda falsa no caixote do lixo e o cozinheiro prepara o que lá escreveu. Neste caso, o "pedido" é o código do atacante e o servidor executa-o.

A PHP afirmou que o risco é maior em servidores que usam uma configuração comum do Apache chamada mod_php, onde uma vulnerabilidade demonstrada funciona "antes mesmo da execução de qualquer código da aplicação". Por outras palavras, as próprias defesas do site, como ecrãs de login e plugins de segurança do WordPress, nem sequer chegam a ser ativadas.

Investigadores da Fundação PHP apontaram o recurso de progresso de upload do PHP, que acompanha a quantidade de um ficheiro já enviado, como uma das formas confirmadas de acesso. Está ativado por predefinição há mais de uma década e poucos sites o utilizam de facto.

Uma fuga de informação, seguida de ataques

Nada disto devia ser ainda público. Na terça-feira, alguém publicou no fórum Hacker News que duas falhas do PHP seriam divulgadas na quinta-feira seguinte, admitindo que não tinha "nenhuma evidência além de 'fonte: confia em mim, meu'".

Acontece que a pessoa tinha razão. 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 a PHP antecipou o lançamento em um dia.

"Estamos a ver os primeiros ataques a surgir e a atualizar as medidas de mitigação à medida que aparecem novos vetores", escreveu Dane Knecht, CTO da Cloudflare, no X na manhã de quarta-feira, quase seis horas antes do lançamento da atualização. A Cloudflare implementou regras de firewall de emergência, filtros que bloqueiam padrões de ataque conhecidos, para todos os clientes, mas Knecht classificou-as como "apenas uma medida paliativa".

Governos desligam tudo

O centro estatal de TI da Finlândia, Valtori, começou a desativar os serviços web públicos por precaução, informou a emissora pública Yle, enquanto a agência nacional de cibersegurança neerlandesa tirou o próprio site do ar.

O Ministério do Interior francês afirmou que os sites das prefeituras foram "temporariamente desativados até que uma atualização de segurança seja lançada pelo editor da estrutura".

O CERT-EU, a equipa de resposta a emergências cibernéticas da UE, orientou as organizações que não conseguiram aplicar a atualização a "considerar isolar as aplicações voltadas para a internet das redes públicas até que uma correção esteja disponível". Por outras palavras, "desliguem tudo". Agências na Austrália, no Japão e no Reino Unido disseram praticamente o mesmo, segundo a Reuters.

O que as publicações virais erraram

Tópicos virais no X afirmavam que versões do PHP "de 2004" eram vulneráveis. Isto remonta a estimativas iniciais de que tudo desde o PHP 5 era afetado, algo que o CERT-EU admitiu basear-se em publicações nas redes sociais.

A empresa de segurança para comércio eletrónico Sansec indica que o problema ocorre a partir do PHP 5.4. Logo, em 2012, e não em 2004 — ainda assim, uma versão bastante antiga.

O PHP só lança atualizações oficiais para as versões 8.2 e posteriores, o que torna a afirmação de que "não há correção para versões antigas" parcialmente correta. Dada a gravidade desta vulnerabilidade, a sua equipa de segurança publicou também patches básicos de código-fonte para as versões 7.4, 8.0 e 8.1, e as distribuições Linux estão a implementar correções retroativas por conta própria.

A empresa de segurança Mallory contabilizou cerca de 884 000 servidores de alojamento expostos à internet a anunciar PHP 8.1 ou versões anteriores a 20 de outubro, o que representa 59% dos aproximadamente 1,5 milhão que exibem publicamente uma versão. Um único servidor de alojamento partilhado pode hospedar muitos sites, pelo que o número de sites por trás destes é ainda maior.

Alguns tópicos incluíram também o Node.js, uma tecnologia web diferente que por acaso tinha agendada a sua própria atualização de segurança, sem relação com a vulnerabilidade, para o mesmo dia. Péssima escolha de momento.

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

Deve preocupar-se?

Não deve entrar em pânico, mas também não deve ignorar o problema. Um site pirateado, por exemplo, não precisa de aceder a uma blockchain para esvaziar a sua carteira. Em 2024, invasores redirecionaram as interfaces dos protocolos DeFi Compound e Celer para páginas que drenaram as carteiras ligadas, e a Curve Finance sofreu um ataque semelhante em 2025.

Estes foram ataques de sequestro de DNS, não bugs do PHP, mas o truque é o mesmo: o site parece correto, o URL parece correto e o botão "aprovar" envia os tokens para outro lugar. Um servidor comprometido pode exibir exatamente esse tipo de página.

Os hackers podem ser muito criativos e muito rápidos quando se trata de explorações de dia zero.

Bugs como estes também estão a tornar-se mais fáceis de encontrar, com modelos de IA de ponta a ser cada vez mais usados para detetar vulnerabilidades de software, e especialistas disseram ao Decrypt em junho que podem surgir muitas outras vulnerabilidades à medida que estas ferramentas se disseminam.

O que acontece agora e o que fazer?

Assim que uma correção é publicada, os atacantes podem comparar o código antigo com o novo para ver exatamente o que foi corrigido, e a equipa de perícia forense da empresa de cibersegurança Sansec disse esperar que "ataques em massa comecem até 15 minutos após o lançamento". Quando uma falha diferente do PHP foi divulgada em junho de 2024, a Akamai sofreu tentativas de exploração contra os seus servidores-isco em 24 horas.

Então, deve a pessoa comum entrar em pânico? Não exatamente. O telemóvel, o navegador e o portátil não precisam de uma correção para o PHP; o trabalho recai sobre quem administra os sites que utiliza.

Se administra um site, pergunte ao seu fornecedor de alojamento se o PHP foi atualizado e não conte com o WordPress para o fazer por si: a Wordfence alertou que as atualizações automáticas não aplicarão esta correção e orientou os proprietários de sites a descobrir quem é responsável por atualizar o PHP nos seus servidores. Quem estiver a usar a versão 8.1 ou anterior precisa de planear uma atualização.

"A única coisa que posso dizer é que a única solução é aplicar patches/atualizar o PHP", disse Gina Peter Banyard, programadora do núcleo do PHP, no Mastodon. "Infelizmente, sei demasiado."

E se estiver a usar o PHP 8.2, a correção que acabou de receber é uma das últimas: esta versão chega ao fim do seu ciclo de vida a 31 de dezembro de 2026, após o qual deixará de receber patches de segurança.

* Traduzido e editado com autorização do Decrypt.

A porta de entrada para o bitcoin, a maior criptomoeda do mundo, está na MB. É simples, seguro e transparente. Não adie mais um investimento com potencial gigantesco. Invista em poucos cliques!