PHP2Shell: corrigir o pacote não basta para confirmar o servidor em execução

Honeypots de Adel Karimi registraram execução remota bem-sucedida das vulnerabilidades PHP2Shell, CVE-2026-109618 e CVE-2026-109619, contra Apache mod_php com PHP 8.4.26.[4] Marcus Hutchins, da Expel, examinou os registros e considerou a evidência particularmente sólida.[4] A novidade é a confirmação funcional, não apenas a existência de tentativas.

Para operação de software, essa diferença deve alterar a prioridade da resposta. Minha recomendação é tratar atualização e investigação como entregas distintas, cada uma com responsável e evidência de conclusão.

O que muda para quem desenvolve

A análise correlacionou um vazamento de memória utilizável com uma carga posterior de execução: um endereço de função extraído dos dados vazados reapareceu na etapa seguinte, e o comando foi executado logo após a requisição.[4] As correções emergenciais haviam sido publicadas em 21 de outubro.[4]

Isso ajuda a separar três afirmações que não deveriam virar sinônimos no acompanhamento operacional: o serviço recebeu uma requisição suspeita, houve uma tentativa de exploração e o atacante conseguiu executar código. O nível de evidência muda as decisões de contenção, mas uma investigação ainda incompleta não é justificativa para adiar a correção.

Outro ponto de atenção é o alvo real da mudança. Recomendo registrar o processo web atendendo a aplicação, seu modo de carregamento do PHP e a imagem ou pacote de origem, em vez de encerrar o chamado com base apenas na versão encontrada no terminal.

Como aplicar

Comece por um inventário dos serviços expostos que usam PHP, incluindo aplicações antigas e imagens de containers. Para cada entrada, associe o artefato implantado à versão efetivamente carregada pelo serviço. Valide a mudança em um ambiente de homologação antes de ampliar a implantação.

Um exercício simples é selecionar uma aplicação representativa e reunir três evidências: versão do artefato corrigido, identificação da implantação que o utiliza e resposta funcional após o reinício ou substituição do processo. Faça a observação por um mecanismo administrativo restrito. Não crie uma página pública de diagnóstico para provar que a atualização aconteceu.

Em paralelo, preserve registros relevantes e investigue atividade suspeita anterior à atualização. Defina o que seria evidência de comprometimento e qual procedimento será seguido se ela aparecer.

Cuidados e limites

As tentativas anteriormente descritas por várias empresas incluíam varredura, identificação de alvos e exploração sem sucesso; a nova confirmação não transforma retroativamente todas elas em invasões comprovadas.[4]

Há uma falha distinta, CVE-2026-115560, sem correção na data da reportagem e dependente de uma combinação incomum de configuração e código.[4] Para ela, o projeto orienta desabilitar session.upload_progress.enabled, medida que não substitui os patches de PHP2Shell.[4] Mantenha essas duas frentes separadas no plano de ação para não aplicar uma mitigação correta ao problema errado.

Fonte

[4] Fonte: BleepingComputer