PHP2Shell: decidir sob CVE vazado, embargo quebrado e exploit incerto

A pergunta que chega antes de qualquer patch

21 de outubro de 2026. Chega no canal de segurança o link de dois CVEs com nota 9,2, apelido PHP2Shell, e a pergunta do CTO logo atrás: estamos expostos?

Cinco minutos depois, ninguém sabe responder. Não porque o time seja lento, mas porque a resposta depende de um dado que a maioria das empresas não mantém atualizado: a versão exata do runtime PHP que está rodando em cada serviço, em cada ambiente, incluindo aquele worker de fila que ninguém mexe desde 2023.

É nesse intervalo entre o anúncio e o inventário que o risco mora. E, neste caso, o anúncio veio acompanhado de uma segunda camada de ruído: parte da informação circulou fora do calendário combinado.

O que está ancorado, o que é relato e o que ninguém sabe ainda

Vale separar o que tem lastro do que é versão de terceiro, porque a decisão de parar uma esteira e aplicar patch emergencial precisa saber em que está se apoiando.

Afirmação	Lastro
São dois CVEs, CVE-2026-109618 e CVE-2026-109619, apelidados PHP2Shell, com nota 9,2 no CVSS v4.0	[A] Wikipedia
A causa está no gerenciamento de memória do PHP e o efeito descrito é execução remota de código	[A/P] relatos técnicos, com exploração a confirmar
Afetaria todas as versões a partir do PHP 5	[P] relato não verificado, sem advisory oficial confirmando escopo, causa técnica e versão corrigida no momento da apuração — WatchTowr
Versões corrigidas: 8.2.35, 8.3.36, 8.4.27 e 8.5.12	[A] arquivo de releases do php.net
Existência de exploit público	[Q] a Huntress declarou não ter construído PoC nem conhecido exploit público à época — Huntress

Repare na última linha. A Huntress não conhecia exploit público. A Chainguard justificou a liberação antecipada de imagens corrigidas citando relatos de exploração em andamento — Socket. As duas coisas podem ser verdade ao mesmo tempo, em momentos diferentes, com fontes diferentes. Para quem opera, isso não é detalhe: é a diferença entre um patch de rotina e um patch de madrugada.

A lição prática é desconfortável. Quando as fontes discordam sobre a existência de exploração, você não escolhe a versão mais confortável. Você assume a mais cara e trabalha para reduzir a incerteza com evidência do seu próprio ambiente.

O embargo quebrado muda o cálculo, não a conclusão

O pós-morte da PHP Foundation, publicado em 21 de outubro, descreve um processo de divulgação atravessado por identificadores de CVE vazados, uma demonstração de exploit publicada por acidente e a decisão da Chainguard de liberar antes do horário combinado. O mesmo texto reconhece que o trabalho sobre o problema de gerenciamento de memória travou repetidamente desde que os primeiros sinais apareceram, em 2024 — Socket, PHP Foundation.

Dois anos entre o primeiro sinal e a correção é o tipo de número que gera discussão sobre processo. Para o time que opera, o ponto é outro: sua janela de patch não é definida pelo calendário acordado entre vendor e pesquisadores. É definida pelo ator mais rápido da cadeia. Se alguém publicou imagem corrigida antes da hora, ou se um exploit de demonstração vazou, o relógio já estava andando sem você.

O gargalo real é o inventário

Aqui está o problema que sobrevive a qualquer disputa sobre embargo. A maior parte das empresas não sabe, com precisão, qual versão de PHP está em produção.

Os motivos são banais:

• O composer.json declara um intervalo de versões, não a versão instalada.
• A tag da imagem base flutua: php:8.2-apache hoje aponta para um patch diferente de três meses atrás.
• O mesmo produto roda em mais de um runtime: web, worker, cron, job de importação.
• Ambientes de homologação ficam expostos à internet e ninguém os inclui na contagem.
• Serviços legados rodam PHP como CGI dentro de uma stack que o time nem reconhece como PHP.

Coletar isso não é sofisticado, mas precisa ser feito no artefato que realmente executa, não na máquina de quem investiga:

# no container ou host que está servindo tráfego
php -r 'echo PHP_VERSION, PHP_EOL;'

# na imagem publicada, antes de promover
 docker run --rm <sua-imagem> php -r 'echo PHP_VERSION, PHP_EOL;'

Se a resposta não bater com o que está no repositório, você achou um problema maior do que o CVE.

Primeiras horas: uma ordem defensável

1. Liste os serviços PHP e onde rodam. Nome do serviço, ambiente, responsável, exposição à internet.
2. Priorize por exposição, não por criticidade declarada. Um serviço interno com nota baixa de negócio e um proxy público na frente é mais urgente do que o sistema principal atrás de VPN.
3. Aplique as versões corrigidas nos expostos primeiro — 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, conforme a linha em uso.
4. Verifique no artefato implantado. Patch aplicado no build e não promovido é patch inexistente.
5. Trate mitigação de borda como paliativo declarado. Regras de WAF reduzem exposição, mas não substituem runtime corrigido, e a cobertura delas depende do tráfego que você consegue inspecionar.
6. Registre horário, versão anterior, versão nova e quem aprovou. Isso vira auditoria depois.

O que costuma ficar para trás

Já escrevemos por que atualizar o PHP não basta para fechar o risco — aqui. O recorte que importa neste artigo é o da verificação: depois do deploy, sobram imagens antigas no registry, réplicas que não foram recicladas, processos que continuam rodando o binário anterior e ambientes secundários que ninguém reiniciou.

Um checklist curto resolve a maior parte disso: toda imagem em produção aponta para digest novo? Todos os processos foram reiniciados? Existe algum runtime fora do orquestrador? O ambiente de homologação está exposto?

A decisão precisa de rastro, não de memória

Em três meses, ninguém vai lembrar por que a janela de manutenção foi aberta naquela quinta. O que sustenta a decisão é o registro: quais serviços foram verificados, com qual evidência, o que ficou fora de cobertura e por quê.

Esse é o mesmo princípio que vale para qualquer laudo técnico: uma afirmação sem lastro não é diagnóstico, é opinião com carimbo. "Todos os serviços foram atualizados" só vale se cada um tiver a versão observada anexada.

Onde o ArchGenerator entra

O inventário do repositório registra linguagens e runtimes, e a superfície de ataque aponta runtimes fora de suporte com referência ao arquivo que sustenta o achado. A partir dos problemas selecionados na Central de Remediação, é possível gerar um Kit SDD de correção — com limites e custo apresentados antes da confirmação. O kit organiza o trabalho; ele não prova que o código foi corrigido nem que o patch foi implantado. Essa parte continua sendo execução e verificação do seu time.

O que o caso PHP2Shell deixa é simples de enunciar e chato de executar: antes de discutir quem quebrou o embargo, descubra qual versão está rodando no seu servidor. Quase sempre é aí que está a exposição de verdade.