PHP sob pressão: nova CVE em 48h e milhões de tentativas de ataque

Quarenta e oito horas. Foi o tempo entre o PHP lançar as correções emergenciais do PHP2Shell e publicar um novo alerta, nesta sexta-feira, 23 de outubro, sobre mais uma vulnerabilidade de execução remota de código.

A nova falha é a CVE-2026-115560. E, antes que o pânico se instale, vale dizer de cara: ela é bem menos grave que as anteriores, e a chance de você estar vulnerável é pequena. O problema de verdade continua sendo o outro — e esse, sim, já está sob ataque em massa.

Vamos separar as duas histórias, porque elas se misturam fácil.

A nova falha: real, mas improvável

O comunicado do PHP é classificado como informativo, não como um aviso de segurança crítico. A diferença de tom é proposital.

A CVE-2026-115560 só pode ser explorada quando três condições acontecem ao mesmo tempo na mesma aplicação:

1. A configuração session.serialize_handler está definida como php_binary ou php_serialize.
2. A aplicação troca esse valor para php em tempo de execução, via ini_set(), antes de chamar session_start().
3. O recurso de session upload progress continua habilitado — e ele vem ligado por padrão no PHP.

O segundo item é o filtro que salva quase todo mundo. Trocar o manipulador de serialização de sessão em runtime é algo que praticamente nenhuma aplicação faz. O próprio time do PHP classifica a combinação como improvável na prática. Se a sua aplicação nunca mexe nesse parâmetro em tempo de execução, você pode inclusive manter o upload progress ligado sem problema.

Por isso não haverá release emergencial. A correção entra no ciclo normal de bugfix, acompanhada de um advisory técnico completo. Até agora o projeto não informou versões afetadas, qual release trará a correção nem a nota de gravidade — e também não esclareceu se a causa técnica é a mesma da CVE-2026-109619.

A mitigação é uma linha

session.upload_progress.enabled=0

E aqui vem a parte conveniente: essa configuração já era recomendada no advisory de 21 de outubro, como mitigação da CVE-2026-109619. Quem aplicou na quarta-feira e manteve não precisa fazer absolutamente nada agora. É um daqueles raros casos em que quem foi diligente há dois dias já está coberto por uma falha que ainda nem tinha nome.

Um lembrete importante: a configuração precisa valer antes do parsing da requisição. Use php.ini, o pool do FPM ou a configuração do servidor — ini_set() e .user.ini rodam tarde demais para servir de proteção. E reinicie os workers.

O PHP2Shell, esse sim, virou caçada aberta