Próxima versão crítica de segurança do PHP (CVE-2026-109618 / -109619)

Artigo original ↗ Discussão no Hacker News ↗

Um par crítico de vulnerabilidades do PHP (CVE‑2026‑109618/109619, apelidado de “PHP2Shell”) permite execução remota de código sem autenticação em praticamente qualquer instalação PHP da versão 5 em diante, colocando em risco uma estimativa de maioria da web — incluindo incontáveis sites WordPress e MediaWiki. Com exploits de prova de conceito circulando antes de os patches oficiais estarem disponíveis, operadores avaliaram mitigações emergenciais como bloquear requisições multipart POST ou tirar sites do ar por completo, enquanto CDNs e provedores de hospedagem correram para lançar regras de WAF e correções retroportadas. O incidente reacendeu preocupações sobre divulgação coordenada na era dos LLMs e sobre a segurança de longo prazo de grandes runtimes baseados em C, como o PHP.

Escopo e Gravidade

  • As vulnerabilidades (CVE-2026-109618 / -109619, apelidadas de “PHP2Shell”) afetam essencialmente todas as versões do PHP desde a série 5.x em diante, configurações padrão, setups típicos de FPM e qualquer servidor que aceite requisições POST/multipart.
  • Vários comentaristas comparam o impacto ao Heartbleed/Log4Shell ou pior, dada a participação do PHP de ~70% da web e a facilidade de exploração para RCE sem autenticação como o usuário do servidor web.
  • Avisos publicados posteriormente descrevem duas cadeias principais: RCE via corrupção por OOM e via estado global obsoleto no parsing de multipart.

Status de Exploração e PoC

  • Demonstrações em vídeo e PoCs circularam nas redes sociais antes dos patches oficiais; as primeiras PoCs estavam incompletas ou eram apenas crashers, mas a Cloudflare e outros relatam exploração ativa em ambiente real.
  • A via de exploração parece abusar do parsing de multipart/form-data e do tratamento de progresso de upload; as configurações padrão de sessão/upload aumentam a exposição.
  • Alguns comentaristas afirmam ter conseguido ao menos corrupção de memória ou acesso limitado ao banco de dados em sistemas de teste.

Mitigações e Defesas (Pré‑Patch)

  • Os mantenedores do núcleo do PHP afirmam repetidamente que mitigações apenas por configuração são insuficientes; somente atualizar o PHP corrige totalmente o problema.
  • Etapas temporárias comumente sugeridas:
    • Desativar session.upload_progress.enabled e, às vezes, file_uploads.
    • Bloquear multipart/form-data ou todo POST/PUT/PATCH/DELETE no servidor web ou no WAF.
    • Restringir requisições apenas a GET/HEAD ou desligar completamente os serviços PHP.
  • Vários provedores (Cloudflare, outras CDNs, hospedagem/WordPress gerenciado, Plesk, distros) estão implementando regras de WAF e/ou backports; a eficácia é apresentada como parcial/heurística.

Impacto Operacional

  • Muitos administradores desligaram MediaWiki, WordPress, Drupal e apps PHP personalizados antes do patch; alguns governos, universidades e grandes serviços tiraram temporariamente sites do ar.
  • Usuários de hospedagem compartilhada muitas vezes não conseguem desabilitar o PHP de forma limpa, gerando confusão sobre o que significa realmente estar “offline”.
  • As pessoas correram para obter pacotes PHP corrigidos, imagens Docker e builds de distribuições; alguns reclamaram que as imagens oficiais de contêiner ficaram atrás dos lançamentos do código-fonte.

Divulgação e Debate de Processo

  • Há um forte debate sobre:
    • Embargo versus liberação imediata do patch assim que os PoCs vazam.
    • Se atrasar patches para coordenar com grandes provedores “abandona” operadores menores.
    • Se LLMs tornam qualquer pista pública (ou palavras‑chave de SEO em textos de terceiros) suficiente para redescobrir rapidamente o bug.

Reflexões Mais Amplas

  • Críticas renovadas à base de código em C do PHP, à qualidade do parser multipart e ao longo histórico de problemas de segurança; pedidos para “oxidizar” o PHP ou migrar para Rust/Go/.NET ou sites estáticos.
  • Contra-argumentos observam que toda stack tem CVEs graves; o problema real é defesa em profundidade, isolamento de processos, menor privilégio e redução da superfície de ataque dinâmica.