PHP2Shell: falhas críticas no seu site expõem uma fundação com um só funcionário fixo

Uma série de vulnerabilidades críticas no núcleo do PHP, batizadas de PHP2Shell, deu origem a uma corrida mundial às atualizações e voltou a mostrar como uma tecnologia de que depende uma grande parte da web assenta numa estrutura frágil. As falhas CVE-2026-109618 e CVE-2026-109619 permitem execução remota de código sem autenticação. Já foram detetadas tentativas de exploração e, dois dias depois das correções de emergência, foi divulgado um terceiro problema, ainda sem correção. Ao mesmo tempo, a diretora executiva da PHP Foundation admitiu que a organização funciona com um único funcionário a tempo inteiro.

O que está em causa

Ao contrário da maioria dos incidentes no ecossistema PHP, que costumam vir de plugins ou extensões de terceiros, estas falhas estão no próprio interpretador. Segundo a análise da Unit 42 da Palo Alto Networks, a CVE-2026-109618 resulta do tratamento de erros de falta de memória através de longjmp(), que deixa a memória do pedido por inicializar devido a uma gestão inadequada do fluxo de controlo. Já a CVE-2026-109619 ocorre quando o tratamento de erros fatais deixa a memória global a apontar para regiões já libertadas, que podem depois ser lidas ou usadas em pedidos seguintes, permitindo executar código arbitrário.

Na prática, o problema está na forma como o PHP reserva e liberta memória quando um pedido HTTP corre mal. A Google Cloud resume que, na segunda falha, um pedido posterior tratado pelo mesmo processo pode usar esse estado obsoleto antes de a inicialização normal o repor. Além da execução de código, os investigadores demonstraram a divulgação, sem autenticação, da memória dos processos PHP, o que pode expor palavras-passe, tokens de autenticação e chaves de API, segundo a Qualys.

O alerta publicado pelo CNCS indica o vetor CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. A complexidade é classificada como alta porque a fiabilidade da exploração depende da build do PHP, das extensões e da configuração do servidor. Ainda assim, não são precisos privilégios nem interação do utilizador.

Versões afetadas e corrigidas

As fontes não coincidem totalmente quanto ao alcance histórico das falhas. A Google Cloud aponta como vulneráveis todas as versões do PHP da 5.4 à 8.5.11. A rede europeia de CSIRT refere que as falhas estarão presentes em todas as versões atuais do PHP e, pelo menos, em todas as versões a partir da 5.

Para os ramos sem suporte, a Trend Micro refere que a equipa de segurança do PHP disponibilizou backports mínimos de código-fonte para o PHP 7.4, 8.0 e 8.1, destinados a quem compila a partir do código. Segundo o Centro Canadiano de Cibersegurança, estão em risco todas as instalações PHP que respondem a pedidos web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed, sendo o mod_php o caso mais grave, porque um exploit demonstrado ativa a vulnerabilidade antes de o código da aplicação ser executado.

Cronologia: de fuga de informação a exploração

O processo de divulgação coordenada não correu como previsto. De acordo com a watchTowr, as falhas foram descobertas por investigadores da Calif e reportadas ao PHP, mas os detalhes foram divulgados nas redes sociais a 20 de outubro, antes da data prevista de 22 de outubro.

Quanto à exploração, os dados pedem leitura cuidadosa. A watchTowr indica que tem observado exploração desde 21 de outubro através da sua rede global de honeypots, e a Qualys refere que a Cloudflare já reportou tráfego de ataque dirigido a estas vulnerabilidades, incluindo tentativas de contornar as suas proteções. Do lado da fundação, segundo a Reuters, a diretora executiva disse que não havia provas de que as falhas tivessem sido exploradas antes da divulgação, nem em sites já corrigidos.

Uma terceira falha, ainda sem correção

A 23 de outubro surgiu a CVE-2026-115560. A Trend Micro descreve-a como uma vulnerabilidade de execução remota de código no tratamento do progresso de upload de sessões, com a mesma mitigação da CVE-2026-109619. O risco é bastante mais limitado: só se manifesta quando uma aplicação define session.serialize_handler como php_binary ou php_serialize e depois o muda para php com ini_set() antes de chamar session_start(), com o progresso de upload ativo (o comportamento por omissão). Até ao fecho deste artigo, o PHP ainda não tinha indicado a versão nem a data da correção.

Exposição em números

A dimensão do problema ajuda a explicar a urgência. Segundo a Unit 42, o Cortex Xpanse identificou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis. A rede europeia de CSIRT refere que as consequências possíveis incluem o controlo de servidores web, a indisponibilidade de sites, fugas de dados ou a perturbação de funcionalidades como a autenticação.

Uma fundação crítica com recursos mínimos

O caso trouxe para o debate público o financiamento do software de código aberto. Em entrevista à Reuters, Elizabeth Barron, diretora executiva da PHP Foundation, explicou que a organização tem um único funcionário a tempo inteiro, ela própria, e 14 colaboradores maioritariamente a tempo parcial, com uma direção de voluntários não remunerados e financiamento através de donativos e subsídios. A conclusão da responsável foi clara: “Given that reliance, it is clear that PHP is incredibly under-funded.”

A inteligência artificial aparece como um fator ambíguo. Segundo a mesma reportagem, ajudou os investigadores a encontrar falhas que existiam há uma década, mas também aumenta a carga de trabalho de quem mantém o projeto. A fundação recebe quase o dobro das propostas de alteração de código de há um ano, mas o número de contribuidores não duplicou.

O que fazer agora

• Atualizar: instalar o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Quem usa pacotes da distribuição deve aplicar as atualizações do fornecedor do sistema operativo.
• Inventariar: identificar todas as instâncias PHP, incluindo as que estão dentro de equipamentos e produtos de terceiros. O NCSC da Nova Zelândia lembra que firewalls, dispositivos de rede e plataformas embebidas podem precisar de avaliação própria.
• Mitigar: definir session.upload_progress.enabled=0 (no Apache com mod_php, com php_admin_flag). Esta medida bloqueia vias de ataque conhecidas e a CVE-2026-115560, mas não protege contra a CVE-2026-109618 e não substitui a atualização.
• Planear a migração: sair dos ramos 8.1 e anteriores, que já não recebem correções oficiais.
• Investigar: procurar processos PHP-FPM ou workers PHP que lancem shells, webshells recentes e acessos anómalos desde 20 de outubro. Se houver sinais de exposição de memória, rodar credenciais e chaves de API.

Não foram publicados indicadores de comprometimento (IOCs) consolidados por uma fonte oficial. Os fabricantes de segurança têm disponibilizado sobretudo regras de deteção comportamental, por exemplo para workers PHP que iniciam interpretadores de comandos.

Porque é que isto importa em Portugal

O PHP está por trás de muitos sites institucionais, lojas online e sistemas de gestão de conteúdos usados por PME, autarquias e outras entidades públicas portuguesas, muitas vezes através de alojamento partilhado ou de produtos de terceiros. O CNCS/CERT.PT emitiu alertas sobre o tema e recomenda a atualização imediata das instalações afetadas.

Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de vulnerabilidades e a segurança da cadeia de abastecimento fazem parte das medidas obrigatórias, e um comprometimento com impacto relevante pode ter de ser notificado ao CNCS. Como as falhas podem expor dados em memória, incluindo credenciais e dados de clientes, um incidente pode também envolver obrigações ao abrigo do RGPD, como a notificação à CNPD no prazo de 72 horas em caso de violação de dados pessoais. Para as PME sem equipa técnica, o passo mais simples é pedir ao fornecedor de alojamento que confirme por escrito que a versão do PHP já está corrigida.

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, com pontuação CVSS v4.0 de 9,2. Permitem execução remota de código sem autenticação em servidores que processam 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. Os ramos 8.1 e anteriores já não têm suporte oficial e devem ser migrados.

Basta atualizar o WordPress ou outro CMS?

Não. A falha está no interpretador PHP e não no CMS ou nos plugins, por isso é preciso atualizar o próprio PHP no servidor ou confirmar com o fornecedor de alojamento que isso já foi feito.

O que é a CVE-2026-115560?

É uma terceira falha, divulgada a 23 de outubro, que só afeta configurações de sessão invulgares e ainda não tem correção. A mitigação recomendada é definir session.upload_progress.enabled=0 até à próxima versão de manutenção.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelo CNCS, pelo CERT-EU, pela rede europeia de CSIRT, pelo Centro Canadiano de Cibersegurança, pela watchTowr, pela Unit 42, pela Google Cloud, pela Trend Micro e pela Reuters.