PHP avisa de una tercera falla tras PHP2Shell: qué deben revisar las empresas
Dos días después de parchar las fallas críticas de PHP2Shell, PHP publicó un tercer aviso de seguridad. Esto es lo que cambia y lo que no.
CVE-2026-115560 llegó el 23 de octubre de 2026, dos días después de los parches de PHP2Shell, y todavía no tiene corrección propia
Un tercer aviso de seguridad llegó dos días después de los parches críticos de PHP2Shell. Todavía no hay parche para esta falla, solo una mitigación.
El equipo de seguridad de PHP publicó el 23 de octubre de 2026 un tercer aviso en apenas dos días: una falla registrada como CVE-2026-115560, justo después de que el proyecto lanzara parches de emergencia para las dos vulnerabilidades críticas conocidas como PHP2Shell. Para cualquier negocio con una tienda en línea, un blog corporativo o un sistema interno corriendo sobre PHP, la pregunta no es si hay que revisar algo, sino qué revisar exactamente, porque instalar el parche crítico no cierra automáticamente la puerta de este tercer aviso.
En resumen
PHP publicó el 23 de octubre de 2026 un tercer aviso de seguridad, CVE-2026-115560, ligado a una configuración poco común en el manejo de sesiones. No es tan grave como las dos fallas de PHP2Shell —CVE-2026-109618 y CVE-2026-109619, ambas con gravedad 9.2 sobre 10 según PHP— y todavía no tiene parche propio: por ahora PHP solo pide desactivar session.upload_progress.enabled.
- CVE-2026-115560 es un aviso informativo, aún sin parche dedicado
- Solo afecta configuraciones poco comunes del manejo de sesiones
- Los parches de PHP2Shell del 21 de octubre siguen siendo obligatorios
Qué pasó: de PHP2Shell al tercer aviso de seguridad
El 21 de octubre de 2026, PHP lanzó actualizaciones de emergencia —las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35— para corregir dos vulnerabilidades críticas que permitían ejecutar código de forma remota sin necesidad de iniciar sesión. La comunidad de seguridad las bautizó como PHP2Shell. Dos días después, el 23 de octubre de 2026, el propio proyecto PHP publicó un tercer aviso, esta vez informativo: una falla registrada como CVE-2026-115560, relacionada con una combinación poco común en la configuración de sesiones.
PHP aclara que este tercer aviso no es un parche nuevo ni sustituye los del 21 de octubre: es una recomendación de configuración mientras el equipo prepara el aviso completo y la corrección definitiva, que llegarán con la próxima versión regular del lenguaje.
Las dos fallas críticas conocidas como PHP2Shell
Las dos fallas de PHP2Shell afectan a todas las instalaciones de PHP que atienden peticiones web, incluyendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP señala que el riesgo es mayor en mod_php, donde ya existe un exploit demostrado que dispara el ataque con una petición sin autenticar, antes de que corra el código de la aplicación.
| CVE | Nombre del problema | Gravedad (CVSS v4.0) | Qué permite |
|---|---|---|---|
| CVE-2026-109618 | Corrupción por manejo de memoria agotada | 9.2 | Ejecutar código antes de que corra la aplicación, aprovechando datos de la petición solo parcialmente inicializados |
| CVE-2026-109619 | Estado global obsoleto que sobrevive en memoria | 9.2 | Ejecutar código reutilizando datos de una petición anterior atendida por el mismo proceso |
| CVE-2026-115560 | Falla en el manejo de sesiones (aviso informativo) | No publicada aún | Solo ocurre bajo una combinación muy específica de configuración de sesiones |
Para corregir PHP2Shell hay que instalar PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la rama que use tu proyecto. PHP 8.1 y versiones anteriores ya no reciben actualizaciones del proyecto PHP, aunque el equipo de seguridad liberó parches mínimos de respaldo para PHP 7.4, 8.0 y 8.1 pensando en quienes compilan desde el código fuente o no cuentan con soporte LTS de su distribución.
La tercera falla: qué es CVE-2026-115560
CVE-2026-115560 solo ocurre bajo una combinación específica: que la aplicación configure el manejador de sesiones como php_binary o php_serialize, y que luego lo cambie a php en tiempo de ejecución con ini_set() antes de llamar a session_start(), con la subida de progreso de sesión todavía activada. El propio PHP dice que esta combinación es poco probable en la práctica, por lo que decidió manejarla en el ciclo de lanzamientos normal en vez de emitir un parche de emergencia.
Las mitigaciones no son parches completos
PHP advierte que las medidas temporales —como fijar memory_limit=-1 o desactivar session.upload_progress.enabled— reducen la exposición a rutas de ataque específicas, pero no hacen segura una instalación. La única solución completa, para PHP2Shell y para cualquier CVE futuro, es actualizar a la versión corregida.
Qué debe revisar tu negocio ahora mismo
Si tu negocio tiene sitios, tiendas o sistemas internos corriendo en PHP, hay tres frentes que revisar esta semana: la versión que corre en producción, si ya se aplicó el parche crítico del 21 de octubre, y si la aplicación usa el patrón de configuración de sesiones que activa el aviso del 23 de octubre.
Confirma tu versión real en producción
Pregunta a tu hosting o a quien administre el servidor qué versión de PHP corre: solo 8.5.12, 8.4.27, 8.3.36 y 8.2.35 tienen el parche de PHP2Shell.
Aplica el parche o, si no puedes, la mitigación
Si no es posible actualizar de inmediato, PHP lista medidas temporales para cada CVE, pero deja claro que no sustituyen la actualización.
Revisa la configuración de sesiones
Verifica si tu aplicación cambia el manejador de sesiones en tiempo de ejecución; si no lo hace, el aviso del 23 de octubre no te aplica.
Qué dice PHP sobre la mitigación mientras no hay parche para CVE-2026-115560
Es la misma mitigación que PHP ya recomendaba desde el 21 de octubre de 2026 para CVE-2026-109619. Quien la aplicó entonces y reinició todos sus procesos ya está cubierto también para el aviso del 23 de octubre.
Por qué la IA no reemplaza la revisión humana
Ninguna herramienta de inteligencia artificial decide por sí sola si hay que actualizar PHP hoy o el lunes. Un sistema de monitoreo o un agente puede avisar que salió un CVE nuevo, revisar registros o incluso sugerir el comando de actualización, pero confirmar la versión real en producción, decidir la ventana de mantenimiento y verificar que el parche quedó aplicado sigue siendo una decisión humana.
La automatización avisa, no decide
Una alerta automática sin alguien que la revise y actúe es tan útil como no tener alerta. El caso de PHP2Shell y su tercer aviso muestra que mantener la infraestructura al día sigue siendo una tarea de revisión humana, aunque la detección se apoye en herramientas automáticas.
Qué significa esto para empresas en México y Latinoamérica
Buena parte de las tiendas en línea, blogs corporativos y sistemas internos en México y Latinoamérica corren sobre PHP, ya sea directamente o a través de plataformas como WordPress, WooCommerce o Laravel. Una alerta de seguridad mal atendida no distingue entre una multinacional y un negocio local: el riesgo es el mismo si el servidor sigue expuesto.
Tiendas en línea con WooCommerce
Un ecommerce sobre WordPress y WooCommerce corre sobre PHP; si el hosting no aplicó el parche del 21 de octubre, el checkout y los datos de clientes quedan expuestos a los vectores de PHP2Shell.
Agencias que administran sitios de clientes
Una agencia que da mantenimiento a varios sitios en PHP necesita confirmar versión por versión cuáles ya tienen el parche y cuáles siguen pendientes, no asumir que todos se actualizaron igual.
SaaS construidos sobre PHP o Laravel
Un producto propio en PHP hereda la misma exposición que cualquier instalación que atiende peticiones web, incluyendo PHP-FPM y FrankenPHP, según el propio aviso de PHP.
Soporte técnico y hosting compartido
Un equipo de soporte que administra hosting compartido debe revisar si la configuración del servidor activa el patrón de sesiones que describe CVE-2026-115560.
¿Ya hay un parche para CVE-2026-115560?
No, todavía no. PHP dijo el 23 de octubre de 2026 que publicará el aviso completo y la corrección junto con su próxima versión regular; por ahora la recomendación es desactivar session.upload_progress.enabled.
¿Si ya apliqué el parche de PHP2Shell del 21 de octubre, estoy protegido del tercer aviso?
Sí, si ya configuraste session.upload_progress.enabled=0 como mitigación de CVE-2026-109619 y reiniciaste los procesos, no necesitas hacer nada más, según el propio aviso de PHP.
¿Qué versiones de PHP corrigen las fallas de PHP2Shell?
Las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen las dos vulnerabilidades críticas conocidas como PHP2Shell, CVE-2026-109618 y CVE-2026-109619.
¿Qué pasa si uso PHP 8.1 o una versión anterior?
El proyecto PHP ya no publica actualizaciones de seguridad para PHP 8.1 o versiones anteriores; hay que contactar al proveedor de hosting o de soporte LTS por un backport, o migrar a una versión soportada.
¿Cómo sé si mi aplicación es vulnerable a CVE-2026-115560?
Solo si tu aplicación configura el manejador de sesiones como php_binary o php_serialize y luego lo cambia a php en tiempo de ejecución con ini_set() antes de llamar a session_start(), con la subida de progreso de sesión activada; PHP dice que esta combinación es poco común en la práctica.
¿Puede una IA detectar y corregir esto sola?
No. Una automatización puede avisar que hay un CVE nuevo, pero decidir qué parchar, cuándo reiniciar los servidores y si una mitigación aplica a tu configuración sigue siendo una tarea humana.
Fuentes
¿Tu negocio corre sobre PHP y no sabes por dónde empezar a revisar?
En Zadrig Technology revisamos la versión de PHP en producción, la configuración de tu hosting y qué mitigaciones aplican a tu caso. Agenda una demostración y te decimos exactamente qué actualizar.
Escríbenos por WhatsApp
