A 21 de outubro de 2026, a equipa do PHP lançou correções de emergência para duas falhas críticas no próprio motor do PHP. Ficaram conhecidas como PHP2Shell, têm os identificadores CVE-2026-109618 e CVE-2026-109619 e uma pontuação de gravidade de 9,2 em 10. Se o teu site corre em PHP, e a maioria corre, este artigo é para ti.
O que é o PHP2Shell, em linguagem simples
O PHP é a linguagem por trás de uma enorme parte da internet: WordPress, WooCommerce, PrestaShop, Joomla, Drupal e milhares de sites feitos à medida. As duas falhas não estão num plugin nem num tema. Estão no próprio PHP, na forma como ele gere a memória quando um pedido termina de forma anormal.
Na prática, um atacante sem password e sem conta consegue enviar um pedido preparado de propósito e pôr o servidor a executar código dele. Na configuração mais exposta (Apache com mod_php), a equipa do PHP demonstrou que um único pedido chega, e que o ataque acontece antes de o código do site sequer começar a correr. Ou seja: não importa se o teu WordPress está atualizado. Se o PHP do servidor não estiver, o site está exposto.
Quem está afetado
Todas as instalações de PHP que servem pedidos web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.
As versões corrigidas são o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
O PHP 8.1 e anteriores já não recebem correções oficiais. Algumas distribuições Linux publicaram correções próprias, mas quem está no PHP 7 deve migrar.
Já está a ser explorado
Não é um risco teórico. O honeypot da Amazon registou uma tentativa de exploração a 17 de outubro, quatro dias antes de as correções existirem. A Cloudflare confirmou ataques às duas falhas logo a seguir à divulgação. O centro de cibersegurança do Reino Unido (NCSC) e o CERT-EU recomendaram tirar do ar os sistemas que não possam ser corrigidos de imediato.
O que fazer, por ordem
Saber que versão de PHP o teu site usa. No WordPress está em Ferramentas → Saúde do site → Informação → Servidor. No painel do alojamento (cPanel, Plesk) costuma aparecer na página inicial.
Atualizar para uma versão corrigida. Se o alojamento é partilhado, quem atualiza é o fornecedor. Pergunta-lhe por escrito se já aplicou as correções do PHP2Shell (CVE-2026-109618 e CVE-2026-109619).
Se não der para atualizar já, há medidas temporárias que reduzem o risco, como desligar o
session.upload_progress. A própria equipa do PHP avisa que nenhuma delas protege por completo: a única correção definitiva é a atualização.Se o site está atrás da Cloudflare, há regras de firewall contra os ataques conhecidos, incluindo no plano gratuito. Ajudam, mas são temporárias e não substituem a atualização.
Depois de atualizar, verificar se houve intrusão: ficheiros PHP estranhos nas pastas de uploads, administradores que ninguém criou, alterações recentes que ninguém fez.
O que fizemos nos sites da JoaoDG
Nos servidores que gerimos, o PHP de todos os sites já estava numa versão corrigida a 23 de outubro, dois dias depois da divulgação. Revimos também as definições que a equipa do PHP recomenda, atualizámos o WordPress, os plugins e os temas, e procurámos sinais de intrusão. Não encontrámos nenhum.
A lição é a de sempre: um site não é um quadro que se pendura na parede. As falhas aparecem todas as semanas, e o que protege um negócio não é ter o site mais bonito, é ter alguém a tratar das atualizações antes de os atacantes chegarem.
Não sabes em que versão está o teu site, ou quem o atualiza? Fala connosco e verificamos contigo.
Fontes: BleepingComputer, Help Net Security. Imagem: Wikimedia Commons, domínio público (CC0).