PHP2Shell: duas falhas críticas do PHP permitem executar código em servidores web sem autenticação

A 21 de outubro de 2026, o projeto PHP publicou de urgência as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir CVE-2026-109618 e CVE-2026-109619, duas falhas de memória que permitem a um atacante sem credenciais executar código através de um pedido HTTP manipulado. O CERT-FR emitiu um alerta: todas as instalações PHP que servem tráfego web devem ser atualizadas, incluindo os antigos ramos 7.x e 8.0–8.1.

O que aconteceu

A 21 de outubro de 2026, o projeto PHP lançou uma atualização de segurança crítica, PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que corrige duas falhas de execução remota de código apelidadas PHP2Shell, cada uma classificada com 9,2 em CVSS 4.0. O CERT-FR publicou no mesmo dia o alerta CERTFR-2026-ALE-014. A CVE-2026-109618 resulta da gestão da falta de memória: um pedido pode ser interrompido quando os seus dados internos estão apenas parcialmente inicializados, e a fase de limpeza usa depois esses dados inválidos. Pedidos multipart sobredimensionados são uma forma de a desencadear. A CVE-2026-109619 é um use-after-free: o estado deixado por um pedido sobrevive no processo de trabalho e é reutilizado por um pedido seguinte.

Quem é afetado

Segundo o php.net, todas as instalações que servem pedidos web estão abrangidas: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Os avisos do PHP indicam que a execução completa de código sem autenticação foi validada contra o mod_php na configuração por omissão e, para a segunda falha, contra o FPM. O CERT-FR considera vulneráveis todas as versões 5.x, 6.x, 7.x, 8.0 e 8.1; excecionalmente, a equipa do PHP publicou correções mínimas em código-fonte para os ramos 7.4, 8.0 e 8.1, já sem suporte. As fontes oficiais não referiam exploração ativa no momento da redação; segundo a ZATAZ, circulam demonstrações em fóruns. WordPress, Drupal, Joomla e as aplicações internas assentam todos em PHP.

O que fazer agora

1. Inventarie as versões do PHP em cada servidor e contentor: php -v, verificando a versão realmente usada pelo servidor web (pool FPM, módulo Apache).
2. Atualize para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou instale os pacotes corrigidos da sua distribuição (apt update && apt upgrade, dnf upgrade 'php*'), e depois reinicie o PHP-FPM ou o Apache para que nenhum processo antigo continue ativo.
3. Se não puder corrigir hoje: defina session.upload_progress.enabled = Off no php.ini, como recomenda o CERT-FR, e fatal_error_backtraces como Off; a equipa do PHP avisa que estas definições não cobrem todos os vetores de ataque.
4. Em 7.4 a 8.1: aplique já as correções retroportadas ou as do seu fornecedor e planeie a migração para um ramo suportado (o próprio 8.2 termina a 31 de dezembro de 2026).
5. Vigie os registos: falhas de processos PHP, erros de memória esgotada e ficheiros inesperados nos diretórios web.

A nossa opinião

O PHP está por baixo de grande parte dos sites empresariais, muitas vezes em versões que ninguém se lembra de ter instalado. Estas falhas lembram que é preciso inventariar os ambientes de execução, e não apenas as aplicações, e tratar um ramo PHP em fim de vida como um risco a eliminar, não como uma herança a tolerar.

Fontes

• PHP — Critical security release: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
• CERT-FR — CERTFR-2026-ALE-014 : Multiples vulnérabilités dans PHP
• PHP (GitHub security advisory) — RCE via OOM corruption
• PHP (GitHub security advisory) — RCE via stale global state
• ZATAZ — PHP2Shell : deux failles critiques menacent les serveurs web

Como escolhemos, verificamos e escrevemos nossas análises →