PHP2Shell, las vulnerabilidades de PHP que ya tienen parche: cómo priorizar el trabajo

PHP2Shell, las vulnerabilidades de PHP registradas como CVE-2026-109618 y CVE-2026-109619, hicieron que el 21 de octubre varias webs de administraciones, colegios y hospitales europeos se apagaran por precaución, según recoge SecurityWeek [1]. Dos días después, el mismo medio seguía sin tener constancia de una sola intrusión con éxito [1].

Esa distancia entre la alarma y los hechos explica bien el momento. PHP2Shell es una amenaza seria pero acotada. No pide pánico ni confianza ciega, sino un orden de trabajo: saber qué PHP tienes, parchearlo, mantener la mitigación recomendada y aislar lo que no se pueda actualizar.

Dos fallos críticos con parche y sin intrusiones confirmadas

Lo confirmado cabe en pocas líneas. Según SecurityWeek, PHP2Shell agrupa dos fallos del motor de PHP que permiten ejecutar código de forma remota sin autenticación, cada uno con una puntuación CVSS v4.0 de 9,2 [1]. El mismo medio explica que Wiz, OpenAI y Calif los encontraron en agosto y que PHP los corrigió el 21 de octubre de 2026 con las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La corrección llegó un día antes de lo previsto porque los identificadores CVE se habían filtrado en internet [1].

La filtración no arruinó el proceso. Johannes B. Ullrich, identificado en la fuente como decano de investigación de SANS.edu, subraya que muchos fabricantes publicaron sus parches sincronizados con PHP.net [2]. Para él, eso prueba que la divulgación coordinada funcionó, aunque algún actor se saltara las reglas y adelantara detalles [2]. BleepingComputer añade que, tras esa fuga, varias empresas de seguridad detectaron intentos de explotación fallidos antes incluso de la divulgación pública [4]. SecurityWeek sitúa el primero de esos intentos, observado por Amazon, el 17 de octubre [1].

La otra mitad del cuadro es lo que todavía no ha pasado. SecurityWeek informa de que ningún fabricante había comunicado un compromiso confirmado [1]. También señala que, en la mañana del 23 de octubre, CISA aún no había incluido ninguno de los dos fallos en su catálogo de vulnerabilidades explotadas conocidas (KEV) [1].

Los intentos de explotación van por delante de los resultados

Entre el ruido y la señal hay bastante trecho. Un analista del SANS ISC revisó las pruebas de concepto publicadas y concluye que construir un exploit universal, fiable y de un solo clic es bastante difícil [3]. Añade que buena parte de ese material parece generado con inteligencia artificial y es de poca calidad [3].

Según su análisis, la prueba de concepto que considera más sensata depende de varias condiciones previas [3]:

• una petición POST con un gran número de campos para forzar la asignación de memoria;
• un límite de memoria muy inferior al habitual en producción;
• un único proceso de trabajo en el servidor;
• conocer de antemano detalles de cómo se compiló PHP en esa máquina.

No es un caso aislado. Según SecurityWeek, Sansec había anticipado una explotación masiva casi inmediata tras el parche, pero rectificó el 22 de octubre [1]. En su nueva valoración, los atacantes necesitan conocer bien el servidor y que se den condiciones concretas, y los exploits públicos fallan contra instalaciones con la configuración por defecto [1]. Sophos, citada por el mismo medio, interpreta la falta de éxitos como una señal de que los atacantes también tienen dificultades [1].

Aun así, sería un error leer todo esto como un riesgo teórico. SecurityWeek recoge que Sophos analizó un intento de instalar Potassium que fue detenido; la empresa considera que es una variante de Mirai capaz de descargar más malware y lanzar ataques DDoS [1]. VulnCheck asegura haber construido un exploit para CVE-2026-109618 que supera la aleatorización del espacio de direcciones (ASLR) en sistemas x86-64 con la configuración recomendada para producción [1]. El exploit está disponible para los clientes de Initial Access Intelligence de VulnCheck [1].

También hay atacantes trabajando en lo mismo. SOCRadar encontró un servidor de atacantes con los ficheros de trabajo a la vista [1]. Contenía una cadena de explotación probada en laboratorio y scripts para comprobar qué webs reales cumplían sus requisitos [1]. Ninguna de las que revisó los cumplía [1].

El propio SANS ISC añade una advertencia más. Al parecer, existe una forma de eludir incluso la corrección disponible, y por eso recomienda mantener session.upload_progress.enabled = 0 hasta la siguiente actualización [3]. Ullrich lo resume así: la vulnerabilidad y el riesgo son reales aunque la explotación masiva no haya llegado todavía; simplemente se está retrasando [2].

Inventariar es el primer paso porque PHP está en casi todas partes

No se puede parchear lo que no se sabe que existe. Según BleepingComputer, PHP está detrás de cerca del 70 % de los sitios web [4]. Según bleepingcomputer.com, el medio cita además estimaciones de VirusTotal: más de 5,1 millones de hosts PHP expuestos en internet, de los cuales unos 3,8 millones tienen al menos un puerto abierto [4]. Son estimaciones de esas fuentes, pero dan una idea de la escala.

El dato más incómodo lo aporta Qualys. Según SecurityWeek, que cita su análisis, alrededor del 71 % de las instancias PHP ejecuta versiones de la 5.4 a la 8.1, ya fuera de soporte [1]. La mayoría nunca recibirá un parche del fabricante [1].

El inventario debe permitir identificar dónde se ejecuta PHP. Conviene revisar la web corporativa, las intranets, los paneles de administración, las aplicaciones de proveedores y los dispositivos con interfaz web para comprobar si utilizan PHP. El SANS ISC recuerda que los equipos embebidos y los appliances preocupan especialmente, porque muchos no se han actualizado o es poco probable que lleguen a recibir un parche [2].

Un orden de trabajo para el equipo técnico: parchear, mitigar y aislar

Con ese mapa delante, la secuencia razonable es esta:

1. Inventariar las aplicaciones y versiones de PHP, incluidas las que vienen dentro de productos de terceros.
2. Aplicar el parche donde exista. Según SecurityWeek, las versiones corregidas son la 8.5.12, la 8.4.27, la 8.3.36 y la 8.2.35, según la rama [1].
3. Mantener la mitigación session.upload_progress.enabled=0. Según el SANS ISC, PHP.net aconsejó dejarla activa hasta la próxima actualización [2].
4. Aislar o segmentar lo que no se pueda actualizar y reducir al mínimo su exposición a internet.
5. Buscar señales de ejecución de comandos posterior a la explotación en los procesos web de PHP.

Lo que se puede actualizar

Para lo que tiene soporte, el SANS ISC es tajante: aplicar el parche sigue siendo la mejor defensa y la única fiable [2]. Las soluciones alternativas y las reglas de los cortafuegos de aplicaciones web (WAF) pueden dar margen, pero ninguna se considera completamente eficaz [2]. Por eso la mitigación de configuración no sustituye al parche. Lo acompaña mientras PHP termina de cerrar el problema.

Lo que no se puede actualizar

Las versiones fuera de soporte y los dispositivos embebidos exigen otra lógica. Si no se pueden actualizar, el SANS ISC recomienda aislar las aplicaciones vulnerables [2]. Recuerda además que las interfaces de administración de routers, los equipos de almacenamiento en red o las cámaras no deberían estar expuestos a internet, usen PHP o no [2].

Ahí conviene aislar equipos industriales que no pueden actualizarse con una segmentación pensada para ese contexto.

La fuente [5] ofrece una consulta de búsqueda de ejecución de comandos posterior a la explotación en servidores PHP. Rastrea comandos de reconocimiento, descargas de ficheros o intérpretes de comandos inversos lanzados desde procesos como Apache o PHP-FPM [5]. El propio equipo advierte de que no es específica de estos dos CVE y de que puede dar falsos positivos según las aplicaciones [5]. Cada hallazgo hay que validarlo.

CVE-2026-115560 es otro asunto: sin parche y con una configuración poco común

Conviene no mezclar expedientes. BleepingComputer informa de que el equipo de seguridad de PHP compartió mitigaciones para CVE-2026-115560, un fallo de ejecución remota de código distinto que no tenía parche en el momento de la noticia [4].

Según el aviso que cita el medio, solo es explotable con una combinación inusual de configuración y código [4]. La aplicación tiene que fijar session.serialize_handler en php_binary o php_serialize y cambiarlo a php en tiempo de ejecución con ini_set() antes de llamar a session_start() [4]. Además, el progreso de subida de sesión debe seguir activo [4].

La mitigación coincide con la de PHP2Shell: desactivar session.upload_progress.enabled. PHP indica que quien ya la aplicó no necesita hacer nada más [4]. El equipo de PHP anunció que trataría este fallo dentro del ciclo normal de versiones [4]. Como la noticia es anterior a cualquier parche, merece la pena revisar el aviso oficial para comprobar si ya existe una actualización.

Apagar la web por precaución es una decisión de riesgo, no un fracaso

Decidir sobre la disponibilidad de un servicio sin el parche aplicado tiene un coste visible. Según securityweek.com, securityWeek recoge que el Gobierno británico informó de 32 servicios no disponibles el 21 de octubre, y de otros que funcionaban solo parcialmente [1]. La causa fueron sobre todo medidas de precaución mientras se aplicaban los parches [1]. SecurityWeek no recoge compromisos confirmados y atribuye la mayoría de esas interrupciones a medidas preventivas durante el parcheo [1].

Esa elección es legítima cuando no se sabe qué hay expuesto ni cuánto tardará el parche. Conviene preparar el inventario y ensayar un procedimiento de parcheo urgente para facilitar esas decisiones. El SANS ISC describe PHP2Shell como un ensayo general de lo que está por venir y anima a hacer ejercicios de simulación y a mantener los inventarios al día [2].

Parchear cierra la puerta; vigilar confirma que nadie entró antes

Hubo intentos de explotación antes de que muchas organizaciones aplicaran el parche, así que actualizar no basta para quedarse tranquilo. Conviene revisar los registros y el comportamiento de los procesos web en busca de ejecución anómala. La consulta de Unit 42 es un buen punto de partida, con la cautela de los posibles falsos positivos [5].

Con PHP2Shell, la respuesta útil no es apagarlo todo ni esperar a ver qué pasa. Es saber qué PHP tienes, parchearlo, mantener la mitigación y aislar lo que no se pueda actualizar.

Si quieres revisar qué está expuesto, considera un ejercicio de pentesting. Considera complementar el parcheo con vigilancia continua mediante un SOC gestionado.