Falha crítica do PHP de outubro de 2026: o meu site está afetado?

1. O teu site usa PHP?

• Sim, quase de certeza: WordPress instalado num alojamento, WooCommerce, PrestaShop, Joomla, Drupal, Magento, OpenCart, ou um site feito à medida em Laravel ou Symfony.
• Não é contigo: Shopify, Wix, Squarespace e WordPress.com. Os servidores são da plataforma, e é ela que os atualiza.
• Normalmente não: sites feitos com Lovable, Bolt ou v0 e publicados na Vercel ou na Netlify.

Conta também o que está ao lado da loja: um blogue em WordPress num subdomínio (por exemplo blog.aminhaempresa.pt) ou um site antigo que ninguém desligou. Se não sabes como o teu site foi feito, pergunta a quem o fez.

2. Que versão de PHP tens?

Vê no painel. Estes são os sítios mais comuns:

• WordPress: Ferramentas › Saúde do site › Informação › Servidor (Tools › Site Health › Info › Server), na linha da versão do PHP.
• cPanel: Software › MultiPHP Manager, ao lado do domínio. Em alguns alojamentos chama-se «Select PHP Version».
• Plesk: no domínio, a secção PHP (PHP Settings).
• Hostinger (hPanel): Sites › Gerenciar › Configuração PHP, na barra lateral (Websites › Dashboard › PHP Configuration).

Estás protegido se a tua versão for igual ou mais recente do que a corrigida da mesma linha:

• PHP 8.5: 8.5.12 ou mais recente
• PHP 8.4: 8.4.27 ou mais recente
• PHP 8.3: 8.3.36 ou mais recente
• PHP 8.2: 8.2.35 ou mais recente

Um número mais baixo nem sempre quer dizer que falta a correção. As distribuições Linux (Debian, Ubuntu, Red Hat e outras) receberam as correções antes do dia 21, e muitas aplicam-nas sem mudar o número da versão. Por isso a pergunta certa ao alojamento não é «que versão têm?», é «o vosso PHP já tem as correções de 21 de outubro?».

PHP 8.1 ou mais antigo: o projeto PHP já não o atualiza. Alguns fornecedores publicam correções próprias para versões antigas; se o teu não o faz, a saída é mudar para uma versão suportada. E o 8.2 deixa de receber correções a 31 de dezembro de 2026: se estás nele, atualiza agora e planeia a passagem para o 8.3 ou mais recente.

3. Atualizar: quem faz o quê

• Alojamento partilhado (a maioria dos sites WordPress de pequenos negócios): o PHP é do alojamento. Escolhes a versão no painel, mas quem instala as correções são eles.
• Servidor próprio ou VPS: atualiza o PHP pelo gestor de pacotes da tua distribuição, ou para uma das versões acima, e confirma que o PHP e o servidor web foram reiniciados. Até lá pode continuar a correr a versão antiga.
• Alguém trata do site por ti (uma agência, um freelancer): envia-lhes esta página e pede-lhes a confirmação por escrito.

Para o alojamento, uma mensagem assim chega: «Olá. O meu site, aminhaempresa.pt, usa PHP. A 21 de outubro o projeto PHP corrigiu duas falhas críticas (CVE-2026-109618 e CVE-2026-109619) nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Podem confirmar se o PHP do meu alojamento já tem estas correções, ou quando as vão instalar?»

Cuidado ao mudar de versão. Dentro da mesma linha (por exemplo de 8.3.30 para 8.3.36) o risco de partir alguma coisa é mínimo. Saltar de linha (de 7.4 ou 8.1 para 8.3) pode deixar plugins e temas antigos a não funcionar: faz uma cópia de segurança antes e vê o site logo a seguir.

4. Se não podes atualizar já

O projeto PHP publicou medidas temporárias, mas diz que elas reduzem a exposição e não tornam o servidor seguro. São para quem gere o servidor: no alojamento partilhado, quem as aplica é o alojamento.

Um plugin de segurança não chega: no caso mais grave (Apache com mod_php), o ataque demonstrado acontece antes de qualquer código do site começar a correr, por isso o plugin nem chega a vê-lo. Esconder a versão do PHP também não protege: o ataque não precisa de a saber.

5. Depois de atualizar: alguém entrou antes?

A atualização fecha a porta, mas não diz se alguém entrou antes de ela fechar. Se o teu site ficou numa versão antiga depois de 21 de outubro, faz isto:

1. No WordPress, em Utilizadores (Users), procura administradores que não conheces.
2. Pede ao alojamento uma análise de malware à tua conta, e corre também a de um plugin de segurança.
3. Muda as passwords de todos os acessos: o painel do alojamento, o FTP ou SFTP, a base de dados e os administradores do site. No WordPress, troca também as chaves secretas do wp-config.php: isso termina as sessões de quem ainda estiver lá dentro.
4. Troca as chaves guardadas no site: as do pagamento (Stripe, PayPal), a password do email que o site usa para enviar e as chaves de serviços de inteligência artificial usadas por plugins. Quem controla o servidor consegue lê-las, e uma chave de IA roubada gasta-se na tua conta.

Se encontrares sinais de ataque e o site tiver dados de clientes, o RGPD obriga a comunicar à CNPD em 72 horas, a não ser que seja improvável haver risco para as pessoas. Pede ajuda ao alojamento ou a um profissional antes de limpar: uma limpeza mal feita deixa portas abertas.

O que o Excubitor vê, e o que não vê

A verificação grátis só lê o que é público e não te diz a versão do PHP: essa vês no painel, ou pergunta-se ao alojamento. O que te diz é o que se vê de fora: se o certificado é válido, se alguém pode enviar emails a fingir ser o teu domínio, e o que falta nos cabeçalhos de segurança do site, com a prova de cada ponto.

Um conselho da própria documentação do WordPress: um site tomado é muitas vezes usado para enviar spam, e se o email do negócio sai do mesmo servidor, as listas negras apanham os dois. Ter o email num fornecedor próprio (Google Workspace, Microsoft 365) separa-os.

Para não teres de voltar a verificar

O PHP não o vigiamos, mas o resto do domínio sim: o Excubitor pode verificar o teu domínio todas as semanas (o certificado, os registos de email, os cabeçalhos) e escrever-te só quando algo muda. Grátis para 1 domínio: faz a verificação e carrega em «Avisa-me».

SPF, DKIM e DMARC passo a passo (os valores servem para qualquer domínio)