A 21 de outubro de 2026, o projeto PHP publicou correções para duas vulnerabilidades críticas, a CVE-2026-109618 e a CVE-2026-109619, que podem permitir que um atacante execute código num servidor sem iniciar sessão. Se o seu website funciona em PHP, como todos os websites WordPress, convém verificá-lo hoje. Explicamos o que aconteceu, o que fazer e como tratámos do assunto nos websites que gerimos.
O que são as CVE-2026-109618 e CVE-2026-109619?
As duas são falhas do próprio PHP, cada uma classificada com 9,2 na escala CVSS v4.0, e o projeto PHP considera-as críticas. Permitem a execução remota de código sem autenticação: alguém sem conta no seu website poderia pôr o seu servidor a executar código seu.
- CVE-2026-109618: quando o PHP fica sem memória, pode ser interrompido com os dados internos do pedido ainda a meio de serem preparados, e a limpeza que se segue pode tratar esses dados inválidos como válidos.
- CVE-2026-109619: os dados internos de um pedido podem sobreviver à memória para a qual apontavam, e um pedido posterior no mesmo worker pode usá-los.
O seu website está afetado?
Muito provavelmente, se funciona em PHP e não foi atualizado desde então. O aviso de segurança abrange todas as instalações de PHP que respondem a pedidos web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed, e considera o risco mais elevado no mod_php.
Manter o WordPress, o tema e os plugins atualizados é uma boa prática, e recomendamo-lo no nosso guia de segurança para WordPress, mas não resolve este problema. A falha está na camada que fica por baixo.
O que fazer agora
- Descubra a sua versão do PHP. No WordPress: Ferramentas, Saúde do site, Informação, Servidor.
- Atualize para uma versão corrigida: PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se tem alojamento gerido, peça ao seu fornecedor que confirme que a atualização foi feita.
- Confirme que a nova versão está mesmo a funcionar. Os workers do PHP têm de ser reiniciados para a carregar.
- Primeiro uma cópia de segurança, depois os testes. Verifique logo a seguir a página inicial, os formulários, o checkout e a área de administração.
- Planeie com antecedência se usa uma versão antiga. O PHP 8.1 e as versões anteriores já não recebem atualizações do projeto, e o PHP 8.2 chega ao fim de vida a 31 de dezembro de 2026.
Se não puder atualizar de imediato, o aviso de segurança indica definições provisórias. Segundo o próprio aviso, reduzem a exposição mas não a eliminam, e atualizar é a única opção segura.
Como a nossa equipa tratou do assunto
Cuidamos dos websites que criamos, no nosso próprio servidor, por isso este problema era nosso. O projeto PHP publicou as correções a 21 de outubro, às 14h00 UTC. Às 9h27 UTC da manhã seguinte, menos de 20 horas depois, a nossa atualização já estava em curso. Foi isto que fizemos:
- Primeiro, uma cópia de segurança. Guardámos a configuração do PHP e a lista de pacotes instalados, para podermos voltar atrás se alguma coisa falhasse.
- Só o que a correção exigia. Atualizámos os pacotes do PHP e mais nada, e mantivemos as definições de cada website tal como estavam.
- Todas as versões suportadas. Passámos as versões 8.2, 8.3, 8.4 e 8.5 para as respetivas versões corrigidas, e não apenas a que os nossos websites usam.
- Uma verificação de cada website. No fim, abrimos os websites um a um, incluindo as páginas de contacto e as versões traduzidas, e confirmámos que todos respondiam normalmente.
Nada disto é heroico. É simplesmente para isso que serve a manutenção e suporte: quando o aviso chega, já há alguém atento, que conhece a configuração do servidor e tem um caminho de regresso preparado. Para saber mais sobre o que esse trabalho envolve, consulte a nossa lista de verificação para a manutenção de websites.
Perguntas a fazer a quem gere o seu website
- Em que versão do PHP está o meu website e quando foi atualizado pela última vez?
- Como saberiam de uma vulnerabilidade crítica e em quanto tempo atuariam?
- Existe uma cópia de segurança recente e alguém já experimentou restaurá-la?
- Quem verifica o website depois de uma atualização?
Se estas perguntas não têm resposta rápida, vale a pena resolver isso antes do próximo aviso de segurança.
Perguntas frequentes
Que versões do PHP corrigem as CVE-2026-109618 e CVE-2026-109619?
PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, segundo o aviso de segurança do projeto PHP. A sua versão tem de ser essa ou posterior, ou o seu fornecedor tem de confirmar que aplicou as correções à versão que usa.
Um website WordPress pode ser afetado?
Sim, se o PHP em que funciona não tiver sido corrigido. As falhas estão no próprio PHP, por isso não dependem do tema nem dos plugins, e atualizar o WordPress não as resolve. A atualização tem de ser feita no servidor.
Uma firewall ou uma definição do servidor protegem-me em vez disso?
Não totalmente. O aviso de segurança indica definições provisórias que reduzem a exposição e diz que não tornam uma instalação segura. Atualizar é a única opção segura.
E se o meu website usar o PHP 8.1 ou uma versão anterior?
O projeto PHP já não publica atualizações para essas versões. O aviso de segurança refere que alguns fornecedores aplicam as correções a versões antigas, por isso pergunte ao seu, ou atualize para uma versão suportada. O próprio PHP 8.2 deixa de receber correções de segurança a 31 de dezembro de 2026.
Como verifico que versão de PHP o meu website utiliza?
No WordPress, abra Ferramentas, depois Saúde do site, depois Informação e, por fim, Servidor. Noutras plataformas, o painel de alojamento costuma indicá-la; se não, o seu fornecedor de alojamento ou o seu programador podem dizer-lhe.
Não sabe se o seu website já foi atualizado? Envie-nos o endereço e dizemos-lhe o que verificar.
