Próxima versión crítica de seguridad de PHP (CVE-2026-109618 / -109619)

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

Un par crítico de vulnerabilidades de PHP (CVE‑2026‑109618/109619, apodadas “PHP2Shell”) permite ejecución remota de código no autenticada en prácticamente cualquier instalación de PHP desde la versión 5 en adelante, poniendo en riesgo a una mayoría estimada de la web —incluidos incontables sitios de WordPress y MediaWiki—. Con exploits de prueba de concepto circulando antes de que hubiera parches oficiales, los operadores barajaron mitigaciones de emergencia como bloquear solicitudes multipart POST o desconectar por completo los sitios, mientras las CDNs y los proveedores de alojamiento se apresuraban a publicar reglas de WAF y correcciones retroportadas. El incidente ha reavivado las preocupaciones sobre la divulgación coordinada en la era de los LLM y sobre la seguridad a largo plazo de grandes runtimes basados en C como PHP.

Alcance y gravedad

  • Las vulnerabilidades (CVE-2026-109618 / -109619, apodadas “PHP2Shell”) afectan esencialmente a todas las versiones de PHP desde la 5.x en adelante, configuraciones predeterminadas, configuraciones típicas de FPM y cualquier servidor que acepte solicitudes POST/multipart.
  • Varios comentaristas comparan el impacto con Heartbleed/Log4Shell o incluso peor, dada la cuota web de PHP de ~70% y la facilidad de explotación para RCE no autenticado como usuario del servidor web.
  • Los avisos publicados posteriormente describen dos cadenas principales: RCE mediante corrupción por OOM y mediante estado global obsoleto en el análisis multipart.

Estado del exploit y PoC

  • Se difundieron demostraciones en video y PoC en redes sociales antes de los parches oficiales; las primeras PoC estaban incompletas o solo provocaban fallos, pero Cloudflare y otros informan de explotación activa en el mundo real.
  • La ruta de explotación parece abusar del análisis multipart/form-data y del manejo del progreso de subida; la configuración predeterminada de sesiones/subidas aumenta la exposición.
  • Algunos comentaristas afirman haber conseguido al menos corrupción de memoria o acceso limitado a bases de datos en sistemas de prueba.

Mitigaciones y defensas (preparche)

  • Los mantenedores del núcleo de PHP afirman repetidamente que las mitigaciones solo por configuración no son suficientes; solo actualizar PHP lo corrige por completo.
  • Pasos temporales sugeridos habituales:
    • Deshabilitar session.upload_progress.enabled y, en ocasiones, file_uploads.
    • Bloquear multipart/form-data o todas las solicitudes POST/PUT/PATCH/DELETE en el servidor web o el WAF.
    • Restringir las solicitudes a solo GET/HEAD, o apagar por completo los servicios PHP.
  • Varios proveedores (Cloudflare, otras CDNs, WordPress/hosting gestionado, Plesk, distribuciones) despliegan reglas WAF y/o backports; la eficacia se presenta como parcial/heurística.

Impacto operativo

  • Muchos administradores apagaron MediaWiki, WordPress, Drupal y aplicaciones PHP personalizadas antes del parche; algunos gobiernos, universidades y servicios grandes retiraron temporalmente sitios de Internet.
  • Los usuarios de hosting compartido a menudo no pueden desactivar PHP limpiamente, lo que genera confusión sobre qué significa realmente estar “offline”.
  • La gente se apresura a obtener paquetes de PHP parcheados, imágenes Docker y compilaciones de distribuciones; algunos se quejan de que las imágenes oficiales de contenedores iban por detrás de las versiones fuente.

Debate sobre divulgación y proceso

  • Fuerte debate sobre:
    • Embargo frente a publicación inmediata del parche una vez que se filtran las PoC.
    • Si retrasar los parches para coordinarse con grandes proveedores “abandona” a los operadores más pequeños.
    • Si los LLM hacen que cualquier pista pública (o palabras clave SEO en textos de terceros) sea suficiente para redescubrir rápidamente el fallo.

Reflexiones más amplias

  • Renovadas críticas al código C de PHP, a la calidad del parser multipart y a su larga historia de problemas de seguridad; llamados a “oxidizar” PHP o migrar a Rust/Go/.NET o a sitios estáticos.
  • Los contrapuntos señalan que todas las pilas tienen CVE graves; el problema real es la defensa en profundidad, el aislamiento de procesos, el menor privilegio y la reducción de la superficie de ataque dinámica.