PHP2Shell: a correção só termina quando o processo web troca de runtime

O PHP publicou correções emergenciais para CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell, com possibilidade de execução de código sem autenticação e leitura de memória sob determinadas condições.[1] O problema está no motor da linguagem, não depende de uma falha no framework e alcança versões desde o PHP 5.4.[1]

O que muda para quem desenvolve

As primeiras versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mas distribuições podem incorporar o remendo mantendo outra numeração de pacote.[1] A evidência operacional deve ser a correção efetivamente instalada, não uma comparação superficial entre números.

O cenário demonstrado varia entre mod_php e PHP-FPM: há diferenças nos caminhos alcançáveis e nas operações necessárias para exploração.[1] Isso impede tratar todas as instalações como idênticas, mas também impede declarar uma instalação segura apenas porque ela usa FPM.

A leitura de memória pode expor segredos de outras requisições, mesmo sem uma cadeia completa de execução de código.[1] Na análise de risco, confidencialidade precisa receber o mesmo cuidado que disponibilidade. Um serviço que continua respondendo pode ainda exigir investigação.

Como aplicar

Monte um inventário por serviço com imagem ou pacote, processo responsável pelo tráfego e responsável pela atualização. Confira separadamente o executável de terminal e o runtime usado pelo servidor web.

Atualizar somente o PHP de linha de comando não comprova a correção do atendimento HTTP; Apache, PHP-FPM e processos persistentes precisam receber a atualização e o reinício apropriado.[1]

Como verificação proposta, faça uma requisição normal antes e depois da mudança em homologação. Compare autenticação, upload, consumo de memória e registro de erros. Guarde a identificação da imagem implantada e a referência do boletim do pacote. Evite criar uma página pública de diagnóstico com informações do ambiente.

Defina também critérios de interrupção da implantação e uma alternativa segura de contenção. Reverter para uma imagem vulnerável não deve ser o plano automático para qualquer regressão.

Cuidados e limites

As mitigações publicadas bloqueiam caminhos específicos e não substituem a atualização; algumas envolvem mudanças no tratamento de memória com consequências de disponibilidade.[1] A correção introduz um limite rígido cujo acionamento encerra o processo sem executar manipuladores de encerramento.[1]

Teste, portanto, a recuperação de trabalhadores e o tratamento de operações interrompidas. Segundo a reportagem, houve tentativas de exploração e adaptações contra WAF, mas não confirmação de invasão bem-sucedida de um servidor específico na atualização consultada.[1] Não transforme tentativa em comprometimento confirmado, nem uma regra de borda em certificado de segurança.

Fonte

[1] Fonte: The Hacker News