Hoje, 21 de outubro de 2026, a equipa de segurança do PHP publicou um aviso de emergência: duas vulnerabilidades críticas no núcleo da linguagem, denominadas coletivamente PHP2Shell, permitem a um atacante executar código remotamente e sem autenticação em qualquer servidor que sirva PHP na web. Não é uma falha do WordPress, nem um plugin, nem uma configuração errada tua – está no intérprete.

A gravidade máxima vem de um detalhe técnico importante: o pedido malicioso é processado antes de uma única linha do seu código ser executada. Não importa quão bem escrita esteja a sua aplicação — login, validações, WAF da aplicação — porque o ataque ocorre dentro do próprio PHP durante a preparação do pedido.

As duas novas entradas na CVE

Ambos partilham a mesma causa raiz — o PHP pode deixar a sua memória corrompida quando um pedido termina de forma anómala — mas são explorados de formas diferentes. Cada um tem uma pontuação CVSS de 9,2 (crítico):

  • CVE-2026-109618 — O tratamento de erros fora de memória (OOM) pode interromper o PHP enquanto os dados internos do pedido estão apenas parcialmente inicializados. A limpeza subsequente de pedidos trata esses dados inválidos como válidos, resultando em corrupção de memória e execução remota de código com privilégios de trabalhadores web.
  • CVE-2026-109619 — O estado interno pertencente a um pedido pode sobreviver depois de a sua memória ter sido libertada. Um pedido subsequente servido pelo mesmo trabalhador pode usar esse estado obsoleto antes de a inicialização normal o reiniciar: usar depois da liberdade no heap, divulgação de memória e, novamente, execução remota de código sem autenticação.

Afetam todas as instalações PHP que servem pedidos web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A equipa PHP considera o risco mais elevado em mod_php, onde já existe um exploit comprovado que é ativado antes do código da aplicação ser executado.

Páginas afetadas

Auditámos toda a nossa infraestrutura e estas são as páginas que servem PHP com versões abaixo das corrigidas — ou seja, vulneráveis até que a atualização seja aplicada:

  • PHP 8.3.35 (vulnerável, requer 8.3.36): www.io-backup.com, www.dynamicdnspro.com, www.fisem.com.
  • PHP 8.4.25 (vulnerável, requer 8.4.27): www.emhaseasociados.es, app.emhaseasociados.es.
  • PHP 8.4.26 (vulnerável, requer 8.4.27): scanner.net-analyzer.com, app.fisem.com, buy.dynamicdnspro.com.

Se gerir os seus próprios sites, pode verificar a versão que expõe cada um com curl -sI https://tudominio.com | grep -i x-powered-by. Nota: só porque o cabeçalho não aparece não significa que esteja seguro, apenas que o servidor não o anuncia.

Medidas urgentes

A única correção completa é atualizar o PHP. As versões com o patch são:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Para PHP 8.1 e anteriores — fora de suporte — a equipa PHP lançou backports mínimos para 7.4, 8.0 e 8.1, mas a recomendação oficial é migrar para um branch suportado. Entretanto, aqui estão as medidas que estamos a implementar e a recomendar:

  1. Atualize o mais rapidamente possível para a versão atualizada do seu ramo, priorizando servidores expostos à Internet.
  2. Mitigação parcial imediata: desativar session.upload_progress.enabled=0 em php.ini y, em PHP 8.5, também fatal_error_backtraces=0. Reiniciar todos os trabalhadores após a alteração. Nota: segundo as análises do Datadog e JFrog, esta mitigação é parcial, não completa — não substitui o patch.
  3. Corrigir memory_limit=-1 em vez de usar limites RLIMIT, para reduzir os caminhos de corrupção por OOM.
  4. Filtro na borda: Um WAF ou reverse proxy à frente do PHP pode bloquear pedidos multipartes anómalos antes de chegarem ao parser vulnerável.
  5. Monitor: Verifica os registos para submissões de formulários muito grandes, erros de esgotamento de memória durante a inicialização dos pedidos e processos shell inesperados lançados por trabalhadores PHP.

Se não puder atualizar imediatamente, a CISA recomenda até desligar sistemas PHP expostos até que possam ser corrigidos. É uma recomendação drástica para uma vulnerabilidade drástica.

Conclusão

O PHP2Shell é um dos bugs que só aparece de poucos em poucos anos: crítico, sem autenticação e na camada abaixo de qualquer aplicação. O patch já existe e a sua aplicação demora apenas minutos na maioria dos sistemas. Já estamos a atualizar todas as páginas afetadas listadas acima; se tiver algum site servido com PHP, este é o momento para fazer o mesmo.