PHP2Shell en productos industriales OT: qué han avisado los fabricantes y por qué el inventario decide

Identificar los productos afectados por PHP2Shell en productos industriales OT requiere consultar los avisos de sus fabricantes; el parche se publicó el 21 de octubre. SecurityWeek informa de productos industriales afectados y de avisos publicados por Siemens, Schneider Electric, ABB, Rockwell Automation y Johnson Controls [3].

Por eso el cuello de botella no es descargar una actualización. Es el inventario: saber qué componentes embebidos de la planta llevan un intérprete PHP y qué ha dicho de cada uno su fabricante.

PHP2Shell pasó de los sondeos a los shells funcionales en cuestión de días

PHP2Shell es el nombre que agrupa los fallos críticos CVE-2026-109618 y CVE-2026-109619. Según SecurityWeek, ambos permiten la ejecución remota de código (RCE) sin autenticación, y PHP los corrigió el 21 de octubre después de que parte de la información se filtrara en Internet [1]. BleepingComputer añade que el equipo de seguridad de PHP había pedido el día anterior a los administradores que se prepararan para instalar las actualizaciones en cuanto estuvieran disponibles [2].

Los atacantes se adelantaron al parche. SecurityWeek sitúa el primer intento de explotación el 17 de octubre, antes de que existiera la corrección, y recoge que Cloudflare ha registrado desde entonces un volumen masivo de intentos [3]. Durante días ninguna empresa de seguridad confirmó una ejecución de código con éxito. Sin embargo, según el mismo medio, los investigadores ya habían desarrollado exploits capaces de saltarse la aleatorización del espacio de direcciones (ASLR) [1].

El cambio llegó el 24 de octubre. Según SecurityWeek, los sensores de Adel Karimi, investigador de Perplexity, registraron 35 shells lanzados contra sus honeypots, y 32 de ellos procedían de una sola dirección IP [1]. Los atacantes encadenaron peticiones HTTP: unas agotaban la memoria de PHP, otras filtraban su contenido y la última ejecutaba un comando. Karimi considera que la actividad encaja con la explotación de CVE-2026-109618 [1].

BleepingComputer detalla el caso con más precisión. Los honeypots de Karimi, responsable de detección y respuesta en Perplexity, registraron ejecución remota de código confirmada contra una instalación Apache mod_php con PHP 8.4.26 [2]. La respuesta del servidor incluyó un volcado de cookies decodificado. Una dirección de función calculada a partir de ese volcado con los offsets del exploit público aparecía después en la carga de ejecución. Karimi lo describió como una RCE confirmada con filtración de memoria aprovechable, y no como un simple fallo seguido de un proceso sospechoso [2].

El propio investigador advirtió que su configuración era deliberadamente favorable, con un único worker de mod_php. Según Karimi, sus resultados no miden la fiabilidad del exploit con otros números de workers, compilaciones de PHP o aplicaciones [2]. Marcus Hutchins, de Expel, la calificó como la confirmación de mayor calidad que había visto hasta entonces [2]. Por su parte, la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA) añadió el 23 de octubre una regla de detección Sigma a su alerta. Según SecurityWeek, en la mañana del 26 de octubre aún no había incluido los fallos en su catálogo de vulnerabilidades explotadas conocidas (KEV) [1].

Todo esto ocurrió en una semana especialmente cargada. El resumen semanal de The Hacker News describe fallos críticos de ejecución remota apareciendo por todas partes y equipos de seguridad con más parches urgentes de los que pueden absorber [5]. Entre ellos figura CVE-2026-111497, conocido como Node2Shell, un fallo en la librería de descompresión Brotli de Google que también podía permitir ejecución remota sin autenticación. Según el mismo resumen, se ha corregido en librerías y plataformas que dependen de ella, como Node.js, Python o Envoy [5]. Si buscas el contexto web del problema, puedes consultar nuestro análisis general de las vulnerabilidades PHP2Shell. Aquí interesa otra cosa: qué ocurre cuando ese PHP no está en una web, sino en la planta.

Los fabricantes industriales ya han publicado avisos, pero con respuestas dispares

Según SecurityWeek, varios grandes fabricantes industriales han confirmado que algunos de sus productos industriales y de tecnología operativa (OT) están afectados. Otros siguen evaluando su exposición y otros han concluido que no lo están [3]. Según securityweek.com, las versiones corregidas de PHP que cita el medio son la 8.5.12, la 8.4.27, la 8.3.36 y la 8.2.35 [3]. En un entorno industrial, sin embargo, esas versiones dicen poco si no sabes qué versión lleva cada equipo.

Los avisos muestran hasta qué punto el PHP puede estar escondido. Según SecurityWeek [3], los casos más ilustrativos son estos:

• Schneider Electric declara afectados EcoStruxure Security Expert, ProLeiT LINEoptimize y EcoStruxure Control Engineering. Hay versión corregida para el primero y una remediación del soporte de ProLeiT para el segundo. Los usuarios del tercero, por ahora, solo pueden aplicar mitigaciones.
• Siemens indica que los dispositivos Ruggedcom APE1808 con determinadas versiones de PAN-OS de Palo Alto Networks están afectados. Remite a su soporte para la información del parche y a las medidas alternativas del fabricante del sistema operativo.
• ABB advierte de que las entregas de su sistema de ejecución de fabricación (MES) que incluyen DokuWiki, usado para mostrar páginas de ayuda, están afectadas. Su filial B&R declara afectado el sistema de control de procesos APROL hasta la versión R 4.4-65, con parches previstos para el 26 y el 29 de octubre.
• Rockwell Automation sigue revisando si alguno de sus productos depende de una versión vulnerable de PHP. En la fecha de su aviso no había ninguno confirmado como afectado.
• Johnson Controls ha publicado parches para varias líneas Illustra y ha corregido Visonic PowerManage en la versión 5.0.45.

La lista continúa con otros proveedores. Belden reconoce que todas las versiones de NetModule NRSW están afectadas, aún sin parche, y recomienda desactivar la interfaz web. Hitachi Energy sigue investigando, mientras que Moxa ha determinado que ninguno de sus productos está afectado [3].

De estos avisos se desprende una idea práctica: un aviso no equivale a un parche. Además, un producto «en evaluación» no es un producto sano, sino uno cuyo estado aún se desconoce. Mientras dure esa incertidumbre, toca actuar con medidas compensatorias.

El verdadero cuello de botella es el inventario de componentes embebidos

Las cifras globales impresionan, pero no resuelven el problema de una planta. PHP sostiene en torno al 70 % de los sitios web de Internet, según BleepingComputer e Infosecurity Magazine [2][4]. Según bleepingcomputer.com, bleepingComputer recoge estimaciones de VirusTotal de más de 5,1 millones de hosts PHP expuestos en Internet y aproximadamente 3,8 millones con al menos un puerto abierto a ataques [2].

Las cifras citadas se refieren al uso de PHP en sitios web y a hosts PHP expuestos en Internet; no deben utilizarse como un recuento de productos OT. Precisamente por eso, la pregunta útil no es «¿hemos parcheado PHP?», sino «¿qué equipos de la planta incluyen un intérprete PHP, en qué versión y quién lo actualiza?».

Por qué el parche de PHP no se aplica a ciegas en OT

Los ejemplos de los fabricantes dibujan dos situaciones muy distintas. En el caso de ABB, el cliente debe actualizar los paquetes PHP de los servidores que alojan DokuWiki [3]. En otros, como los dispositivos Netbiter de HMS Networks, la corrección llega como una actualización de firmware del fabricante [3]. En el Ruggedcom APE1808, Siemens identifica como afectados los dispositivos que ejecutan determinadas versiones de PAN-OS de Palo Alto Networks [3].

A juicio del equipo editorial, esta mezcla explica por qué en OT no basta con instalar PHP 8.4.27 donde se encuentre. Antes de modificar un componente interno de un equipo industrial, conviene consultar las indicaciones de su fabricante. Conviene planificar con el responsable de operación cuándo aplicar los cambios. La vía razonable pasa por identificar el equipo, localizar el aviso que le corresponde y aplicar lo que el fabricante indique. Si no hay indicación, quedan las medidas compensatorias. Construir esa visibilidad es la base de cualquier estrategia de seguridad OT industrial.

Qué preguntar al fabricante de cada equipo

Para cada equipo o aplicación con interfaz web en la planta, conviene obtener del fabricante o del integrador respuestas a estas preguntas:

1. ¿Incluye el producto un intérprete PHP? Si es así, ¿en qué versión?
2. ¿Cuál es el estado del aviso para este producto: afectado, en evaluación o no afectado?
3. ¿Existe un parche, una versión corregida o una mitigación documentada? ¿Quién debe aplicarla: el fabricante, el integrador o tu equipo?
4. ¿Está expuesta la interfaz web a redes no confiables o puede desactivarse sin afectar a la operación?

No todo aviso de PHP exige la misma urgencia: una tabla para priorizar

La misma semana trajo otro fallo de PHP que conviene no confundir con PHP2Shell. Según Infosecurity Magazine, el equipo de seguridad de PHP advirtió el 23 de octubre de CVE-2026-115560, otra vulnerabilidad de ejecución remota que no se corregirá hasta la próxima versión [4]. El motivo es que solo se da con una combinación inusual de configuración y código. La aplicación debe fijar session.serialize_handler en php_binary o php_serialize, cambiarlo a php en tiempo de ejecución con ini_set() antes de llamar a session_start() y mantener activo el progreso de subida de sesiones [4]. Como mitigación, PHP recomienda fijar session.upload_progress.enabled=0, la misma medida que ya aconsejó el 21 de octubre en el aviso de CVE-2026-109619 [4].

La comparación ayuda a ordenar el trabajo:

A partir de ahí, el orden de prioridad que proponemos para los equipos de la planta es un criterio editorial, no una norma. Primero, los productos que el fabricante declara afectados y cuya interfaz es alcanzable desde redes no confiables. Después, los afectados en segmentos aislados y los que siguen en evaluación con exposición. Por último, los declarados no afectados, cuyo aviso conviene archivar como evidencia. Si tu organización está en el ámbito de la directiva europea NIS2, también vale la pena revisar cómo encaja esta priorización documentada con los requisitos de NIS2 para el sector industrial y OT.

Mientras llega el parche del fabricante, la detección sostiene la defensa

Para los equipos sin parche o en evaluación, cuentan las medidas que no dependen del fabricante. La primera es limitar qué interfaces web son alcanzables y desde dónde, en línea con la recomendación de Belden de desactivar la interfaz web mientras no exista corrección [3]. También ayuda vigilar los procesos y el tráfico anómalos en los servidores y equipos que ejecutan PHP, y seguir de cerca los avisos de cada proveedor.

El caso de Karimi muestra por qué vigilar importa. Karimi documentó la ejecución remota mediante la respuesta con memoria filtrada y la carga posterior que utilizaba una dirección derivada de ella [2]. Mientras llega el parche, conviene reforzar la visibilidad sobre la actividad de los equipos afectados. HMS Networks, por ejemplo, ha comunicado que corrigió o eliminó versiones vulnerables de PHP de sus servicios Talk2M y su servidor de documentación Argos, y que no encontró indicadores de compromiso [3]. Conviene conservar registros que faciliten la búsqueda de indicadores de compromiso.

Parchear PHP es la parte fácil. Lo difícil es saber qué equipos industriales lo llevan dentro, y quien tenga ese inventario y los avisos de sus fabricantes decidirá con ventaja. Si tu equipo necesita apoyo para ganar esa visibilidad de forma continua, un servicio de monitorización y respuesta gestionadas (SOCaaS/MDR), con un centro de operaciones de seguridad (SOC) externo, puede complementar el inventario mientras los fabricantes terminan de publicar sus correcciones.