Un tercer fallo de PHP2Shell, CVE-2026-115560, no tendrá parche de emergencia: a quién afecta y qué hacer

Qué ha anunciado PHP

El viernes 23 de octubre, la Fundación PHP explicó a The Register que ha reservado el identificador CVE-2026-115560 para un tercer fallo de ejecución remota de código, que se suma a los dos que forman PHP2Shell. PHP publicará el aviso completo y el software corregido con la próxima versión regular, y de momento solo ha difundido un aviso informativo en su web.

Elizabeth Barron, directora ejecutiva de la Fundación PHP, dijo que el fallo requiere una combinación muy improbable de configuración y código de aplicación específico, que no esperan que ocurra en el uso práctico de PHP, y que puede mitigarse con un ajuste de configuración. Por eso no habrá versión de emergencia.

Cuándo afecta de verdad: tres condiciones

Según PHP, el camino de ataque exige que se cumplan las tres cosas a la vez:

1. La aplicación configura session.serialize_handler como php_binary o php_serialize.
2. Después lo cambia a php en tiempo de ejecución con ini_set(), antes de llamar a session_start().
3. La función de progreso de subida de sesión, session.upload_progress.enabled, está activada. Lo está por defecto.

Las aplicaciones que nunca cambian el manejador de serialización en tiempo de ejecución no están expuestas por este camino, aunque tengan activado el progreso de subida. Por eso PHP considera que no representa el riesgo masivo de los dos primeros fallos.

Lo que todavía no se sabe

Según recoge Security Affairs, PHP aún no ha identificado qué versiones están afectadas, no ha confirmado cuándo llegará la corrección, no ha asignado una puntuación de gravedad y no ha explicado si el fallo comparte causa con CVE-2026-109619. Conviene tenerlo presente: hasta que el aviso completo salga, la valoración de "improbable" es la de PHP, no un análisis independiente.

Qué hacer

• Si ya aplicaste session.upload_progress.enabled=0 como medida provisional por PHP2Shell y lo mantienes, ya estás cubierto: no hace falta nada más para este fallo.
• Si no lo has hecho, aplícalo en el php.ini o en el pool de PHP-FPM y reinicia PHP, para que surta efecto antes de que se procese la petición. Mantenlo hasta la próxima versión regular de corrección.

; php.ini
session.upload_progress.enabled = 0

; pool de PHP-FPM
php_admin_value[session.upload_progress.enabled] = 0

• Efecto secundario: dejará de funcionar el progreso de subida basado en sesión. Pocas webs lo usan; según Codeable, WordPress no lo usa.
• Si desarrollas la aplicación, busca en tu código ini_set('session.serialize_handler' y revisa si el php.ini o el pool lo fijan a php_binary o php_serialize. Si tu aplicación lo cambia en tiempo de ejecución, aplica la medida cuanto antes.
• Si estás en hosting compartido o gestionado, pregunta a tu proveedor en lugar de tocar la configuración del servidor.
• Comprueba el resultado: php -i muestra la configuración de la línea de comandos, que puede no coincidir con la de tu servidor web. Verifica el pool o pide la confirmación a tu proveedor.

El estado de PHP2Shell a 23 de octubre

La Fundación PHP afirma que no tiene evidencia de explotación exitosa de los dos primeros fallos antes de su divulgación, ni de explotación en versiones parcheadas, y que OpenAI, Wiz y Calif, con quienes trabaja, no le han señalado problemas en sistemas parcheados. Los investigadores consultados por The Register documentan intentos de explotación, pero ningún ataque exitoso confirmado en el entorno real.

Charles Carmakal, director de tecnología de Mandiant, advirtió en LinkedIn de que la explotación puede haber comenzado ya de forma limitada y de que la amenaza es viable y muy seria. Señaló que circulan varios exploits de prueba de concepto, muchos de los cuales parecen programados "por intuición" y no consiguen ejecutar código remoto. Pero Mandiant ha validado algunos que sí lo logran contra instalaciones predeterminadas de mod_php, aunque no contra PHP-FPM. El panorama de los ataques se detalla en el seguimiento de PHP2Shell 48 horas después.

Preguntas frecuentes

Conclusión

El tercer fallo no cambia lo esencial: lo urgente sigue siendo actualizar PHP por los dos primeros. Es, además, un recordatorio de por qué conviene aplicar la medida de session.upload_progress.enabled=0 aunque ya hayas parcheado: cubre este nuevo camino hasta que llegue su corrección. Y también de que la historia de PHP2Shell no está cerrada: los avisos seguirán actualizándose.

Fuentes: The Register (23 de octubre de 2026), aviso informativo de PHP (php.net), Security Affairs, Techaeris, Codeable y la publicación de Charles Carmakal (Mandiant) en LinkedIn, según The Register. Información a 23 de octubre de 2026. Este artículo es informativo y no sustituye a un profesional.