PHP 8.2.35

Artigo original ↗ Discussão no Hacker News ↗

Lançamentos emergenciais de segurança para PHP 8.2–8.5 visam corrigir duas vulnerabilidades críticas “PHP2Shell” que permitem execução remota de código sem autenticação em quase qualquer servidor web movido a PHP, incluindo stacks populares como WordPress e plataformas de hospedagem compartilhada. Comentadores trocam táticas de mitigação de curto prazo (desativar upload progress, bloquear multipart form data, apertar limites de memória, reiniciar workers agressivamente) enquanto aguardam pacotes corrigidos e imagens Docker de distros, provedores de nuvem e repositórios de terceiros. O incidente também desencadeia preocupação mais ampla sobre divulgação coordenada na era da caça a vulnerabilidades assistida por IA, a lentidão de alguns vendors em liberar patches e a longa cauda de instalações desatualizadas de PHP 5/7 ainda executando grande parte da web.

Novos Lançamentos e Vulnerabilidades

  • Lançamentos de segurança: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12; também há backports mínimos de código-fonte para 7.4, 8.0 e 8.1.
  • Duas vulnerabilidades críticas (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) permitem RCE por meio do tratamento de falta de memória e da análise de multipart; todos os SAPIs web são apontados como em risco (FPM, mod_php, CGI etc.).
  • As vulnerabilidades estão relacionadas a OOM durante a inicialização da requisição, tratamento de erros baseado em longjmp e parsing de multipart/form-data; muitas verificações defensivas para OOM foram adicionadas em todo o codebase.

Mitigações e Respostas Operacionais

  • Mitigações temporárias comuns:
    • Desativar session.upload_progress.enabled.
    • Bloquear requisições multipart/form-data no servidor web, aceitando que isso quebre uploads de arquivos.
    • Definir pm.max_requests=1 no FPM para evitar reutilização de estado obsoleto.
    • Reduzir post_max_size e max_input_nesting_level.
    • Garantir que nenhum .php seja servido a partir de uploads e remover phpinfo.php.
  • Alguns operadores colocaram sites PHP offline ou desligaram os servidores web de front-end até que os patches estivessem disponíveis; outros inseriram proxies reversos/filtros temporários entre o servidor web e o FPM.
  • Debate sobre se o CGI/clássico um-request-por-processo é, na prática, explorável; o advisory oficial trata todos os SAPIs como arriscados.

Atraso de Patch em Distro, PPA e Docker

  • Debian (incluindo oldstable e alguns backports de PHP 7) e Gentoo atualizaram rapidamente; as atualizações de segurança do Ubuntu atrasaram e foram inconsistentes entre as releases LTS, mas acabaram chegando.
  • Os repositórios Debian/Ubuntu de Ondřej Surý e outros repositórios de terceiros (incluindo para PHP 5.6/7.4) publicaram builds corrigidos cedo; Launchpad e PECL ficaram sobrecarregados.
  • As imagens oficiais do Docker para PHP e apps populares (WordPress, Matomo, Nextcloud) demoraram notavelmente ou, por breve período, publicaram imagens ainda com PHP vulnerável, levando muitos a reconstruir as imagens por conta própria ou a usar pacotes da distro em vez disso.

Versões Mais Antigas do PHP e Hosting Compartilhado

  • Grandes frações do ecossistema ainda executam PHP 5/7; algumas distros e mantenedores da comunidade fizeram backport das correções, mas o PHP oficial parou em patches mínimos para 7.4.
  • Provedores gerenciados de WordPress e de hosting compartilhado variaram: alguns desativaram à força todos os sites PHP; outros liberaram versões corrigidas horas depois, frustrando os usuários.

Papel da IA e Processo de Divulgação

  • Cadeia de vulnerabilidade atribuída ao trabalho de empresas de segurança usando LLMs; há forte debate sobre se a coordenação e o embargo foram mal conduzidos e excessivamente orientados por PR.
  • Alguns argumentam que correções mais cedo e discretas, ou um lançamento mais rápido após o vazamento, teriam reduzido o caos; outros observam que qualquer patch público revela imediatamente o bug na era dos LLMs.
  • Discussão meta significativa sobre “AI slop” nos comentários, com críticas (baixa confiança, textos barulhentos) e elogios (mitigações rápidas, tooling, audits gerados).

Reações Técnicas e Culturais

  • Longjmp, tratamento manual de OOM e verificações espalhadas no estilo goto são criticados como padrões inseguros em C; outros observam que essas técnicas são comuns em interpretadores.
  • Alguns veem isso como mais um sinal de que PHP é um “fractal de bad design” e defendem migrar para fora do PHP, especialmente agora que a IA pode ajudar a portar código.
  • Outros respondem que todas as grandes runtimes (JVM, V8 etc.) têm bugs críticos; a onipresença do PHP torna suas falhas mais visíveis, não inerentemente piores.