O seu site corre em PHP? As duas falhas que levaram governos a desligar servidores

A equipa de segurança do PHP lançou atualizações de emergência para corrigir duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell. As falhas permitem executar código remotamente sem autenticação. Detalhes sobre elas foram divulgados antes do fim do embargo, e há relatos de tentativas de exploração anteriores à publicação das correções. As versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem as duas vulnerabilidades. O projeto diz que não existe nenhuma mitigação completa além da atualização.

Uma fuga de informação antes do embargo

A 20 de outubro, a equipa de segurança do PHP anunciou que ia publicar uma versão de emergência na quarta-feira, 21 de outubro de 2026, às 14:00 UTC, para corrigir duas vulnerabilidades críticas, ambas com classificação CVSS v4.0 de 9.2. O aviso surgiu depois de um utilizador do fórum Hacker News ter afirmado, numa publicação entretanto apagada, que duas vulnerabilidades críticas de execução remota de código no PHP seriam divulgadas a 22 de outubro.

A empresa watchTowr confirmou publicamente que as falhas existiam. Segundo o seu CEO, Benjamin Harris, as vulnerabilidades estavam sob embargo e tinham divulgação prevista para quinta-feira, às 11:00 (hora da costa leste dos EUA). O PHP avisou que podia publicar as correções mais cedo caso surgissem detalhes técnicos ou provas de exploração ativa, e foi isso que aconteceu.

O CNCS publicou um alerta antes da publicação das correções. Nessa altura, o centro sublinhava que os identificadores CVE-2026-109618 e CVE-2026-109619 não tinham sido confirmados pelo PHP nem tinham registo na NVD ou no cve.org. A confirmação oficial chegou com as novas versões.

O que está em causa, tecnicamente

O aviso de segurança publicado em php.net descreve duas falhas diferentes, ambas ligadas à forma como o PHP gere a memória quando um pedido é interrompido por um erro:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), execução remota de código por corrupção em falta de memória (OOM): o tratamento de falta de memória pode interromper o PHP quando os dados internos do pedido ainda só estão parcialmente inicializados, e a limpeza do pedido pode depois tratar esses dados inválidos como válidos.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), execução remota de código por estado global obsoleto: o estado interno de um pedido pode sobreviver depois de a sua memória ser libertada, e um pedido seguinte no mesmo processo pode usar esse estado antes de ser reiniciado.

Segundo o projeto, estão em risco todas as instalações PHP que servem pedidos web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é mais elevado no mod_php, onde foi demonstrado um exploit em que um pedido não autenticado desencadeia o ataque antes de correr qualquer código da aplicação. Isto quer dizer que um site pode estar exposto mesmo que o código da aplicação esteja bem escrito, porque a falha está no próprio motor do PHP.

A Cloudflare indica que a divulgação coordenada foi feita pela Calif.io, Wiz, OpenAI e Quarkslab. Segundo a empresa, as falhas afetam todos os servidores web com PHP 5.4 ou posterior e podem permitir negação de serviço, execução remota de código e exposição de dados. A Patchstack refere que a Wiz também demonstrou a leitura da memória dos processos PHP, que pode conter palavras-passe, tokens e chaves de API.

Antes da publicação oficial circularam análises técnicas que não coincidiam com o aviso final. Um investigador escreveu que a análise divulgada antes das correções estava errada nas duas falhas: a CVE-2026-109618 é um problema de falta de memória, e o mecanismo de progresso de upload da sessão é apenas um dos caminhos confirmados da CVE-2026-109619. Nas primeiras horas também circulou a pontuação de 10.0, mas a classificação oficial é 9.2.

Versões afetadas e corrigidas

O alerta do CNCS sublinha que as versões 8.1 e anteriores estão em fim de vida e não receberão correção. O problema é grande: uma análise da VirusTotal contou cerca de 758 mil servidores com ramos em fim de vida, entre o 5.4 e o 8.1, que têm o progresso de upload da sessão ativo por omissão e já não recebem correções.

Cronologia

Exploração ativa e sites desligados

O CTO da Cloudflare, Dane Knecht, disse que a empresa estava a ver os primeiros ataques e a atualizar as mitigações à medida que surgiam novos vetores. A empresa disponibilizou regras de firewall de aplicações web (WAF) para todos os clientes, incluindo os do plano gratuito, mas apresenta-as apenas como solução provisória. As regras só protegem se o servidor aceitar tráfego exclusivamente da Cloudflare. A Patchstack registou, às 07:34 UTC, vários incidentes de exploração ativa reportados por parceiros de alojamento.

Vários governos reagiram. Segundo a The Record, a União Europeia, os EUA, a Alemanha, o Japão, a Austrália, o Reino Unido e os Países Baixos emitiram avisos, e alguns governos chegaram a desligar sites antes de existirem correções. A mesma publicação refere que centenas de sites estiveram em baixo enquanto os administradores respondiam ao alerta.

Até ao momento, nenhuma fonte oficial publicou indicadores de comprometimento (IOCs), como endereços IP ou hashes. Depois de aplicar as correções, as equipas devem procurar sinais de comprometimento anterior: web shells, ficheiros .php alterados recentemente, contas de administrador novas e ligações de saída invulgares a partir do servidor web.

O que fazer agora

• Atualizar e reiniciar: instale 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinicie todos os processos (php-fpm, Apache). Confirme a versão ativa com php -v e php-fpm -v. Os pacotes das distribuições Linux e as imagens Docker podem demorar algumas horas a ficar disponíveis.
• Fazer o inventário: identifique todos os sistemas com PHP, a começar pelos que estão expostos à Internet. Isto inclui painéis de alojamento, equipamentos e appliances de terceiros.
• Reduzir a exposição temporariamente: para a CVE-2026-109619, o aviso recomenda session.upload_progress.enabled=0 com reinício de todos os processos e, no PHP 8.5, fatal_error_backtraces=0. Para a CVE-2026-109618, recomenda memory_limit=-1, um post_max_size baixo e limites ao tamanho dos pedidos no servidor web. O PHP avisa que não se deve confiar em ini_set() nem em .user.ini no FPM.
• Versões em fim de vida: migre para um ramo suportado ou retire o servidor da Internet até conseguir migrar.

Estas medidas são paliativas. Segundo o aviso oficial, as configurações listadas reduzem a exposição a caminhos de ataque específicos, mas não tornam uma instalação segura. Note ainda que atualizar o WordPress, o Drupal ou o Joomla não corrige o problema: o que é preciso atualizar é o PHP instalado no servidor.

Porque é que isto importa em Portugal

Muitos sites institucionais, lojas online e plataformas de PME em Portugal assentam em PHP, com frequência em alojamento partilhado onde a versão do PHP é gerida pelo fornecedor. Os clientes destes serviços devem confirmar com o fornecedor que a atualização foi feita. Quem gere os próprios servidores deve tratar esta atualização como emergência.

Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), um caso destes testa diretamente as obrigações de gestão de vulnerabilidades e de notificação de incidentes significativos ao CNCS. Se um servidor comprometido tiver dados pessoais, como clientes, encomendas ou credenciais, pode estar em causa uma violação de dados nos termos do RGPD, que obriga a avaliar a notificação à CNPD no prazo de 72 horas. A possibilidade de ler a memória dos processos PHP, onde podem estar palavras-passe e chaves de API, torna esta avaliação ainda mais importante.

Perguntas frequentes

O que é o PHP2Shell?

É o nome dado a duas vulnerabilidades críticas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 de 9.2. Permitem executar código remotamente sem autenticação em servidores que usam o PHP para servir pedidos web.

Que versões do PHP corrigem as falhas?

As versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas a 21 de outubro de 2026. O PHP 8.1 e as versões anteriores estão em fim de vida e não vão receber correção oficial.

Desativar session.upload_progress resolve o problema?

Não. Bloqueia apenas um dos caminhos confirmados da CVE-2026-109619 e não tem efeito na CVE-2026-109618. Segundo o PHP, só a atualização resolve o problema por completo.

Tenho um site WordPress num alojamento partilhado. O que devo fazer?

Confirme no painel de alojamento ou junto do fornecedor qual é a versão do PHP em uso e se já foi atualizada. Atualizar o WordPress não basta, porque a falha está no PHP do servidor e não no CMS.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelo PHP, pelo CNCS, pela Cloudflare, pela Sansec e pela Patchstack.