PHP2Shell: CISA confirma exploração ativa e prazo é 29/10

A CISA confirmou exploração ativa das falhas CVE-2026-109618 e CVE-2026-109619 no núcleo do PHP — batizadas de PHP2Shell — e incluiu as duas no catálogo Known Exploited Vulnerabilities (KEV) em 26 de outubro. Agências federais americanas têm até 29 de outubro para aplicar a correção. Ambas têm CVSS 9,2 e permitem execução remota de código por atacante não autenticado: o pior cenário possível para um servidor PHP exposto à internet.

Quem é afetado

As duas falhas atingem múltiplas versões do PHP. A tabela abaixo é a mesma publicada pelo Canadian Centre for Cyber Security (CCCS) e pela Fundação PHP:

• PHP 8.5.x anterior à 8.5.12 → corrigido na 8.5.12
• PHP 8.4.x anterior à 8.4.27 → corrigido na 8.4.27
• PHP 8.3.x anterior à 8.3.36 → corrigido na 8.3.36
• PHP 8.2.x anterior à 8.2.35 → corrigido na 8.2.35
• PHP 7.4 a 8.1: sem release oficial — a equipe de segurança do PHP publicou apenas backports mínimos de código-fonte. Consulte o mantenedor da sua distribuição.
• PHP 5.4 a 7.3: fora do ciclo de suporte, sem correção do projeto.

Todo PHP que atende requisições web está em risco — PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed inclusive. O próprio projeto PHP classifica o mod_php como o cenário de maior exposição.

Como a exploração escalou

• 17/10 — a Amazon Threat Intelligence detecta tentativa de exploração contra sua rede de honeypots MadPot, quatro dias antes da divulgação pública.
• 20/10 — o PHP emite aviso prévio de correção de segurança.
• 21/10, 14h UTC — o PHP lança as correções, antecipadas de 22 para 21 depois que os identificadores CVE vazaram. Cloudflare e Amazon já registram tentativas crescentes de exploração; a watchTowr confirma ataques contra as duas CVEs.
• 23/10 — o FBI (IC3) publica alerta público pedindo patch imediato.
• 24/10 — o pesquisador Adel Karimi reporta exploração bem-sucedida contra honeypots rodando PHP 8.4.26, batendo na CVE-2026-109618.
• 26/10 — a Trail of Bits confirma exploits funcionais contra PHP 8.2 a 8.5 não corrigidos; a CISA adiciona as duas CVEs ao catálogo KEV.
• Hoje — a Amazon classifica a exploração como amplamente disseminada.

Vale uma ressalva sobre o número: identificadores pré-divulgação circularam com CVSS 10,0. A pontuação final publicada pela Fundação PHP é 9,2 — é essa que vale para priorização.

O que fazer agora

1. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 imediatamente, priorizando qualquer sistema exposto à internet.
2. Em PHP 7.4 a 8.1, fora do suporte oficial, busque o backport de segurança da sua distribuição Linux ou fornecedor LTS — não existe patch oficial do projeto PHP para essas versões.
3. Mapeie containers, appliances e produtos de terceiros que empacotam uma versão própria de PHP; é o lugar onde esse tipo de falha costuma ficar esquecido.
4. Existe uma falha relacionada, a CVE-2026-115560, que o patch de 21/10 não corrige. Enquanto não houver correção, mitigue desativando session.upload_progress.enabled=0. Quem já aplicou isso para a CVE-2026-109619 não precisa repetir.
5. Se não puder corrigir agora, isole o servidor da rede pública e revise logs de servidor web, autenticação e processos por atividade suspeita.

Perguntas frequentes

O PHP2Shell exige autenticação para ser explorado?
Não. As duas CVEs permitem execução remota de código por atacante não autenticado.

Qual é o CVSS real da falha?
9,2, segundo a pontuação final da Fundação PHP. Identificadores vazados antes do lançamento circularam com nota 10,0, que não é a oficial.

Minha versão do PHP já está fora de suporte — o que fazer?
Atualize para uma versão com suporte ativo (8.2 ou superior) ou, se isso não for viável no curto prazo, busque o backport do seu fornecedor Linux/LTS e isole o servidor da internet até aplicar a correção.

Só servidores com mod_php estão em risco?
Não. PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed estão todos expostos; o próprio projeto PHP classifica o mod_php como o cenário de maior risco.

Conclusão

Com exploração ativa confirmada e um prazo federal batendo na porta — 29 de outubro —, a prioridade é aplicar o patch hoje, não auditar o impacto primeiro. Quem roda PHP em produção e ainda não atualizou para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 está na janela de maior risco: a exploração começou quatro dias antes da divulgação pública e, segundo a Amazon, já está amplamente disseminada.