PHP 8.2.35

Artículo original ↗ Discusión en Hacker News ↗

Las versiones de seguridad urgentes para PHP 8.2–8.5 buscan corregir dos vulnerabilidades críticas “PHP2Shell” que permiten ejecución remota de código sin autenticación en casi cualquier servidor web impulsado por PHP, incluidas plataformas populares como WordPress y el hosting compartido. Los comentaristas comparten tácticas de mitigación a corto plazo (desactivar el progreso de carga, bloquear multipart form data, ajustar los límites de memoria, reiniciar agresivamente los workers) mientras esperan paquetes e imágenes de Docker parcheados de las distribuciones, proveedores de nube y repositorios de terceros. El incidente también despierta una preocupación más amplia sobre la divulgación coordinada en la era de la búsqueda de vulnerabilidades asistida por IA, el lento despliegue de parches de algunos proveedores y la larga cola de instalaciones no soportadas de PHP 5/7 que aún ejecutan gran parte de la web.

Nuevas versiones y vulnerabilidades

  • Lanzamientos de seguridad: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12; también backports mínimos del código fuente para 7.4, 8.0, 8.1.
  • Dos vulnerabilidades críticas (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) permiten RCE mediante el manejo de falta de memoria y el análisis multipart; se dice que todos los SAPIs web están en riesgo (FPM, mod_php, CGI, etc.).
  • Las vulnerabilidades están relacionadas con OOM durante la inicialización de solicitudes, el manejo de errores basado en longjmp y el análisis multipart/form-data; se añadieron muchas comprobaciones defensivas para OOM en todo el código base.

Mitigaciones y respuestas operativas

  • Mitigaciones temporales comunes:
    • Deshabilitar session.upload_progress.enabled.
    • Bloquear solicitudes multipart/form-data en el servidor web, asumiendo que esto rompe las cargas de archivos.
    • Establecer pm.max_requests=1 en FPM para evitar la reutilización de estado obsoleto.
    • Reducir post_max_size y max_input_nesting_level.
    • Asegurarse de que no se sirva ningún .php desde las subidas y eliminar phpinfo.php.
  • Algunos operadores desconectaron sitios PHP o apagaron los servidores web de frontend hasta que hubo parches; otros insertaron proxies inversos/filtros temporales entre el servidor web y FPM.
  • Debate sobre si CGI/clásico de una solicitud por proceso es explotable en la práctica; el aviso oficial considera riesgosos todos los SAPIs.

Retraso de parches en distros, PPA y Docker

  • Debian (incluyendo oldstable y algunos backports de PHP 7) y Gentoo se actualizaron rápido; las actualizaciones de seguridad de Ubuntu llegaron con retraso y de forma inconsistente entre versiones LTS, pero finalmente se publicaron.
  • Los repositorios Debian/Ubuntu de Ondřej Surý y otros repositorios de terceros (incluidos los de PHP 5.6/7.4) publicaron compilaciones parcheadas pronto; Launchpad y PECL estuvieron sobrecargados.
  • Las imágenes oficiales de Docker para PHP y aplicaciones populares (WordPress, Matomo, Nextcloud) fueron notablemente lentas o publicaron brevemente imágenes que seguían usando PHP vulnerable, lo que llevó a muchos a reconstruir imágenes por su cuenta o usar paquetes de la distribución.

Versiones antiguas de PHP y hosting compartido

  • Grandes proporciones del ecosistema siguen ejecutando PHP 5/7; algunas distribuciones y mantenedores de la comunidad retroportaron correcciones, pero PHP oficial se quedó en parches mínimos para 7.4.
  • Los proveedores de WordPress gestionado y hosting compartido variaron: algunos deshabilitaron forzosamente todos los sitios PHP; otros desplegaron versiones parcheadas horas después, frustrando a los usuarios.

Papel de la IA y proceso de divulgación

  • La cadena de vulnerabilidades se atribuye al trabajo de empresas de seguridad que usan LLMs; existe un fuerte debate sobre si la coordinación y el embargo se gestionaron mal y estuvieron demasiado orientados a la PR.
  • Algunos sostienen que arreglos anteriores y más discretos o una publicación más rápida tras la filtración habrían reducido el caos; otros señalan que cualquier parche público revela de inmediato el fallo en la era de los LLM.
  • Hay una discusión meta significativa sobre “AI slop” en los comentarios, con tanto críticas (baja confianza, writeups ruidosos) como elogios (mitigaciones rápidas, herramientas y auditorías generadas).

Reacciones técnicas y culturales

  • Longjmp, el manejo manual de OOM y las comprobaciones dispersas al estilo goto se critican como patrones inseguros en C; otros señalan que estas técnicas son comunes en intérpretes.
  • Algunos ven esto como una señal más de que PHP es un “fractal de mal diseño” y abogan por migrar fuera de PHP, especialmente ahora que la IA puede ayudar a portar código.
  • Otros responden que todos los grandes runtimes (JVM, V8, etc.) tienen errores críticos; la ubicuidad de PHP hace que sus fallos sean más visibles, no intrínsecamente peores.