Dois dias depois dos patches emergenciais do PHP2Shell (CVE-2026-109618 e CVE-2026-109619), o projeto PHP confirmou hoje uma terceira vulnerabilidade de execução remota de código, a CVE-2026-115560.

Ela não é corrigida pelas versões de 21/10 (8.5.12, 8.4.27, 8.3.36 e 8.2.35). Ela (ainda)  não é motivo para pânico, mas é para atenção, pois em casos raros permite execução remota de código.

Três condições precisam ocorrer ao mesmo tempo: a aplicação define session.serialize_handler como php_binary ou php_serialize na configuração, troca esse handler para php em tempo de execução com ini_set() antes de chamar session_start(), e mantém o upload progress habilitado.

Minha leitura técnica do mecanismo, compatível com o que o toolkit da Syhunt [1] descreve: o handler de upload progress grava dados na sessão antes de o script rodar, usando o serializador da configuração. Depois, a aplicação lê essa mesma sessão com outro formato.

Conteúdo controlado pelo atacante passa a ser interpretado como objetos serializados, o que abre caminho para injeção de objetos e RCE via gadgets da aplicação (destrutores, por exemplo). É uma confusão de serializadores, e não corrupção de memória como no PHP2Shell.

Mitigação

A mitigação é uma linha de configuração. O PHP recomenda session.upload_progress.enabled=0 até o próximo release de correção, aplicado no php.ini ou no pool do FPM, para valer antes do parsing da requisição. Quem já aplicou essa flag na terça-feira está coberto. Aplicações que nunca trocam o serializer em tempo de execução podem manter o recurso habilitado.

A configuração precisa estar no nível do servidor. No caso da CVE-2026-109619, o PHP já deixou claro que ini_set() dentro da aplicação e o arquivo .user.ini do FPM não ajudam

Para auditar um parque de servidores, além de conferir o valor efetivo na SAPI web, vale procurar a troca de serializer no código-fonte:

% grep -rnE "ini_set\s*\(\s*['\"]session\.serialize_handler" /var/www
% grep -E "^\s*session\.serialize_handler" /etc/php/*/*/php.ini

Se o primeiro comando não retornar nada, o vetor da CVE-2026-115560 provavelmente não se aplica. Mesmo assim, desabilitar o upload progress continua recomendável por causa da CVE-2026-109619.

Sobre a fonte e o toolkit

A fonte principal dessa informação é Felipe Daragon,  autor do Sandcat Browser e fundador da Syhunt. O repositório fixado no perfil dele, syhunt/php2shell-protection [1], é descrito como toolkit de mitigação e teste para CVE-2026-109618, CVE-2026-109619 e CVE-2026-115560, incluindo proteções para Apache e orientações de hardening de PHP. O material é tecnicamente cuidadoso e honesto sobre os próprios limites. Ele afirma que é um toolkit de filtragem de POST multipart no Apache e de teste funcional, e NÃO uma mitigação completa para nenhuma das CVEs.

Um ponto que merece atenção: o projeto declara que foi desenvolvido antes da publicação dos advisories oficiais, com base em informações preliminares e em acesso antecipado a material de prova de conceito zero-day obtido e revisado pela equipe. Isso não compromete a parte defensiva, mas mostra que PoCs circularam antes da divulgação coordenada. Faz sentido, porque as tentativas de exploração do PHP2Shell começaram quatro dias antes da divulgação, e a Cloudflare reporta milhões de ataques.

Avaliação de risco

A CVE-2026-115560 é de baixo impacto prático, com nenhuma exploração conhecida até agora. Ela importa menos pelo que é e mais pelo que mostra: o subsistema de sessão e upload progress do PHP virou alvo de escrutínio intenso, e novas variantes devem continuar aparecendo. A prioridade operacional continua sendo o PHP2Shell: aplicar os patches de 21/10, reiniciar os workers e manter session.upload_progress.enabled=0 de forma permanente onde o recurso não é usado.

Referências

[1] https://github.com/syhunt/php2shell-protection