PHP vuelve a emitir una alerta, CVE-2026-115560 abre otro posible camino de RCE y todavía no tiene parche
Apenas dos días después de que PHP publicara actualizaciones de emergencia para corregir dos vulnerabilidades críticas capaces de permitir ejecución remota de código, el propio proyecto volvió a emitir una advertencia de seguridad.
Esta vez el nuevo identificador es CVE-2026-115560 y la situación tiene una diferencia importante respecto de las fallas que conocimos el 21 de octubre, no estamos frente a un problema que afecte de la misma manera a todas las instalaciones PHP, sino ante un posible camino de ejecución remota de código que necesita una combinación bastante poco habitual entre configuración de sesiones y código de la aplicación.
PHP todavía no publicó el parche definitivo para esta CVE y anunció que la corrección llegará dentro del próximo ciclo normal de actualizaciones, mientras tanto recomienda desactivar temporalmente una función llamada session upload progress en los servidores donde pueda existir este escenario.
Y hay algo especialmente interesante, la medida temporal recomendada hoy ya formaba parte de las mitigaciones publicadas hace dos días, por eso aquellos administradores que siguieron completamente las indicaciones del 21 de octubre probablemente ya estén protegidos frente a este nuevo escenario.
Qué sabemos hoy sobre CVE-2026-115560
El aviso es real, pero entender las condiciones evita transformar una advertencia concreta en una alarma general.
Sí, PHP la identificó oficialmente como CVE-2026-115560.
PHP describe un posible vector de RCE, aunque necesita una combinación poco habitual de configuración y código.
Todavía no existe una actualización específica para esta CVE. PHP incorporará la corrección en el próximo lanzamiento normal.
Sí, PHP recomienda configurar temporalmente session.upload_progress.enabled=0.
No. Se necesita una combinación específica relacionada con session.serialize_handler y cambios realizados durante la ejecución.
PHP indica que si ya desactivamos session upload progress, no necesitamos realizar ninguna acción adicional por este nuevo aviso.
PHP publicó un nuevo aviso apenas dos días después de su actualización de emergencia
El 21 de octubre PHP publicó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 para corregir CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas con una puntuación de 9,2 sobre 10 que podían permitir ejecución remota de código sin autenticación.
Aquella actualización fue excepcionalmente importante porque el problema existía dentro del propio núcleo de PHP y podía afectar servidores utilizando PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed.
Ahora, el 23 de octubre, PHP volvió a publicar un aviso, esta vez denominado Informational advisory: Session upload progress.
El nuevo problema recibió el identificador CVE-2026-115560 y todavía no cuenta con un advisory técnico completo, porque PHP decidió manejarlo dentro de su ciclo normal de correcciones debido a que la combinación necesaria para aprovecharlo resulta poco habitual.
La diferencia más importante está en una palabra, configuración
Las vulnerabilidades anteriores afectaban al núcleo de PHP de una manera mucho más general y por eso la recomendación era contundente, todos los servidores web debían instalar las versiones corregidas cuanto antes.
CVE-2026-115560 funciona de otra manera.
PHP explica que el problema solamente puede aparecer cuando coinciden varias condiciones, algunas relacionadas con la configuración inicial del sistema y otras con cambios que realiza la propia aplicación mientras se está ejecutando.
Si esas condiciones no existen, el camino descrito por PHP tampoco existe.
Para llegar a este nuevo escenario tienen que ocurrir tres cosas bastante específicas
Según PHP, la aplicación tiene que comenzar utilizando un determinado formato para almacenar información de sesión, cambiar ese formato durante la ejecución y mantener además activa la función de seguimiento del progreso de archivos subidos.
1. La configuración inicial de session.serialize_handler debe utilizar php_binary o php_serialize.
2. La aplicación debe cambiar después ese valor a php durante la ejecución utilizando ini_set(), antes de llamar a session_start().
3.session.upload_progress.enabled debe continuar habilitado.
No es la configuración típica de una instalación común y PHP lo dice expresamente, la combinación resulta improbable en la práctica.
Las aplicaciones que nunca cambian el serializador de sesiones durante la ejecución no necesitan desactivar la función exclusivamente por este escenario, aunque PHP igualmente propone hacerlo temporalmente como medida conservadora hasta que llegue la próxima versión corregida.
Una sesión es la forma en que una página recuerda quién somos mientras navegamos
Cuando iniciamos sesión en una página, agregamos productos a un carrito o utilizamos determinadas funciones, el servidor necesita guardar información entre una petición y la siguiente.
PHP dispone de un sistema de sesiones precisamente para eso.
Esa información puede guardarse utilizando diferentes formatos internos, y session.serialize_handler determina cómo PHP transforma los datos de una sesión antes de almacenarlos.
En una instalación normal esa decisión suele mantenerse estable durante todo el funcionamiento de la aplicación.
CVE-2026-115560 aparece cuando una aplicación utiliza una configuración al comienzo y posteriormente intenta cambiarla a otra mientras la petición ya está siendo procesada.
La segunda pieza es una función que permite seguir el progreso mientras subimos archivos
PHP incluye desde hace años una función denominada session.upload_progress.
Su objetivo es permitir que una aplicación conozca cuánto avanzó la subida de un archivo mientras todavía está llegando al servidor, por ejemplo para mostrar una barra que indica 20%, 50% o 90% completado.
La opción session.upload_progress.enabled viene activada por defecto en PHP.
Cuando está habilitada, PHP puede almacenar temporalmente información del archivo dentro de la sesión incluso antes de que el código habitual de la página empiece a ejecutarse.
Ese comportamiento ya había aparecido dentro de los caminos relacionados con CVE-2026-109619, por eso PHP recomendó desactivarlo temporalmente como una de las mitigaciones del 21 de octubre.
Mientras no exista parche, PHP recomienda desactivar session upload progress
La recomendación publicada el 23 de octubre es muy concreta:
PHP recomienda mantener esta función desactivada hasta que aparezca la próxima actualización normal que incluya la corrección definitiva.
Esto no debería aplicarse desde el propio código de la página una vez que la petición ya empezó, porque la función de progreso interviene antes de la ejecución normal de la aplicación.
En servidores administrados directamente, la modificación debería realizarse en una configuración que PHP lea antes de procesar las peticiones, por ejemplo el archivo php.ini, la configuración del pool de PHP-FPM o la configuración equivalente del servidor.
Actualizar PHP el 21 de octubre sigue siendo correcto, esta nueva CVE no vuelve inútiles esos parches
Este punto merece especial atención porque un titular como “PHP vuelve a estar vulnerable” puede generar la sensación de que actualizar a PHP 8.3.36, 8.4.27 o 8.5.12 no sirvió para nada.
No es así.
Las versiones publicadas el 21 de octubre corrigen CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades diferentes, críticas y con un alcance mucho más amplio.
CVE-2026-115560 representa otro escenario que PHP identificó posteriormente y que necesita una configuración específica para funcionar.
Por eso debemos mantener las versiones actualizadas y, mientras esperamos la próxima revisión, aplicar la mitigación adicional donde corresponda.
Corrige CVE-2026-109618 y CVE-2026-109619.
Mitiga CVE-2026-115560 desactivando temporalmente session upload progress hasta que llegue el parche.
Además, PHP indica algo muy importante, si el 21 de octubre ya aplicamos session.upload_progress.enabled=0 siguiendo las mitigaciones recomendadas para CVE-2026-109619, no necesitamos realizar ninguna acción adicional frente a este nuevo aviso.
WordPress vuelve a quedar en el medio, pero otra vez el problema no pertenece a WordPress
WordPress utiliza PHP como tecnología de servidor, por eso cualquier vulnerabilidad importante dentro del runtime puede terminar afectando indirectamente a sitios WordPress.
Sin embargo, CVE-2026-115560 no es una vulnerabilidad del núcleo de WordPress, tampoco de Elementor, WooCommerce o algún plugin determinado.
La condición depende de cómo esté configurado PHP y de si una aplicación cambia específicamente el manejador de serialización de sesiones durante la ejecución.
Una instalación estándar de WordPress no debería llevarnos automáticamente a esa combinación solamente por utilizar WordPress, pero plugins, integraciones o aplicaciones desarrolladas a medida pueden modificar comportamientos de PHP, por eso en entornos complejos conviene revisar antes de asumir.
El 21 de octubre PHP corrigió dos vulnerabilidades críticas mucho más generales
La actualización anterior solucionó dos fallas calificadas con CVSS 9.2 capaces de permitir ejecución remota de código sin autenticación, un escenario diferente al que presenta CVE-2026-115560.
En un hosting administrado, buena parte de esta responsabilidad pertenece al proveedor
La mayoría de las páginas de pequeñas y medianas empresas no funcionan sobre un servidor administrado directamente por su propietario, utilizan un hosting donde PHP, PHP-FPM, LiteSpeed, Apache y gran parte de la infraestructura son gestionados por otra compañía.
En ese escenario probablemente no tengamos acceso a todos los niveles de configuración necesarios para aplicar una mitigación global.
Eso no significa que tengamos que ignorar el problema, significa que la pregunta correcta cambia.
Ahora empieza otra etapa, determinar cuántos sistemas utilizan realmente esta configuración
La información disponible hoy todavía es limitada porque PHP decidió publicar primero la mitigación y reservar el advisory técnico completo para la próxima versión.
Durante los próximos días seguramente veremos investigadores analizando frameworks, aplicaciones y productos que modifiquen session.serialize_handler durante la ejecución para determinar qué software podría entrar realmente en la combinación vulnerable.
También es probable que proveedores de hosting incorporen la mitigación a nivel global si comprueban que sus clientes no necesitan la función de progreso de subida o si pueden hacerlo sin romper aplicaciones.
Lo que todavía no sabemos es la fecha exacta del lanzamiento que incorporará el parche, la gravedad CVSS definitiva de CVE-2026-115560 ni si aparecerá explotación pública de este camino concreto.
Después de lo ocurrido con PHP2Shell sería razonable esperar que investigadores y atacantes revisen el nuevo vector rápidamente, por eso la medida prudente es aplicar la recomendación de PHP donde corresponda y mantener seguimiento hasta que llegue la corrección definitiva.
Preguntas frecuentes sobre CVE-2026-115560
¿CVE-2026-115560 es real?
Sí. PHP publicó oficialmente el 23 de octubre de 2026 un aviso informativo sobre este nuevo vector y anunció que publicará el advisory completo junto con la próxima actualización.
¿Permite ejecución remota de código?
PHP describe un posible vector de RCE, pero requiere una combinación poco habitual entre configuración de sesiones, cambios realizados durante la ejecución y session upload progress habilitado.
¿Afecta a todos los servidores PHP?
No bajo el escenario documentado actualmente. PHP indica que solamente aparece cuando coinciden condiciones específicas relacionadas con session.serialize_handler y session.upload_progress.
¿Existe un parche para CVE-2026-115560?
Todavía no existe una versión específica publicada para esta CVE. PHP anunció que incluirá la corrección en el próximo lanzamiento normal.
¿Cómo se puede mitigar?
PHP recomienda desactivar temporalmente session upload progress utilizando session.upload_progress.enabled=0 hasta que llegue el parche definitivo.
¿PHP 8.3.36 también está afectado?
La actualización 8.3.36 corrigió las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, pero CVE-2026-115560 todavía espera una corrección específica. Eso no significa que una instalación 8.3.36 sea explotable automáticamente, porque este nuevo escenario exige condiciones adicionales.
¿Tengo que volver atrás una actualización de PHP?
No. Las actualizaciones del 21 de octubre siguen siendo necesarias y corrigen dos vulnerabilidades críticas diferentes. La recomendación actual es mantener PHP actualizado y aplicar la mitigación temporal cuando corresponda.
¿WordPress necesita una nueva actualización por esta CVE?
No existe actualmente una corrección que deba realizar WordPress, porque el problema pertenece a PHP y depende de la configuración y comportamiento del entorno de sesiones.
Después de una emergencia crítica, lo peor que podemos hacer es tratar cada nuevo aviso como si fuera exactamente el mismo problema
CVE-2026-115560 merece atención precisamente porque PHP decidió comunicarla antes de publicar su parche definitivo, pero entender las condiciones resulta tan importante como conocer el titular.
Las vulnerabilidades del 21 de octubre requerían actualizar PHP inmediatamente porque tenían un alcance general y una gravedad crítica confirmada.
La alerta del 23 de octubre describe otro posible camino de ejecución remota de código, pero solamente cuando una aplicación utiliza una combinación poco frecuente de configuración y cambios internos de sesión.
La solución temporal ya está definida, desactivar session upload progress, y quienes aplicaron esa medida hace dos días no necesitan hacer nada nuevo.
Ahora toca esperar el advisory completo, instalar la próxima actualización cuando esté disponible y, sobre todo, seguir trabajando con información técnica confirmada en lugar de asumir que cada publicación alarmante en redes significa que Internet acaba de romperse otra vez.
Una web profesional también necesita seguimiento después de publicarse
Una página puede tener WordPress, plugins y contenidos perfectamente actualizados y aun así depender de componentes del servidor que necesitan seguimiento, como PHP, bases de datos, servicios externos y configuraciones de seguridad.
En byteStudio preferimos construir cada proyecto desde una base propia, entendiendo el negocio, la estrategia y los objetivos desde el comienzo, porque cuando acompañamos todo el proceso también podemos hacernos responsables de cómo evoluciona.
