PHP: tercera RCE CVE-2026-115560 sin parche, ataques a PHP2Shell

El 23 de octubre de 2026, dos días después de los parches de emergencia para PHP2Shell, el equipo de seguridad de PHP publicó un aviso informativo sobre una tercera vulnerabilidad de ejecución remota de código, CVE-2026-115560. Todavía no hay una versión corregida: llegará con la próxima versión ordinaria. Mientras tanto existe una mitigación de configuración, la misma que ya se recomendó el 21 de octubre para uno de los dos fallos de PHP2Shell.

Nuestro artículo del 20 de octubre recogía el anuncio de las dos vulnerabilidades críticas CVE-2026-109618 y CVE-2026-109619. A continuación, las novedades: la tercera CVE, las versiones corregidas publicadas el 21 de octubre y el estado de los ataques.

CVE-2026-115560: las condiciones

Según el aviso de PHP, recogido por BleepingComputer, The Register y Security Affairs, y según el aviso del KrCERT/CC coreano, el fallo está en la gestión de sesiones y solo es explotable si se cumplen todas estas condiciones:

1. en la configuración, session.serialize_handler está fijado en php_binary o php_serialize;
2. la aplicación lo vuelve a poner en php durante la ejecución con ini_set(), antes de llamar a session_start();
3. session.upload_progress.enabled está activo, como ocurre por defecto.

El proyecto PHP considera esta combinación improbable en el uso real y por eso la trata en el ciclo ordinario, con un aviso completo en la próxima versión. Las aplicaciones que no cambian el serialize handler durante la ejecución no están expuestas por esta vía, aunque tengan activo el upload progress.

Por ahora, según Security Affairs, PHP no ha indicado las versiones afectadas, la fecha de la corrección ni una puntuación de gravedad, y no ha explicado si el fallo comparte causa con CVE-2026-109619. Las versiones del 21 de octubre no lo corrigen. Ninguna de las fuentes informa de ataques contra esta CVE.

PHP2Shell: parches, intentos de explotación y versiones sin soporte

Los dos fallos anunciados el 20 de octubre, conocidos ahora como PHP2Shell, son errores de seguridad de memoria en el motor de PHP (The Register), con una puntuación CVSS v4.0 de 9.2 y ejecución de código sin autenticación. Según Security Affairs, el código defectuoso se remonta a PHP 5.4, de 2012. Las correcciones salieron el 21 de octubre con PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Sobre la explotación, las fuentes coinciden en un punto: a 23 de octubre no se ha confirmado públicamente ningún compromiso con éxito. Los intentos, sin embargo, son numerosos:

• Amazon observó los primeros intentos el 17 de octubre, antes de los parches, con cargas e infraestructuras distintas que apuntan a varios actores (SecurityWeek, BleepingComputer, The Record);
• Cloudflare, según Security Affairs, contó decenas de miles de intentos en los 45 minutos siguientes a la divulgación y millones antes del 22 de octubre;
• Sophos, Arctic Wolf, Hunt.io y Cobalt relacionan parte de los intentos con botnets de tipo Mirai (Potassium), que intentan instalar malware para ataques DDoS; Sophos retiró un primer informe de explotación con éxito.

Las fuentes discrepan sobre la viabilidad. Según Sansec, citada por SecurityWeek, los exploits públicos fallan contra instalaciones con la configuración por defecto; Mandiant, citada por The Register, afirma en cambio haber validado algunos PoC capaces de RCE contra instalaciones por defecto con mod_php, pero no con PHP-FPM. VulnCheck dice tener un exploit para CVE-2026-109618 que evita el ASLR en x86-64 con la visualización de errores desactivada, la configuración recomendada en producción; está reservado a sus clientes. SOCRadar encontró en un servidor del atacante una cadena de exploits para PHP 8.4.26 sobre Apache mod_php, probada sin éxito en una veintena de sitios.

La técnica MITRE ATT&CK es T1190 (explotación de aplicaciones expuestas a Internet). Las fuentes no publican indicadores de compromiso.

Las actualizaciones avanzan despacio. Según los datos de Censys que recoge The Record, el 22 de octubre más de 41 millones de servicios PHP expuestos en Internet tenían versiones afectadas y alrededor de 1 millón una versión corregida. Qualys, con datos anónimos de sus clientes, calcula que el 71% de las instancias usa las ramas 5.4 a 8.1, sin soporte, que en su mayoría no recibirán parches del proyecto.

Impacto en Europa e Italia

Según SecurityWeek, el 21 de octubre varios sitios de administraciones públicas, escuelas y hospitales europeos se desconectaron por precaución durante las actualizaciones, y en el Reino Unido 32 servicios del gobierno quedaron fuera de servicio. El DNSC rumano también publicó una alerta sobre las dos vulnerabilidades.

Para las entidades sujetas a NIS2 sigue valiendo lo que escribimos el 20 de octubre: documentar inventario, prioridades y plazos de actualización, y valorar la notificación al CSIRT nacional (CSIRT Italia en Italia) si hay un incidente significativo. En sanidad hay que revisar primero los portales para pacientes basados en PHP, también los gestionados por proveedores externos.

Qué hacer ahora

1. Actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o a las versiones corregidas de tu distribución o de tu hosting, y comprueba la versión que usa de verdad el servidor web (PHP-FPM o módulo), no solo la de php -v.
2. Configura session.upload_progress.enabled=0 en php.ini y en los pools de PHP-FPM y reinicia todos los workers de PHP, como indica el KrCERT/CC. Si ya la aplicaste para CVE-2026-109619, mantenla: según PHP no hace falta nada más.
3. Revisa el código: busca llamadas a ini_set() sobre session.serialize_handler en tus aplicaciones y en componentes de terceros.
4. Versiones sin soporte: pregunta a tu proveedor de la distribución o del hosting si tiene correcciones; si no, planifica la migración y, mientras tanto, limita la exposición pública.
5. Prioridad a mod_php: las instalaciones con Apache mod_php son las que centran los PoC validados por Mandiant y la cadena encontrada por SOCRadar.
6. Vigila los registros de los servidores web en busca de peticiones anómalas y los hosts PHP por si aparecen procesos o conexiones salientes inesperados.

Cómo ayuda ARXDOME

ARX Shield muestra para cada máquina los paquetes con vulnerabilidades abiertas, destacando las ya explotadas; el inventario de ARX Sentry recoge el software y los procesos de los servidores con el agente, útil para encontrar PHP y PHP-FPM. ARX Expose indica qué servicios públicos de tu empresa exponen productos reconocidos, para que empieces por los accesibles desde Internet.

Última actualización: 24 de octubre de 2026