PHP2Shell: o que está confirmado e o que fazer agora

Em 21 de outubro de 2026, o projeto PHP corrigiu duas falhas no motor da linguagem, CVE-2026-109618 e CVE-2026-109619, apelidadas de PHP2Shell. As duas permitem execução remota de código sem autenticação em servidores que atendem requisições web. Os detalhes vazaram antes da divulgação coordenada, a Amazon relata uma tentativa de exploração quatro dias antes do patch e, dois dias depois da correção, o PHP publicou um aviso sobre uma falha relacionada que afeta inclusive as versões já corrigidas.

Este artigo resume o threat brief que publicamos sobre o caso. O evento ainda está em curso e circularam versões conflitantes sobre escopo, pontuação e exploração, por isso cada afirmação abaixo traz o estado da evidência: confirmado (fonte primária verificável), reportado (fonte identificada, sem confirmação independente), inferido ou desconhecido. As fontes foram consultadas em 23/10/2026.

O que está confirmado e o que ainda é relato

A falha não está na aplicação, está no runtime

Como o defeito está no interpretador, uma aplicação sem nenhum erro próprio pode estar exposta, e atualizar WordPress, Drupal ou plugins não resolve. As duas falhas exploram o tratamento de condições excepcionais: quando a memória acaba ou ocorre um erro fatal no meio de uma requisição, 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, corrupção por falta de memória. Uma falha de alocação interrompe o PHP quando a memória da requisição já está acessível, mas ainda não inicializada; o encerramento da requisição usa esse estado inválido. Com mod_php, isso ocorre antes de qualquer código da aplicação.
• CVE-2026-109619, estado global obsoleto. Estado de uma requisição sobrevive depois que sua memória é liberada e é consumido pela requisição seguinte no mesmo worker, um use-after-free. Os casos confirmados são os backtraces de erro fatal do PHP 8.5 e o ciclo de progresso de upload de sessão, ativo por padrão.

O resultado, segundo os advisories, é execução de código com os privilégios da conta do worker web. Isso não é, por si só, acesso administrativo ao sistema operacional. Na prática, porém, essa conta costuma ler arquivos de configuração, credenciais de banco de dados e chaves de integração, e alcançar serviços internos a partir do servidor (inferido). Nenhuma campanha, ator ou conjunto de indicadores de comprometimento foi associado ao PHP2Shell nas fontes primárias consultadas.

Quem está exposto

O PHP considera em risco qualquer instalação que atende requisições web. Os modos de execução diferem no que já foi demonstrado, não na existência da falha: a ordem abaixo é de urgência, não uma lista de quem pode esperar.

Versões corrigidas e as armadilhas do "já atualizamos"

As versões corrigidas são 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 distribuições e fornecedores LTS. Os ramos 7.3 e anteriores não têm correção: o caminho é migrar, isolar ou retirar do ar. Três armadilhas aparecem no processo:

• O php -v engana. O binário de linha de comando pode ter versão diferente do que roda no FPM ou no Apache. A verificação vale no runtime que atende a web.
• Workers em memória. Processos em execução mantêm o código vulnerável até serem reiniciados, o que pesa na CVE-2026-109619.
• PHP de terceiros. O NVD já associa às duas CVEs configurações de appliances de outros fabricantes. Painéis de hospedagem, contêineres e produtos que embarcam PHP também precisam entrar no inventário.

CVE-2026-115560: corrigido pode ser um estado provisório

Em 23 de outubro, o PHP publicou um aviso informativo sobre outra falha no progresso de upload de sessão. Ela não faz parte das correções de 21 de outubro e afeta também as versões já corrigidas, mas só quando a aplicação define session.serialize_handler como php_binary ou php_serialize e o troca para php em tempo de execução, antes de session_start(), com o progresso de upload ativo. O próprio PHP descreve o vetor como improvável, não a classifica como parte do PHP2Shell e tratará a correção na próxima release regular. O registro na CVE está como reserved, sem CVSS.

O que muda na decisão. Atualizar continua necessário, mas deixou de ser suficiente para fechar todos os vetores do progresso de upload. A mitigação é a mesma já recomendada para a CVE-2026-109619, session.upload_progress.enabled=0, que agora deve ser mantida mesmo depois da atualização, até a próxima release. Onde o recurso não é usado, desativá-lo é uma decisão de baixo custo que cobre os dois casos.

Um 9,2 não é um risco de negócio

O CVSS mede a gravidade intrínseca da falha em condições genéricas. Ele não sabe se o servidor está exposto, se há exploração em curso nem o que o servidor sustenta. No PHP2Shell, três perguntas diferentes pedem três fontes diferentes:

• Severidade: CVSS 9,2, com acesso pela rede, sem privilégio, sem interação e com complexidade alta. Veja como ler a nota do CVSS 4.0.
• Probabilidade: exposição, modo de execução, provas de conceito públicas, tentativas observadas e controles na frente do ativo. Em 23/10, o EPSS estimava 11,6% para a CVE-2026-109618 (percentil 96) e 6,0% para a CVE-2026-109619 (percentil 93) nos 30 dias seguintes. Nenhuma das duas constava do catálogo KEV da CISA na versão 2026.10.23, o que indica falta de confirmação suficiente, não baixo risco.
• Risco de negócio: dados processados, credenciais guardadas, serviços alcançáveis e processos que param. Essa resposta vem do inventário, da BIA e da gestão de riscos.

Para a ordem de grandeza: a W3Techs mede PHP em 69,3% dos sites cuja linguagem de servidor é identificável. O número não mede versão nem exposição. As telemetrias de fornecedores que circularam descrevem as próprias bases, não são comparáveis entre si e nenhuma mede instalações efetivamente exploráveis; o PDF traz cada uma com o que conta, o método e o que não prova. O artigo sobre priorizar vulnerabilidades com CVSS, EPSS e KEV aprofunda essa combinação.

Cronologia resumida

Se o relato da Amazon estiver correto, alguém testava a falha antes de existir correção: a própria Amazon recomenda iniciar investigações a partir de 17/10. Exploit em laboratório, exploit publicado, tentativa observada, exploração bem-sucedida e comprometimento confirmado são estados distintos. Até 23/10, as fontes primárias registram os três primeiros.

O que fazer agora

As medidas estão organizadas pelo efeito que produzem. Só a primeira remove a falha; as demais compram tempo ou apoiam a investigação. Em caso de dúvida sobre um parâmetro, prevalece o advisory oficial.

1. Correção definitiva. Atualizar para as versões corrigidas ou para o pacote corrigido do fornecedor, reconstruir imagens de contêiner, reiniciar todos os processos que carregam PHP e confirmar o build no runtime em execução. Priorizar ativos voltados à internet com mod_php, depois os demais expostos e, por fim, os internos, pela criticidade de negócio.
2. Mitigação temporária. session.upload_progress.enabled=0 na configuração do servidor ou do pool, não via ini_set(); fatal_error_backtraces=0 no PHP 8.5. O memory_limit=-1 não é mitigação completa e aumenta o risco de indisponibilidade: só como medida curta, com limite de memória por worker e limites de requisição no frontend.
3. Redução de exposição. Inventariar todo PHP, inclusive em contêineres, painéis e appliances, com versão, modo de execução, exposição e dono. Aplicar post_max_size conservador e limites de corpo e de partes multipart no frontend. Tratar o WAF como paliativo: a Cloudflare observou mutações de payload para contornar as regras, e tráfego direto à origem passa por fora dele.
4. Monitoramento e investigação. Revisar logs desde pelo menos 17/10 em busca dos sinais listados pelo PHP: avisos e erros antes da execução de scripts, erros fatais e timeouts concentrados em rotas e uploads. A ausência de erro em log não prova segurança. Pela divulgação de memória confirmada, avaliar a rotação de credenciais e chaves dos servidores expostos (inferido).
5. Isolamento ou retirada de serviço. Para o que não pode ser corrigido nem compensado, incluindo os ramos 7.3 e anteriores, CERT-EU e CCCS recomendam isolar as aplicações expostas de redes públicas até a correção ser aplicada e verificada.

Perguntas que a diretoria deve fazer

• Quantos ativos expostos à internet rodam PHP, e quantos já têm remediação validada no runtime?
• Quais estão em versões sem correção oficial, e qual é o plano para cada um?
• Que riscos foram aceitos, por quem, com qual controle compensatório e até quando?
• Quais terceiros e appliances operam PHP em nosso nome, e o que eles confirmaram?
• Revisamos sinais de exploração desde 17/10? Com que cobertura de logs?
• Quanto tempo levamos para responder à pergunta "onde estamos expostos"?

Nenhuma estratégia de tratamento é automática. Mitigar, evitar (isolar ou desligar), transferir parte da consequência a terceiros ou aceitar o risco residual são decisões que precisam de dono, alçada, justificativa, controle compensatório verificado e data de revisão. Esse registro é o que permite responder a auditores, reguladores e clientes, e o que impede que um aceite temporário vire permanente por esquecimento. Hospedagens e fabricantes de appliances entram na mesma conta: o tema conversa com a gestão de risco de terceiros.

Onde o Eagle entra, e onde não entra

Bloquear tráfego de exploração, aplicar patches, reiniciar serviços e detectar exploração em tempo real são funções de WAF, gestão de patches, EDR e SIEM. O Eagle não substitui essas ferramentas nem os scanners de vulnerabilidade: ele integra e contextualiza os dados que elas produzem. No PHP2Shell, isso significa:

• Cyber Exposure Management: consolidar ativos, versões e responsáveis num registro usado pelas demais análises, associar achados de scanners aos ativos e sinais de ameaça e criticidade do ativo à priorização. Conectores específicos dependem de integração configurada.
• Business Continuity Management: ligar ativos a processos, MTPD, RTO e RPO para ordenar a correção pela consequência.
• Cyber Risk Management: modelar cenários do risco inerente ao residual, com controles e tratamento, e avaliação qualitativa e quantitativa quando houver dados. Veja o que muda com Cyber Risk Quantification.
• Governance, Risk & Compliance e Third-Party Risk Management: acompanhar controles, evidências e planos de ação, e registrar fornecedores, criticidade e seus planos.

O valor está no registro rastreável da decisão, não em substituir o julgamento de quem decide. O threat brief detalha esse quadro de capacidades e deixa claro o que está fora do escopo da plataforma.

Fontes: comunicados do PHP de 21 e 23/10/2026, advisories GHSA, registros NVD e CVE, feed do KEV (versão 2026.10.23), API do EPSS, alertas da CERT-EU e do CCCS e publicações originais de Wiz, Amazon e Cloudflare, consultados em 23/10/2026. Status no KEV, EPSS e indicadores de comprometimento mudam com frequência; confira as fontes antes de decidir. Material educativo e defensivo, sem payloads nem instruções de exploração.