PHP2Shell: o patch fecha a falha, a detecção fecha a janela

Em 21 de outubro de 2026, o projeto PHP corrigiu a CVE-2026-109618 e a CVE-2026-109619, apelidadas de PHP2Shell: execução remota de código sem autenticação em instalações que atendem requisições web. Os detalhes vazaram antes da data combinada, e a Amazon relata uma tentativa de exploração quatro dias antes da correção. O patch responde se a falha continua aberta. A pergunta que ele não responde é outra: alguém entrou enquanto ela estava aberta?

Este artigo resume o threat brief que a Network Secure publicou sobre o caso. Como é um evento em curso, separamos o que está confirmado por fonte primária (comunicado do PHP, advisories no GitHub, registros CVE/NVD) do que ainda é relato de quem observou o fato. O material é defensivo: não traz payloads nem instruções de exploração.

O que é o PHP2Shell

PHP2Shell é o nome informal de duas vulnerabilidades no núcleo do PHP — no runtime, não na aplicação. Atualizar WordPress, Drupal ou plugins não resolve. As duas exploram o tratamento de condições excepcionais: quando a memória acaba ou ocorre um erro fatal, o PHP abandona a operação sem a limpeza normal, e estruturas internas ficam parcialmente inicializadas ou apontando para memória já liberada.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — RCE via corrupção por falta de memória. Uma falha de alocação interrompe o PHP enquanto dados internos da requisição ainda não foram inicializados, e a limpeza trata esse estado inválido como válido. Com Apache mod_php, o ataque roda antes de qualquer código da aplicação.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — RCE via estado global obsoleto. Um estado de uma requisição sobrevive depois que a memória é liberada e é usado pela requisição seguinte no mesmo worker (use-after-free). Os casos validados incluem o progresso de upload de sessão, ativo por padrão, em mod_php e PHP-FPM. Também há divulgação de memória: dados que passaram pelo processo podem ser expostos mesmo sem execução de código.

O PHP atribuiu CVSS v4.0 de 9,2 a cada uma — complexidade alta, mas sem exigir autenticação nem interação do usuário. Para entender como ler essa nota, veja CVSS: o que é e como ler a nota de uma vulnerabilidade.

O que está confirmado e o que ainda é relato

Em 23/10, as duas CVEs não estavam no catálogo KEV da CISA, e o EPSS era de 11,6% e 6,0%. Esses indicadores mudam rápido; vale reconsultar. Se o tema é priorização, veja como priorizar vulnerabilidades com CVSS, EPSS e KEV.

Quem está exposto

O PHP considera em risco toda instalação que atende requisições web. A forma de execução muda a urgência:

• Apache com mod_php — prioridade máxima. RCE validada via HTTP nas duas CVEs, antes de qualquer código da aplicação.
• PHP-FPM — alta. CVE-2026-109619 validada no ciclo de sessão; CVE-2026-109618 suscetível por análise de código, sem exploit completo demonstrado.
• FrankenPHP, LiteSpeed e php-cgi — tratar como exposto. Estão na lista do PHP, mas não há validação pública por modo.

Novo em 23/10: CVE-2026-115560. O PHP publicou aviso informativo sobre outra falha no progresso de upload de sessão que atinge inclusive versões já corrigidas, mas só sob uma combinação incomum de configuração e código. O PHP não a classifica como parte do PHP2Shell. A mitigação é a mesma já indicada para a CVE-2026-109619: session.upload_progress.enabled=0.

Três armadilhas de inventário aparecem com frequência:

• php -v engana. O binário de linha de comando pode ser diferente do que roda no FPM ou no Apache.
• Workers em memória mantêm o código vulnerável até o reinício, mesmo com o pacote novo instalado.
• PHP de terceiros. O NVD já associa appliances de outros fabricantes às CVEs; hospedagens e painéis também entram na conta.

Quatro dias antes do patch

Entre 17 e 21 de outubro não havia CVE, patch nem assinatura. Nesse intervalo, só detecção comportamental e inteligência de ameaças podiam enxergar o ataque. A própria Amazon recomenda investigar a partir de 17/10.

Por que o patch não fecha a janela sozinho

A janela de exposição começa quando a falha passa a ser explorável por alguém que não o defensor e termina quando a organização comprova duas coisas: que o ativo deixou de ser explorável e que ninguém o explorou no intervalo. Gestão de vulnerabilidades cuida do primeiro fechamento; detecção e resposta, do segundo.

• Log sem erro não é prova de segurança. O próprio PHP adverte que a falha pode ocorrer antes de a mensagem ser escrita.
• “Corrigido” pode ser provisório. Workers antigos seguem em memória até o reinício, e a CVE-2026-115560 atinge versões já corrigidas.
• São dois relógios. O tempo de correção mede quanto a falha ficou aberta. O MTTD e o MTTR do SOC medem quanto tempo um invasor ficaria no ambiente sem ser notado e quanto levaria até ser contido. Um não substitui o outro.
• Inteligência externa não é evidência interna. Tentativas em honeypots provam que a falha é atacada no mundo, não que o seu servidor foi — nem que não foi.

Onde o ataque deixa rastros

A exploração em si pode não gerar log. O que o atacante faz depois quase sempre gera. Em termos conceituais, a cadeia é:

1. Requisição ao PHP
2. Falta de memória ou erro fatal
3. Estado inconsistente no worker
4. Execução de código no servidor

O código roda com os privilégios da conta do worker web. Isso não é acesso administrativo por si só, mas essa conta costuma ler arquivos de configuração, credenciais de banco e chaves de integração, e alcançar serviços internos. O sinal mais forte para o SOC está na pós-exploração.

O que caçar desde 17 de outubro

Sem IoCs publicados, a caça parte de hipóteses sobre comportamento. As seis abaixo foram escritas para servidores Linux que rodam PHP; registre o que não pôde ser verificado por falta de telemetria.

1. Worker web iniciando processos. apache2, httpd, php-fpm ou lsphp gerando shell, interpretadores ou utilitários de download (ATT&CK T1059.004, T1505.003). Fonte: EDR, auditd ou Sysmon for Linux.
2. Arquivos novos onde o servidor web escreve. Scripts ou binários criados após 17/10 em diretórios web, uploads, cache ou /tmp (T1505.003, T1105). Fonte: FIM, EDR, comparação com o repositório.
3. Saída de rede inédita. Conexões iniciadas pelo usuário do servidor web para destinos sem histórico (T1071, T1105). Fonte: firewall, NDR, proxy de saída, flow logs.
4. Erros fatais concentrados. “Memory exhausted”, timeouts e workers reiniciando, agrupados por rota, tipo de conteúdo ou origem (T1190). Fonte: logs do PHP, do PHP-FPM, do servidor web e do WAF.
5. Credenciais do servidor usadas em outro lugar. Leitura de .env e arquivos de configuração seguida de logins de contas de serviço a partir de origens novas (T1552.001, T1078).
6. Consumo anômalo de CPU por processos ligados ao servidor web, sem aumento correspondente de tráfego (T1496).

Havendo indício, trate como incidente, não como patch. Preserve memória, discos e logs do período antes de corrigir: reiniciar ou atualizar antes da coleta apaga exatamente o que a investigação precisa. Dada a divulgação de memória confirmada, avalie a rotação de credenciais, tokens e chaves usados pelos servidores expostos. Se precisar de apoio, veja Resposta a Incidentes.

Recomendações técnicas

Corrigir é a única solução completa; o resto compra tempo. Em caso de dúvida sobre um parâmetro, prevalece o advisory oficial do PHP.

1. Inventariar todo PHP — ramos paralelos, contêineres, painéis de hospedagem e appliances — com versão, modo de execução, exposição e dono.
2. Atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou para o pacote corrigido do fornecedor; nos ramos 7.4 a 8.1, backport ou migração. Reconstruir imagens de contêiner.
3. Reiniciar todos os processos que carregam PHP e confirmar que os workers em execução usam o build corrigido — não o php -v.
4. Desativar o progresso de upload de sessão com session.upload_progress.enabled=0 no php.ini, no pool do FPM ou na configuração do servidor (não via ini_set()), e manter mesmo após atualizar, até a release que corrigir a CVE-2026-115560.
5. No PHP 8.5, fatal_error_backtraces=0 de forma administrativa, o que remove o produtor do caso confirmado de RCE.
6. Limitar requisições: post_max_size conservador, limites de multipart no frontend e bloqueio de multipart onde a aplicação não o usa.
7. Cobrir os servidores PHP expostos com telemetria de processo e rede (EDR ou auditd, firewall ou NDR), não só logs de acesso, integrada ao SIEM ou XDR.
8. Usar o WAF como paliativo, não como solução: a Cloudflare observou tentativas de contornar suas regras, e tráfego direto à origem passa ao largo do WAF.

Para ativos que não podem ser corrigidos nem compensados, CERT-EU e o Centro Canadense de Cibersegurança recomendam isolá-los de redes públicas até que a correção seja aplicada e verificada.

Perguntas que a liderança deve fazer

• Quantos ativos expostos à internet rodam PHP, e quantos já têm remediação validada no runtime?
• Revisamos sinais de exploração desde 17/10? Com que cobertura de telemetria, e o que ficou sem cobertura?
• Se um servidor tivesse sido comprometido em 18/10, quando teríamos sabido?
• Quem pode decidir isolar um serviço às 3h da manhã de um sábado?
• Que riscos foram aceitos, por quem, com qual controle compensatório e até quando?

As primeiras provas de conceito surgiram por volta das 2h UTC de uma terça-feira. Montar essa cobertura internamente pede escala de turnos, SIEM, SOAR, Threat Intelligence e uma equipe difícil de contratar e reter. Muitas empresas combinam os dois modelos: o time interno mantém o contexto e as decisões de negócio, e o SOC como serviço garante a vigilância contínua e a primeira resposta. A comparação está em SIEM, MDR ou SOC as a Service.

Como o SOC e o MDR da Network Secure atuam em um caso assim

Uma falha sem IoC gera sinais fracos e dispersos: um erro fatal aqui, um processo filho ali, uma conexão nova acolá. Isolados, nenhum justifica alarme; correlacionados no mesmo host e na mesma janela de tempo, contam uma história. No SOC 24×7 e MDR da Network Secure, a plataforma Open-XDR coleta telemetria de endpoint, rede, nuvem, identidade e firewalls; a IA faz a triagem e a correlação; o analista valida o que é crítico, mapeia o ataque no MITRE ATT&CK, conduz a contenção e entrega uma notificação que o seu time consegue executar. O SOC é certificado ISO/IEC 27001:2022, com auditoria do Bureau Veritas.

Para deixar claro o limite: não afirmamos ter detectado exploração do PHP2Shell em clientes, nem que algum serviço identifique a falha automaticamente. Aplicar patches e reiniciar serviços continua sendo responsabilidade de quem opera cada ativo, salvo contrato específico.

Perguntas frequentes

O que é o PHP2Shell?

É o nome informal de duas vulnerabilidades críticas no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619, corrigidas em 21/10/2026. Elas permitem execução remota de código sem autenticação em instalações que atendem requisições web.

Quais versões do PHP corrigem o PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Os ramos 8.1, 8.0 e 7.4 não têm release oficial, apenas backports mínimos em código-fonte ou pacotes de fornecedores LTS; da 7.3 para trás não há correção.

Atualizar o WordPress ou os plugins resolve?

Não. A falha está no runtime do PHP, não na aplicação. É preciso atualizar o PHP e reiniciar todos os processos que o carregam.

Se eu já apliquei o patch, preciso fazer mais alguma coisa?

Sim. Confirme que os workers em execução usam o build corrigido, mantenha session.upload_progress.enabled=0 até a correção da CVE-2026-115560 e investigue sinais de exploração desde 17/10/2026, quando surgiram as primeiras tentativas relatadas.

Existem indicadores de comprometimento (IoCs) do PHP2Shell?

Até 23/10/2026, nenhuma fonte primária havia publicado IoCs, atores ou campanhas associados. A detecção depende de comportamento: processos iniciados pelo worker web, arquivos novos em diretórios web e conexões de saída inéditas.

Fontes consultadas até 23 de outubro de 2026: comunicados de segurança do PHP de 21/10 e 23/10; advisories GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp; registros do NVD; catálogo KEV da CISA (versão 2026.10.23); EPSS da FIRST; CERT-EU, advisory 2026-018; Canadian Centre for Cyber Security, AL26-026; publicações da Wiz Research, Amazon Threat Intelligence, Cloudflare, Qualys, watchTowr e Field Effect. Status no KEV, EPSS e indicadores mudam com frequência. As hipóteses de caça são derivação técnica da Network Secure, não indicadores publicados.

Referências oficiais

• Security advisory: critical remote code execution vulnerabilities (21/10/2026) — The PHP Group
• Informational advisory: session upload progress, CVE-2026-115560 (23/10/2026) — The PHP Group
• GHSA-w8hw-w9fx-j79w — RCE via OOM corruption (CVE-2026-109618) — PHP/GitHub
• GHSA-6wmf-4rv5-p3rp — RCE via stale global state (CVE-2026-109619) — PHP/GitHub
• CVE-2026-109618 Detail — NIST NVD
• CVE-2026-109619 Detail — NIST NVD
• CISA — Known Exploited Vulnerabilities Catalog
• Security Advisory 2026-018 — Critical Vulnerabilities in PHP — CERT-EU
• PHP2Shell: AI uncovers critical RCE vulnerabilities — Wiz Research
• PHP2Shell exploitation prior to public disclosure in MadPot — Amazon Threat Intelligence
• Cloudflare deploys protections against php2shell — Cloudflare