Las actualizaciones han ido acompañadas de una reducción de los sistemas vulnerables detectados. Sin embargo, la explotación está confirmada y Palo Alto Networks ha documentado ataques contra equipos con su interfaz de administración expuesta a Internet.
Han pasado diez días desde que PHP publicó sus actualizaciones de emergencia. Los dos fallos que provocaron la alerta, CVE-2026-109618 y CVE-2026-109619, permiten ejecutar código de forma remota sin autenticación en instalaciones vulnerables y recibieron una puntuación de gravedad de 9,2 sobre 10. Conocidos conjuntamente como PHP2Shell, afectan tanto a servidores web como a productos que incorporan PHP entre sus componentes.
Durante estos días se ha reducido la exposición detectada por los investigadores, pero también se han confirmado ataques. El 26 de octubre, CISA incluyó ambas vulnerabilidades en su catálogo de fallos explotados, y el 29 Palo Alto Networks informó de una campaña contra sus equipos.
Los ataques llegan a los firewalls
Palo Alto Networks ha confirmado que los atacantes están aprovechando PHP2Shell contra interfaces de administración de PAN-OS expuestas a Internet. En la campaña analizada, combinaron los fallos de PHP con una vulnerabilidad del núcleo de Linux para conseguir acceso como root, el usuario con mayores privilegios del sistema. Dream Research publicó los primeros detalles y Unit 42, el equipo de investigación de Palo Alto, verificó posteriormente las herramientas utilizadas y los resultados.
La compañía pide retirar el acceso público a esas interfaces, restringir la administración a direcciones internas de confianza e instalar las correcciones de PAN-OS. Los parches disponibles interrumpen la cadena de ataque observada. El fabricante también recuerda que la interfaz de gestión no está expuesta a Internet por defecto: esa configuración debe haberse habilitado.
Baja el número de servidores expuestos
El seguimiento de Wiz ofrece algunos datos sobre la respuesta de los administradores. En su informe del 27 de octubre, la empresa registró una caída aproximada del 67 % en las máquinas vulnerables accesibles desde Internet dentro de su muestra. El número de organizaciones observadas con al menos una instalación expuesta descendió un 47,9 %.
Las cifras no representan a todos los servidores del mundo ni permiten saber cuántos han instalado las actualizaciones. Parte del descenso puede deberse a equipos retirados o a restricciones de acceso. Wiz tampoco había observado una explotación completada en los intentos recogidos por sus propios sistemas, algo que no contradice los ataques confirmados por otros investigadores: cada informe recoge la actividad que su autor ha podido analizar.
¿Qué actualizaciones toca comprobar?
Los dos fallos originales quedaron corregidos en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, dependiendo de la rama utilizada. En Linux conviene consultar también el aviso de la distribución, ya que algunos proveedores incorporan los parches a paquetes anteriores sin cambiar la versión principal que aparece instalada.
Las instalaciones antiguas tienen una situación diferente. Ante la gravedad del problema, el equipo de PHP publicó correcciones mínimas de código fuente para las ramas 7.4, 8.0 y 8.1. Están destinadas a facilitar el trabajo de quienes compilan sus propios paquetes o no disponen de mantenimiento extendido no suponen la recuperación del soporte ordinario de esas versiones.
En Windows hubo otra actualización el 26 de octubre. Los paquetes 8.5.12-1, 8.4.27-1, 8.3.36-1 y 8.2.35-1 incorporan una corrección para Brotli, una biblioteca de compresión. Es un problema distinto de PHP2Shell que puede afectar a aplicaciones que activan la descompresión automática de respuestas HTTP mediante cURL. El sufijo «-1» identifica la revisión de las dependencias del paquete; la versión del intérprete permanece igual.
Microsoft recordó el 30 de octubre que Windows Update no corrige las instalaciones de PHP añadidas por el usuario. Es necesario actualizarlas por separado y reiniciar los procesos correspondientes para que utilicen los archivos nuevos.
Sigue pendiente una tercera vulnerabilidad
El aviso del 23 de octubre añadió CVE-2026-115560, una tercera posibilidad de ejecución remota de código que requiere una configuración poco habitual. Para que pueda explotarse, la aplicación debe cambiar durante su ejecución el mecanismo con el que guarda las sesiones y mantener activado el seguimiento del progreso de las subidas de archivos. Las aplicaciones que no realizan ese cambio no están expuestas a esta vía.
PHP mantiene prevista su corrección para el ciclo ordinario de actualizaciones. Mientras tanto, recomienda establecer session.upload_progress.enabled=0. Quienes ya aplicaron esta medida y la mantienen no necesitan realizar otra actuación específica para este tercer fallo. Los parches del 21 de octubre siguen corrigiendo las dos vulnerabilidades iniciales.
