CVE-2026-115560: PHP alerta sobre una tercera vía de RCE

Actualización al 23 de octubre de 2026. PHP publicó un aviso sobre CVE-2026-115560, una nueva vía de ejecución remota de código relacionada con sesiones y el seguimiento del progreso de cargas. La falla aparece apenas dos días después de las actualizaciones de emergencia contra PHP2Shell, pero su alcance y sus condiciones son diferentes.

No todos los servidores PHP están automáticamente expuestos. El problema requiere una combinación poco habitual de configuración y código de aplicación. Sin embargo, todavía no existe una versión oficial que lo corrija, por lo que los administradores deben revisar su entorno y aplicar la mitigación publicada por PHP cuando corresponda.

Una semana especialmente complicada para PHP

PHP sostiene una parte importante de la web y se utiliza debajo de WordPress, Drupal, Joomla, tiendas electrónicas y sistemas empresariales. En pocos días, su equipo de seguridad tuvo que comunicar tres vías de ejecución remota de código.

Las dos primeras fallas, conocidas conjuntamente como PHP2Shell, recibieron una puntuación crítica de 9.2 en CVSS v4.0. En cambio, al cierre de esta nota PHP todavía no había publicado una puntuación, una lista completa de versiones afectadas ni el aviso técnico definitivo para CVE-2026-115560.

¿Qué es CVE-2026-115560?

La nueva vulnerabilidad se encuentra en la interacción entre la serialización de sesiones y session.upload_progress. Esta última función permite que PHP escriba en la sesión información sobre el avance de un archivo mientras se está cargando, para que otra solicitud pueda consultar el porcentaje completado.

Las sesiones conservan información entre solicitudes HTTP, como identificadores, preferencias o estados temporales. PHP puede codificar esos datos mediante distintos controladores de serialización. El riesgo aparece cuando una aplicación cambia de controlador en un orden muy específico antes de iniciar la sesión.

Bajo esas condiciones, un atacante podría alcanzar una vía de ejecución remota de código dentro del contexto del proceso PHP. El proyecto describe el escenario como improbable, pero considera necesario desactivar temporalmente el seguimiento del progreso para obtener protección completa hasta que exista un parche.

Las cuatro condiciones necesarias

Según el aviso oficial, la exposición solo puede ocurrir cuando se cumplen todas estas condiciones:

1. La configuración establece session.serialize_handler en php_binary o php_serialize.
2. La aplicación cambia posteriormente ese valor a php durante la ejecución mediante ini_set().
3. El cambio ocurre antes de llamar a session_start().
4. session.upload_progress.enabled continúa habilitado.

Esta secuencia no es habitual. PHP aclara que las aplicaciones que nunca cambian el controlador de serialización durante la ejecución pueden mantener habilitada la función. Por ello, revisar el código y la configuración efectiva es más útil que asumir que cualquier instalación está comprometida.

¿Por qué una RCE merece atención?

RCE significa Remote Code Execution o ejecución remota de código. Una explotación exitosa puede permitir que un tercero ejecute instrucciones con los permisos asignados al proceso PHP.

El posible impacto incluye leer archivos accesibles, obtener credenciales, modificar una aplicación, instalar componentes maliciosos, interrumpir servicios o utilizar el servidor como punto de partida hacia otros sistemas. No significa que el atacante obtenga automáticamente permisos de administrador del sistema.

Estos son escenarios potenciales propios de una RCE, no evidencia de que todos se hayan observado mediante CVE-2026-115560. The Hacker News informó que, al momento de su publicación, no existían reportes de explotación activa de esta nueva falla; la actividad observada se relacionaba con las vulnerabilidades anteriores.

¿Existe ya una actualización?

No. PHP decidió gestionar la corrección dentro de su ciclo regular porque considera poco probable la combinación necesaria. El proyecto publicará un aviso completo y la versión corregida en su siguiente lanzamiento normal de mantenimiento.

Esto significa que actualizar a PHP 8.2.35, 8.3.36, 8.4.27 o 8.5.12 sigue siendo obligatorio para corregir PHP2Shell, pero no elimina CVE-2026-115560. Incluso un servidor completamente actualizado al 21 de octubre necesita revisar esta configuración.

Mitigación oficial: desactivar el progreso de cargas

Hasta que llegue el parche, PHP recomienda configurar:

session.upload_progress.enabled = 0

El ajuste debe aplicarse en un nivel administrativo que entre en vigor antes de procesar la solicitud, por ejemplo en php.ini, en el pool de PHP-FPM o en la configuración del servidor. No conviene depender de ini_set() ni de una configuración que se cargue demasiado tarde.

Después del cambio, reinicia o recarga de manera controlada todos los trabajadores PHP y verifica el valor efectivo desde el contexto web de cada sitio. La versión mostrada por la consola puede usar otro archivo de configuración.

Desactivar esta función no deshabilita las cargas de archivos. Solo impide que PHP registre el avance de una carga dentro de la sesión. Antes de cambiar producción, comprueba si alguna aplicación o desarrollo personalizado utiliza específicamente ese mecanismo.

Si ya desactivaste session.upload_progress.enabled como mitigación de CVE-2026-109619 y el valor continúa en cero, PHP indica que no necesitas una acción adicional para esta nueva vía.

¿Qué ocurre con WordPress y otros CMS?

La presencia de CVE-2026-115560 en PHP no convierte automáticamente en vulnerable a toda instalación de WordPress. Deben cumplirse las cuatro condiciones descritas, incluidas las modificaciones del controlador de serialización en tiempo de ejecución.

El análisis debe incluir plugins, temas, mu-plugins, integraciones y código personalizado que manipulen sesiones. Lo mismo aplica para Drupal, Joomla, Laravel y aplicaciones a medida. Revisar solamente el núcleo del CMS no descarta personalizaciones que cambien el comportamiento de PHP.

En alojamiento compartido, reseller o cPanel, es posible que el proveedor controle la configuración. Solicita confirmación por dominio de que el valor efectivo está deshabilitado o de que la aplicación no reúne las condiciones vulnerables. No des por válida una respuesta genérica sobre “PHP actualizado”, porque el parche todavía no existe.

Qué deben hacer los administradores ahora

1. Mantener los parches anteriores. Confirma que PHP2Shell esté corregido con las versiones del 21 de octubre o con un backport documentado.
2. Buscar cambios de serializador. Revisa configuraciones y código que modifiquen session.serialize_handler mediante ini_set().
3. Aplicar la mitigación. Desactiva administrativamente el progreso de cargas si no puedes demostrar que la ruta no existe.
4. Reiniciar y verificar. Comprueba cada pool, host virtual, contenedor y nodo desde su contexto web real.
5. Mantener defensa en profundidad. Conserva registros, mínimo privilegio, segmentación y WAF, sin tratarlos como sustitutos del futuro parche.
6. Vigilar el aviso oficial. Instala la siguiente versión corregida cuando PHP publique el reporte completo.

Cloudflare informó que sus reglas administradas cubren intentos conocidos cuando se utiliza el nombre predeterminado del campo de progreso. Esa protección tiene límites y puede no cubrir configuraciones personalizadas, por lo que la mitigación del servidor sigue siendo necesaria.

Una lección sobre configuración y riesgo

CVE-2026-115560 demuestra que la seguridad no termina al actualizar paquetes. El comportamiento final depende también de directivas, código personalizado, orden de inicialización, contenedores y servicios que pueden usar configuraciones diferentes.

Para las organizaciones, la respuesta adecuada combina inventario, revisión de configuración, aplicación de controles temporales y seguimiento de los avisos del proveedor. Una condición poco frecuente puede seguir siendo grave cuando se encuentra en un servicio público y permite ejecutar código.

Conclusión

CVE-2026-115560 es una vulnerabilidad distinta y considerablemente más específica que PHP2Shell. No justifica afirmar que todos los sitios PHP están expuestos, pero tampoco debe ignorarse mientras permanezca sin parche.

La prioridad es conservar las actualizaciones del 21 de octubre, revisar si la aplicación cambia el serializador de sesiones, desactivar temporalmente el progreso de cargas cuando corresponda y verificar el resultado en cada entorno. Una infraestructura segura se construye con decisiones informadas, configuraciones controladas y seguimiento continuo.

Nota editorial: esta información corresponde al estado conocido el 23 de octubre de 2026. El listado de versiones, la severidad y las recomendaciones pueden cambiar cuando PHP publique el aviso técnico completo.