Falhas no núcleo do PHP permitem execução remota sem autenticação
O projeto PHP lançou, em 21 de outubro, atualizações emergenciais para corrigir duas vulnerabilidades críticas no núcleo da linguagem. Identificadas como CVE-2026-109618 e CVE-2026-109619, as falhas foram agrupadas sob o nome PHP2Shell e receberam pontuação 9,2 na escala CVSS 4.0. Em determinadas condições, elas podem permitir que um invasor execute código remotamente sem apresentar credenciais.
A primeira vulnerabilidade, CVE-2026-109618, está relacionada ao tratamento de situações de falta de memória. O uso de `longjmp` pode interromper a inicialização de dados associados a uma requisição. Mais tarde, ao encerrar o processamento, o PHP pode tentar operar sobre informações inválidas. Entre as situações capazes de acionar o problema estão requisições multipart com grande quantidade de cabeçalhos e envios de arquivos vazios.
A segunda falha, CVE-2026-109619, envolve um estado global obsoleto em processos de longa duração. Nesse cenário, um worker pode conservar uma referência para uma área de memória que já foi liberada. Os caminhos identificados para alcançar essa condição incluem erros fatais, dados usados na geração de relatórios de erro e o acompanhamento do progresso de uploads em sessões.
Pesquisadores demonstraram execução de código sem autenticação por HTTP para a primeira vulnerabilidade em servidores Apache que utilizam `mod_php` com limites padrão. No caso do PHP-FPM, a possibilidade de exploração foi apontada por análise do código, mas não houve demonstração de um exploit. Já a exposição à segunda falha varia conforme a configuração do sistema e as extensões instaladas.
O alerta divulgado pela divisão Cyber do FBI em 21 de outubro recomenda aplicar as correções imediatamente. Se não for possível atualizar, a orientação é retirar o sistema vulnerável do ar. O comunicado também destaca a importância de identificar todas as instalações de PHP, dando prioridade a servidores acessíveis pela internet e a produtos que incluam a linguagem em sua própria estrutura.
As versões vulneráveis são as anteriores a PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Cada uma dessas versões recebeu uma atualização corretiva. O PHP 8.1 e as versões anteriores já não são mantidos pelo projeto, o que aumenta a urgência de migrar para uma edição suportada, além de aplicar os patches disponíveis.
A Cloudflare disponibilizou regras de firewall de aplicações web (WAF) para todos os planos. A medida pode ajudar a bloquear tráfego malicioso, mas não substitui a atualização do PHP. O diretor de tecnologia da empresa, Dane Knecht, afirmou que já havia sinais iniciais de ataques, tornando especialmente importante reduzir o tempo entre a identificação do risco e a correção.
A correção definitiva exige mais do que instalar o pacote atualizado. Depois da atualização, é necessário reiniciar os workers e verificar todos os serviços e pools que executam PHP. Atualizar apenas o interpretador de linha de comando pode deixar desprotegidos os processos do PHP-FPM ou o módulo usado pelo Apache, que podem estar instalados ou configurados separadamente.
Para reduzir a exposição enquanto a atualização não é concluída, o projeto recomenda limitar, no frontend, o tamanho das requisições e dos dados multipart recebidos. No PHP 8.5, também podem ser desativados `fatal_error_backtraces` e o acompanhamento do progresso de uploads em sessões. Essas medidas são paliativas: não eliminam a vulnerabilidade nem dispensam a instalação de uma versão corrigida.
Uma resposta eficaz começa por um inventário completo. Equipes de tecnologia devem localizar servidores web, containers, ambientes de hospedagem e aplicações que tragam o PHP incorporado. Também é importante registrar a versão em execução, o método de integração – como Apache com `mod_php` ou PHP-FPM -, as extensões carregadas e os responsáveis por cada serviço.
Após identificar os sistemas afetados, a prioridade deve ser corrigir os ativos expostos à internet e aqueles que processam arquivos ou requisições de usuários. Em ambientes críticos, a atualização precisa ser planejada para evitar interrupções, mas o risco deve ser avaliado com cautela: uma falha explorável sem autenticação pode atingir o servidor antes que o usuário tenha qualquer oportunidade de intervir.
Por fim, a equipe deve confirmar que a correção está ativa nos processos realmente utilizados pela aplicação. Isso inclui reiniciar serviços, validar a versão em cada ambiente e observar logs e alertas em busca de comportamentos incomuns. Regras de WAF, limites de upload e monitoramento são camadas complementares; a proteção principal continua sendo manter todas as instalações do PHP em versões corrigidas e suportadas.