PHP2Shell, día 5: salen los primeros hotfixes de PAN-OS y PHP avisa de una tercera falla sin parche

Quinto día de PHP2Shell y llegan las primeras correcciones para firewalls Palo Alto. Este domingo 25 de octubre de 2026, Palo Alto Networks actualizó su aviso y marcó como liberados los tres hotfixes que tenía programados para el lunes 26: PAN-OS 10.2.18-h13, 11.1.16-h4 y 11.2.10-h16. Salieron un día antes de lo previsto.

En paralelo, el proyecto PHP publicó el viernes 23 un aviso informativo sobre una tercera falla, CVE-2026-115560, que todavía no tiene versión corregida. No es PHP2Shell, pero toca la misma pieza (el progreso de carga de archivos en las sesiones) y la mitigación es la misma que ya muchos aplicaron.

Si llegas tarde a la historia: el 21 de octubre PHP corrigió CVE-2026-109618 y CVE-2026-109619, dos fallas críticas que permiten ejecutar código en un servidor sin usuario ni contraseña. El 22 vimos que firewalls, conmutadores y NAS traen PHP por dentro y el 23 que Palo Alto fijó su calendario de hotfixes del 26 al 30 de octubre.

Palo Alto: quién ya puede actualizar

Así queda la tabla del aviso CVE-2026-109618 tras la revisión del 25 de octubre:

Las demás fechas no se movieron. Palo Alto sigue diciendo que no conoce explotación maliciosa contra sus productos, y la lista de firmas de prevención es la misma del sábado: 543004, 97622 a 97625, 97643, 97647, 97649, 97652, 97653, 97656 a 97659, 97662 a 97664, 97670 a 97674 y 97676 a 97678, con contenido 9162 o posterior.

Panorama (virtual y M-Series) sigue listado como afectado sin una tabla propia: sigue las mismas versiones de PAN-OS. Si tu Panorama administra firewalls que van a recibir el hotfix, revisa en la matriz de compatibilidad de Palo Alto si conviene actualizarlo primero o en la misma ventana, para no quedar con una consola central más vieja que los equipos que gestiona.

PHP: CVE-2026-115560, sin parche todavía

El aviso del 23 de octubre en php.net es corto y, conviene decirlo, tranquilizador. La falla solo se puede aprovechar si se cumplen tres condiciones a la vez:

1. La aplicación configura session.serialize_handler como php_binary o php_serialize.
2. En tiempo de ejecución lo cambia a php con ini_set() antes de llamar a session_start().
3. El progreso de carga de sesiones (session.upload_progress.enabled) sigue activo.

PHP la describe como una vía de ejecución remota poco probable en la práctica. No publicó calificación de severidad ni versiones afectadas: dice que el aviso completo saldrá con la siguiente versión regular de mantenimiento, sin fecha. Por eso, las versiones del 21 de octubre (8.5.12, 8.4.27, 8.3.36 y 8.2.35) corrigen PHP2Shell pero no esta falla.

La recomendación oficial es poner, en php.ini, en el pool de PHP-FPM o en la configuración del servidor:

session.upload_progress.enabled = 0

Si ya lo hiciste como mitigación de CVE-2026-109619, PHP dice que lo dejes así y no hace falta nada más. Las aplicaciones que nunca cambian el manejador de sesiones en tiempo de ejecución pueden dejar la función activa, pero averiguarlo exige revisar código; en un ERP, CRM o tienda en línea con módulos de terceros, apagarla es más rápido y casi nunca se nota (solo afecta barras de progreso de subida que usan esa función de PHP).

Un detalle que repite el aviso del 21: la opción no sirve en .user.ini ni con ini_set(). Va en la configuración que se lee antes de procesar la petición, y luego hay que reiniciar los procesos de PHP-FPM o Apache.

El resto del panorama al 25 de octubre

El rastreador es independiente (no pertenece a PHP ni a ningún fabricante): úsalo como guía y confirma en el aviso oficial de tu marca. Que alguien esté armando listas de servidores con la función de progreso activa es una razón más para apagarla hoy.

Qué hacer hoy

1. Firewalls Palo Alto: ubica tu versión exacta (Dashboard, "Software Version"). Si estás en 10.2.18, 11.1.16 u 11.2.10, el hotfix ya está; agenda la ventana esta misma semana. Si no, confirma tu fecha y prepara el salto de versión base si lo necesitas.
2. Servidores con PHP: comprueba que ya estén en 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o el paquete corregido de tu distribución). Si sigues en PHP 8.2, recuerda que se queda sin soporte el 31 de diciembre.
3. Apaga session.upload_progress.enabled en php.ini o en el pool de FPM, reinicia y verifícalo con php -i | grep upload_progress o con una página phpinfo() temporal que borres al terminar.
4. Equipos con PHP embebido (ClearPass, NAS, conmutadores): aquí no controlas el php.ini; depende del fabricante. Sigue los avisos de cada marca, como el hotfix de ClearPass que ya publicó HPE.
5. Saca de internet lo que no puedas parchar y comprueba desde fuera con nuestro método para escanear vulnerabilidades en tu red.

Si tu firewall necesita una ruta de actualización larga o tienes servidores con PHP que nadie sabe quién administra, en ciberseguridad y servidores hacemos el inventario, aplicamos los parches y dejamos las mitigaciones donde sí funcionan.

Fuentes: aviso de seguridad CVE-2026-109618 de Palo Alto Networks (publicado el 21 y actualizado el 25 de octubre de 2026); noticias de php.net del 21 y 23 de octubre de 2026; catálogo Known Exploited Vulnerabilities de CISA, versión 2026.10.23 (consultado el 25 de octubre); rastreador independiente phpvulnerabilities.app (actualizado el 25 de octubre de 2026).