O código tinha 14 anos. A falha foi encontrada por uma IA em agosto. Só soubemos na terça-feira.

Na terça-feira à noite, sites e serviços começaram a desaparecer. Não por estarem a ser atacados — por precaução. Duas vulnerabilidades críticas no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619 e conhecidas em conjunto como PHP2Shell, obrigaram agências governamentais em vários países europeus a retirar sites do ar enquanto se preparavam as correções.

Ambas têm pontuação de 9,2 em 10 no CVSS v4.0 e permitem execução remota de código sem autenticação. Um atacante não precisa de conta nem de palavra-passe: um único pedido pode correr código no servidor antes de qualquer linha do seu site ser executada.

O que é o PHP e porque isto importa tanto

O PHP é uma linguagem de programação com mais de 30 anos, usada em cerca de 70% dos sites do mundo. WordPress, Drupal, Joomla, Magento e Laravel assentam todos nela. Quando a falha está no PHP, não está num plugin nem num tema: está na fundação que sustenta o site inteiro.

Segundo a PHP Foundation, os problemas estão nas partes do PHP que são acionadas em praticamente todos os pedidos — a gestão de memória e o tratamento de erros. É por isso que a exposição é tão vasta e por isso a correção não podia esperar.

Como funciona a falha

• Corrupção na gestão de memória. Quando um pedido excede o memory_limit, o PHP aborta-o de forma abrupta. Se isso acontecer a meio da leitura de um upload, a limpeza pode tratar dados inválidos como válidos e libertar memória que nunca foi inicializada — memória que ainda pode conter dados controlados pelo atacante.
• Estado obsoleto entre pedidos. Estruturas internas de um pedido podem sobreviver à memória que as suportava. O pedido seguinte, servido pelo mesmo processo, pode usar esse estado antes de a inicialização normal o repor.

São bugs de motor, não de aplicação: não aparecem em testes funcionais, não dão erro e não deixam rasto nos logs. Segundo a NSA norte-americana, o caminho aberto por estas falhas podia chegar diretamente ao sistema de ficheiros ou à base de dados do servidor.

Então porque só se soube agora, se o código tem 14 anos?

Esta é a pergunta que interessa. Os investigadores reportam versões afetadas desde o PHP 5.4 — código de 2012. Durante 14 anos, a falha esteve lá, invisível.

O que mudou foi o método. A PHP Foundation usou um modelo de linguagem de ponta da Anthropic para analisar o próprio código e inscreveu o PHP no programa Patch the Planet, da OpenAI. Foi assim que as falhas foram encontradas — em meados de agosto de 2026 — em simultâneo com a descoberta independente de um investigador. O que durante anos escapou à revisão humana foi identificado por ferramentas que leem código em escala.

A partir daí, a cronologia explica o resto:

• Agosto: falhas descobertas e comunicadas em privado.
• Correção até 22 de outubro: prazo dado aos fabricantes para prepararem pacotes corrigidos antes da divulgação pública.
• 20 de outubro: torna-se pública a falha. As falhas começam a circular em fóruns e redes sociais.
• 21 de outubro, 13:30 UTC: o PHP publica 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O CERT-EU emite o aviso 2026-018 e o CNCS alerta em Portugal.
• 21 e 22 de outubro: agências europeias tiram sites do ar; a Cloudflare confirma os primeiros ataques e ativa regras de firewall.

Ou seja: não estivemos 14 anos sem saber. Estivemos 14 anos sem que ninguém tivesse encontrado. Quando finalmente alguém encontrou, a informação durou dois dias em segredo.

Atualizar o WordPress não resolve

Vale a pena insistir, porque é o erro mais comum. A correção tem de ser aplicada ao nível do servidor: atualizar para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reiniciar o serviço. É a mesma lógica que defendemos em segurança para lá do HTTPS — há camadas que ficam abaixo do site e que o site não consegue proteger sozinho.

E há um detalhe que engana muita gente: os scanners de dependências não detetam esta falha. O Dependabot e o composer audit dizem que está tudo limpo, porque a vulnerabilidade não vive em nenhum pacote que o projeto declare. Um scan verde não significa um servidor seguro.

O nosso dia: esperar, atualizar e validar

Passámos o dia de ontem exatamente nisto. A parte visível foi curta; a parte invisível foi o dia inteiro.

• Inventário. Descobrir a versão real de cada serviço. A versão que o PHP-FPM usa para servir o site não é necessariamente a que responde no terminal — e é a primeira que conta.
• Espera. O anúncio saiu a 20; as correções, a 21 ao início da tarde. Até lá não havia pacote para instalar. Só monitorização, preparação e um plano B escrito.
• Aplicação. Atualizar os pacotes, reiniciar os serviços PHP e confirmar que o processo em execução é o novo, não o antigo ainda em cache.
• Validação. Abrir cada site, testar formulários, lojas e áreas de cliente. Um servidor atualizado que devolve erros 500 não é um servidor seguro — é uma queda de serviço.

É por isso que ninguém deu por nada: quando o trabalho é bem feito, o resultado é exatamente igual ao de antes. A monitorização que temos montada, de que falámos no artigo sobre o UptimeRobot, serve para saber primeiro; este trabalho serve para não precisar de saber.

Os nossos servidores já estão atualizados

Se o seu site é gerido pela Make It Digital, não tem de fazer nada: os servidores que gerimos já estão a correr uma versão corrigida do PHP.

Não foi um clique. Foi uma noitada de trabalho árduo — inventário de cada serviço, atualização dos pacotes, reinício dos processos PHP e validação site a site — feita enquanto as notícias ainda estavam a ser escritas. No fim, tudo de pé: sem uma página em baixo e sem um cliente a notar.

Os nossos clientes podem estar descansados. Quando esta falha chegou às manchetes, o trabalho já estava feito.

O que deve fazer hoje

• Confirme a versão real de PHP que serve o seu site — não a do terminal, a do serviço web.
• Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinicie o PHP-FPM.
• Se está em 8.1 ou anterior, migre. O projeto PHP não vai corrigir essas versões; existem apenas correções de código-fonte para 7.4, 8.0 e 8.1, e alguns fornecedores fazem backport.
• Não confie num scan limpo. As ferramentas de análise de dependências não detetam esta falha.
• Valide depois de atualizar. Atualizar sem testar troca um risco de segurança por um problema de disponibilidade.

Em resumo

• Duas falhas críticas no motor do PHP, com execução remota de código sem autenticação.
• O código tinha mais de uma década; o que faltava era alguém — ou algo — que o conseguisse ver.
• A correção é no servidor, não no WordPress.
• Atualizar, reiniciar, validar — e fazer isto antes de haver notícia, não depois.
• Os servidores que gerimos já estão atualizados e validados.

Se não sabe que versão de PHP corre no seu site, essa é a primeira pergunta a responder esta semana.