Introducción
La seguridad de la infraestructura web ha entrado en estado de alerta tras la publicación de parches de emergencia para dos fallos críticos en el motor de ejecución de PHP. A diferencia de las vulnerabilidades habituales que residen en CMS o librerías de terceros, estos defectos se encuentran en el propio runtime de PHP. Esto significa que un servidor puede ser comprometido incluso si aloja una página estática o una aplicación «Hello World» perfectamente segura, siempre que utilice una versión vulnerable del intérprete. Los equipos de DevOps y SRE deben priorizar la actualización inmediata de los binarios del sistema operativo o las imágenes de contenedores, ya que el riesgo es inherente a la forma en que el servidor maneja las peticiones HTTP antes de que se ejecute cualquier lógica de negocio.
La gravedad de la situación se ve agravada por la naturaleza de los vectores de ataque, que permiten la ejecución de código sin autenticación y la lectura de memoria del proceso trabajador. Con intentos de explotación activos detectados por proveedores de borde como Cloudflare, la ventana de exposición es crítica. La estrategia de mitigación no depende de configurar firewalls de aplicación web (WAF) de manera perfecta, sino de eliminar la vulnerabilidad subyacente mediante la actualización del paquete de software de nivel de sistema.
Qué ocurrió
La Fundación PHP lanzó actualizaciones para las ramas 8.5, 8.4, 8.3 y 8.2 el 21 de octubre, adelantándose a la fecha de divulgación planificada debido a una fuga de información. Las vulnerabilidades, identificadas como CVE-2026-109618 y CVE-2026-109619, fueron descubiertas por investigadores de Wiz Research, Calif, y el equipo de seguridad de OpenAI, quienes colaboraron con el equipo de seguridad de PHP para desarrollar los parches. Los fallos afectan a versiones de PHP tan antiguas como la 5.4, lo que implica una superficie de ataque masiva en servidores legacy y sistemas embebidos que aún dependen de estas versiones.
El mecanismo de ataque, denominado colectivamente «PHP2Shell», explota defectos en la gestión de memoria y el manejo de sesiones dentro del núcleo. Los investigadores demostraron que un solo request HTTP no autenticado puede desencadenar la ejecución de código. Aunque la divulgación coordinada sufrió una brecha cuando Calif publicó accidentalmente una prueba de concepto y Chainguard liberó imágenes parcheadas prematuramente, el impacto real se centra en la facilidad con la que los modelos de IA facilitaron el desarrollo de exploits funcionales para fallos que llevaban más de una década en el código base.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto es sistémico y afecta a cualquier arquitectura que utilice PHP para servir contenido dinámico. Los modos de operación más vulnerables son aquellos donde PHP se carga como un módulo dentro del proceso del servidor web, específicamente mod_php en Apache. En este escenario, el exploit se ejecuta en el contexto del proceso del servidor web, permitiendo el acceso a recursos compartidos y la persistencia sin necesidad de escribir archivos en disco. Los servidores que utilizan PHP-FPM (FastCGI Process Manager) también son vulnerables, aunque el comportamiento es ligeramente diferente: si el error ocurre temprano en el ciclo de vida de la petición, el worker puede reiniciarse, pero los investigadores confirmaron que la ejecución de código es posible en ambas configuraciones.
Para los equipos de seguridad en la nube, el riesgo incluye la exfiltración de secretos. Los fallos permiten leer la memoria del proceso PHP activo, lo que puede exponer tokens de API, credenciales de bases de datos, claves de sesión y certificados TLS que otras peticiones concurrentes estén utilizando. Esto es particularmente peligroso en entornos multi-tenant o contenedores compartidos. Aunque no se han confirmado brechas masivas, Cloudflare reportó intentos de explotación activos y la adaptación de payloads por parte de los atacantes para evadir reglas de WAF básicas, lo que indica una campaña de exploración organizada.
Detalles técnicos
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 tienen una puntuación CVSS v4.0 de 9.2. Afectan a PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, siendo estas las versiones parcheadas. El fallo CVE-2026-109618 está relacionado con una condición de desbordamiento que puede ser explotada mediante peticiones multipart/form-data maliciosas. El vector de ataque no requiere que la aplicación procese los datos de la petición; el motor PHP intenta parsear el cuerpo de la petición antes de entregar el control al código de la aplicación, lo que hace que incluso una página vacía sea vulnerable.
CVE-2026-109619 involucra el mecanismo de progreso de carga de sesiones (session.upload_progress). Esta función está habilitada por defecto y permite a los clientes consultar el estado de una carga de archivos. Los atacantes pueden manipular este mecanismo para acceder a la memoria del worker o ejecutar código. Es crucial destacar que las mitigaciones basadas en límites de recursos del sistema operativo, como RLIMIT_AS o RLIMIT_DATA, no funcionan y pueden activar el mismo camino vulnerable. La configuración memory_limit en php.ini es relevante para CVE-2026-109618, pero establecerla no es una mitigación completa, solo reduce la exposición.
Qué deberían hacer los administradores y equipos técnicos
La única mitigación efectiva es actualizar el binario de PHP. Los administradores de sistemas Linux deben actualizar los paquetes del sistema operativo inmediatamente. En distribuciones basadas en Debian/Ubuntu, esto implica ejecutar apt update && apt upgrade php8.2-cli php8.2-fpm (ajustando la versión y paquetes instalados). Es vital verificar el changelog del paquete para confirmar que las CVEs están incluidas, ya que los proveedores de distros a menudo retroportan parches de seguridad a versiones de paquetes que parecen antiguas pero contienen las correcciones.
Si la actualización inmediata no es posible, se deben aplicar mitigaciones parciales en php.ini, entendiendo que no cierran la vulnerabilidad:
session.upload_progress.enabled = 0
Tras aplicar los cambios o los parches, reiniciar los servicios de PHP y el servidor web. Para Apache: systemctl restart apache2. Para PHP-FPM: systemctl restart php8.2-fpm. Verificar los logs en busca de errores de límite de memoria inusuales o peticiones multipart gigantes, indicadores potenciales de intentos de explotación previos.
Conclusión
La aparición de PHP2Shell marca un punto de inflexión en la seguridad del lenguaje, demostrando que los fallos en el runtime son tan peligrosos como los de las aplicaciones, pero más difíciles de mitigar a nivel de aplicación. La reliance en parches de WAF como solución principal es insuficiente dada la capacidad de los atacantes para ofuscar cargas. Los equipos técnicos deben tratar esta actualización como un incidente de seguridad de prioridad P0. La auditoría de versiones de PHP en toda la infraestructura, incluyendo contenedores legacy y máquinas virtuales huérfanas, debe ser inmediata. La colaboración entre investigadores de IA y equipos de seguridad tradicionales ha acelerado la identificación de estos fallos, lo que sugiere que el ritmo de descubrimiento de vulnerabilidades en el núcleo de los lenguajes de scripting aumentará, exigiendo una disciplina de parcheo más estricta y automatizada.
Fuentes
https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html