Hoje o PHP publicou a correção de emergência para duas falhas críticas que vazaram antes da hora. O nome que a comunidade deu ao caso já entrega a gravidade: PHP2Shell.
O que se sabe, com fonte: as duas vulnerabilidades, CVE-2026-109618 e CVE-2026-109619, têm severidade 9.2 Critical e permitem execução remota sem autenticação. E o PHP roda em torno de sete em cada dez sites da web.
Como as duas falhas funcionam
No primeiro caminho, o tratamento de estouro de memória interrompe o PHP com dados internos inicializados pela metade, e a limpeza da requisição trata o inválido como válido. No segundo, o estado interno de uma requisição sobrevive à memória que o sustentava, e a requisição seguinte no mesmo worker usa esse estado antes do reset.
O caminho confirmado passa pelo session.upload_progress: uma feature legada que vem ligada por padrão e que a maioria dos desenvolvedores esqueceu que existe. Superfície de ataque é, quase sempre, o que ficou ligado desde a instalação.
A cronologia é a aula
Os detalhes vazaram antes do prazo combinado, a prova de conceito ficou pública em horas, e a correção de emergência saiu no dia seguinte ao vazamento, com o PHP exercendo justamente a cláusula que tinha escrito no aviso: lançar antes se os detalhes virarem públicos ou se houver exploração ativa.
E o pior cenário está sem rodeio no aviso oficial: todas as instalações que servem web, com o mod_php como o caso grave, onde existe exploit demonstrado que roda antes de qualquer linha do seu código.
A resposta do mercado, no mesmo dia
Cloudflare ligou proteções na borda, fornecedores de hospedagem publicaram regras próprias, e a orientação europeia de cibersegurança recomendou tirar do ar o site exposto que não puder ser corrigido. Centenas de sites já estão offline de forma preventiva.
É a resposta que a gravidade pede: RCE sem autenticação num runtime de sete em cada dez sites não é ciclo mensal de patch, é emergência com site offline preventivo como medida legítima.
O que fazer hoje, nesta ordem
- Atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (o aviso oficial diz que mitigação não substitui correção).
- Confirmar o pacote do seu fornecedor: distribuições receberam os patches com antecedência.
- Se não couber hoje: desligar a feature de sessão comprometida com reinício de todos os workers e apertar limites de memória e de tamanho de POST na borda.
- Migrar de linha quem está no PHP 8.1 ou mais velho: essas versões não recebem mais correção do projeto.
Na Tech86, esse foi o trabalho do dia para os clientes: inventariar o que roda PHP em cada host, aplicar a correção ou mitigação e documentar, no mesmo desenho de operação que aplicou o patch do core do WordPress na semana passada.
Conclusão
O PHP2Shell fecha a semana em que runtimes viraram alvo em massa, e a reflexão que fica é a do inventário: a feature vulnerável era uma que a maioria esqueceu que existia, ligada por padrão desde sempre.
Patch hoje, migração de linha na semana, e o inventário de features ligadas por padrão no backlog permanente. O boletim informa; o inventário protege.