PHP detecta nova vulnerabilidade dois dias após correções emergenciais
Em 23 de outubro de 2026, o projeto PHP alertou sobre uma nova falha que, em determinadas circunstâncias, pode permitir a execução remota de código em servidores web. Registrada como CVE-2026-115560, ela foi divulgada apenas 48 horas depois da publicação de atualizações emergenciais destinadas a corrigir as vulnerabilidades PHP2Shell.
O novo problema não é corrigido pelas versões lançadas em 21 de outubro: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Essas atualizações tratam das falhas CVE-2026-109618 e CVE-2026-109619, que são independentes da CVE-2026-115560.
Segundo a equipe do PHP, a exploração da nova vulnerabilidade depende de uma combinação específica de configurações de sessão. Inicialmente, a diretiva `session.serialize_handler` precisa estar configurada como `php_binary` ou `php_serialize`. Depois, antes de chamar `session_start()`, a aplicação deve alterar esse parâmetro em tempo de execução para `php`, por meio da função `ini_set()`.
Também é necessário que esteja ativo o recurso de acompanhamento do progresso de uploads de arquivos, conhecido como *session upload progress*. Como esse recurso vem habilitado por padrão, a recomendação dos mantenedores é desativá-lo temporariamente:
“`ini
session.upload_progress.enabled = Off
“`
A equipe considera improvável encontrar, em ambientes reais, todas essas condições reunidas. Aplicações que não trocam dinamicamente o manipulador de serialização de sessões não estão expostas a essa vulnerabilidade específica. Ainda assim, a desativação do acompanhamento de uploads é indicada como precaução até que a correção definitiva seja disponibilizada.
A mesma medida já havia sido recomendada em 21 de outubro para reduzir o risco associado à CVE-2026-109619. Assim, organizações que já desabilitaram o recurso e mantiveram essa configuração ativa não precisam fazer uma mudança adicional para se proteger da nova falha.
O PHP informou que pretende incluir a correção no ciclo regular de atualizações, acompanhada de documentação técnica. Até o momento do alerta, porém, o projeto não havia detalhado quais versões são afetadas, em quais lançamentos a solução será incluída nem qual será a classificação de gravidade da vulnerabilidade. Também não esclareceu se há relação entre a causa técnica da CVE-2026-115560 e a da CVE-2026-109619.
O que administradores podem fazer enquanto a correção não chega
O primeiro passo é verificar a configuração efetiva do PHP em cada ambiente, incluindo servidores de produção, homologação e contêineres. Uma configuração definida em um arquivo pode ser sobrescrita por outro arquivo, pela inicialização do serviço ou pelo próprio código da aplicação. Por isso, vale confirmar o valor realmente aplicado, e não apenas consultar um arquivo de configuração isolado.
Também é importante revisar o código em busca de chamadas a `ini_set()` que alterem `session.serialize_handler` antes do início de uma sessão. Essa análise ajuda a identificar se a aplicação reúne as condições necessárias para a falha e permite avaliar se a alteração dinâmica pode ser removida ou evitada.
Após desativar o acompanhamento de progresso dos uploads, a equipe deve testar os fluxos de envio de arquivos. Aplicações que exibem uma barra de progresso ou dependem desse mecanismo podem apresentar mudanças de comportamento; o teste deve confirmar que o recebimento dos arquivos continua funcionando e que eventuais recursos de interface não foram afetados.
A avaliação também deve abranger todas as instâncias em que o PHP é executado. Servidores menos visíveis, tarefas automatizadas, serviços de processamento de arquivos e ambientes temporários podem utilizar configurações diferentes das do site principal. Manter um inventário atualizado reduz a possibilidade de deixar um componente sem mitigação.
Como medida geral de segurança, administradores podem acompanhar os registros de acesso e de aplicação em busca de comportamentos incomuns, sem presumir que toda solicitação suspeita esteja relacionada a essa CVE. A equipe do PHP não havia divulgado relatos de exploração da nova falha; portanto, a atividade identificada contra as vulnerabilidades anteriores não deve ser tratada como evidência de ataques à CVE-2026-115560.
Ataques às falhas PHP2Shell continuam sob monitoramento
Enquanto não havia registros de exploração da nova vulnerabilidade, as duas falhas PHP2Shell corrigidas em 21 de outubro já eram alvo de tentativas maliciosas. A Amazon informou que seus honeypots detectaram uma tentativa de exploração em 17 de outubro, quatro dias antes da divulgação pública das vulnerabilidades.
A Cloudflare observou um aumento acentuado de ataques após a publicação dos detalhes em 21 de outubro. A empresa contabilizou dezenas de milhares de tentativas nos primeiros 45 minutos, e os registros chegaram à casa dos milhões nas primeiras horas do dia 22.
Pesquisadores da Sophos e da Arctic Wolf também identificaram tentativas de usar as falhas para instalar uma variante da botnet Mirai. Esse malware compromete dispositivos conectados e pode integrá-los a redes usadas em atividades maliciosas. Até então, porém, não havia confirmação de que essas tentativas tenham conseguido executar a instalação.
Previdian e Wordfence relataram varreduras e sondagens direcionadas a sistemas potencialmente vulneráveis, mas sem evidências de execução de código bem-sucedida. Pesquisadores também apontaram dificuldades para criar exploits confiáveis. Esses registros se referem às falhas PHP2Shell corrigidas em 21 de outubro, não à CVE-2026-115560.
A distinção é importante para orientar a resposta das equipes técnicas: a nova vulnerabilidade exige uma combinação particular de configurações, e não havia relatos de ataques que a explorassem. Administradores devem aplicar a mitigação temporária, acompanhar as próximas atualizações do PHP e instalar a correção definitiva assim que ela estiver disponível.