Lo que llegó al señuelo eran tres nodos: una pestaña vacía, un inject y un exec. El inject con once: true para que arrancara solo al desplegarse, y detrás el exec, que es el nodo cuyo trabajo documentado es ejecutar órdenes del sistema. Es lo que monta cualquiera que use la herramienta para lo que sirve.
El 30 de octubre de 2026, uno de los señuelos de VulnCheck recogió ese envío: un POST contra /flows. Esa ruta no añade un flujo. La documentación de la API lo dice en cinco palabras —«Set the active flow configuration»— y con el tipo de despliegue que se aplica por defecto, full, «all existing nodes are stopped before the new configuration is started». El envío del atacante empezaba por una pestaña vacía, así que el mismo POST que le abre la puerta se lleva por delante las automatizaciones que hubiera en marcha. Nadie lo ha contado así, y es la parte que más caro sale.
La orden dentro del nodo exec era echo <base64> | base64 -d | sh, con tres capas de codificación una dentro de otra, y al final un binario llamado bot-linux-amd64 que se descargaba a /dev/shm/.b y se lanzaba con setsid, con nohup de reserva. En otros intentos, un guion intermedio y un fichero en /tmp/.kworker; en algunos, webshells montadas con un nodo http in que pasaba por un nodo function antes de llegar a otro exec. Un punto de entrada HTTP nuevo, construido con las piezas de la paleta.
Un diez que puntúa un ajuste
El identificador es CVE-2026-58115 y lleva un 10,0 en CVSS 3.1 y otro 10,0 en CVSS 4.0. Lo asignó Siemens en su aviso SSA-834709 del 11 de agosto de 2026, para los SIMATIC IoT2050 Advanced con Industrial OS y Node-RED instalado. El resumen del aviso es una frase sin adornos: «could allow an unauthenticated remote attacker to create malicious flows and execute arbitrary code on the underlying server with maximum privileges». La palabra que importa ahí es crear.
La documentación oficial de Node-RED lo dice desde mucho antes que el aviso, en su propia página de seguridad: «By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes». Y acto seguido, la condición: «This is only suitable if you are running on a trusted network». El ajuste que lo cambia se llama adminAuth y viene comentado en settings.js.
Siemens publicó Industrial OS V4.3.4.1, y conviene decir qué dice y qué no dice el aviso al respecto: indica «update to V4.3.4.1 or later version» sin detallar qué cambió por dentro. Lo que sí detalla es lo que ofrece mientras actualizas, y ahí está lo revelador: endurecer la instalación de Node-RED siguiendo la guía del propio proyecto, o desinstalar Node-RED del aparato. Ninguna de las dos es un parche.
Y no es la primera vez que alguien le pone un diez a este mismo ajuste. En julio de 2025, CERT@VDE asignó CVE-2025-41656 al IndustrialPI 4 de Pilz, también con 10,0, y la redacción es prácticamente la misma frase: «An unauthenticated remote attacker can run arbitrary commands on the affected devices with high privileges because the authentication for the Node_RED server is not configured by default». Otro fabricante, otro año, el mismo ajuste comentado. Trece meses separan los dos avisos y ninguna de las dos veces hubo nada que parchear en Node-RED.
Eso cambia dónde está el control. Contra un desbordamiento de memoria, el control es el parche. Aquí el parche de Siemens solo existe si tienes el aparato de Siemens. Si tu Node-RED corre en una máquina virtual tuya —que es como suele estar montado—, no hay versión a la que subir por este CVE, porque el CVE no es contra Node-RED sino contra un producto que lo lleva dentro. El control, en tu caso, son dos cosas que no se descargan: adminAuth puesto y el editor sin salida a internet.
Que un CVE lleve el nombre del fabricante y el fallo esté en el componente que empaqueta no es nuevo, y lo contamos esta misma mañana con GitLab y Ruby, así que aquí no nos extendemos. Lo distinto de este caso es que el componente de dentro se comporta exactamente como está documentado.
Siete de los ocho que atacó no son infraestructura
La prensa ha contado esto como una historia industrial, y se entiende: lo firma Siemens, el producto es una pasarela de planta y CISA lo publicó como aviso de sistemas de control (ICSA-26-237-03). La telemetría del señuelo añade otra capa. La misma IP que lanzó los flujos —4.201.105.116, en una red de Microsoft, geolocalizada en Brasil— golpeó CVE-2026-58115 dieciséis veces entre el 30 de octubre y el 1 de noviembre, y en los últimos días había acumulado 125 impactos contra ocho CVE distintos en el conjunto de los señuelos de VulnCheck.
Los productos que VulnCheck nombra en ese recuento son Apache Solr, Camunda, Gitea, MLflow, Traefik y Joomla, más el propio Node-RED. Son siete nombres para ocho CVE: del octavo no dice el producto, así que lo que sigue vale para siete de ocho y conviene leerlo con esa reserva puesta. De esos siete, ninguno es un sistema operativo ni un concentrador de VPN.
Todos escuchan en HTTP y casi todos los levantó alguien de dentro para pegar una cosa con otra. Dos no encajan del todo y conviene decirlo: Traefik está diseñado precisamente para dar la cara a internet, y un Joomla suele ser una web pública que alguien encargó. Los otros cinco sí se diseñaron dando por hecho que vivirían en una red de confianza, y ninguno de los siete forma parte del parque que mantiene el departamento de sistemas. Son lo que creció al lado.
VulnCheck lee la amplitud de esa lista como la firma de un escaneo masivo oportunista y no de un ataque dirigido, y tiene razón en el cómo. Nosotros añadimos el qué, y lo decimos marcado como lectura nuestra: el escaneo oportunista explica la velocidad, no la selección. Alguien decidió que merecía la pena buscar estas cosas, y lo que el escáner encontró rentable buscar son herramientas internas que nadie firmó. Que una de ellas acabara viviendo dentro de un producto de Siemens es la anécdota; el tema es que la mayoría no vive dentro de ningún producto, sino en una máquina de alguien.
El calendario tampoco hay que leerlo al revés. El aviso de Siemens es del 11 de agosto; el primer ataque recogido por el señuelo, del 30 de octubre. Ochenta días. Lo que pasó en medio no lo ha publicado nadie, así que lo único que se puede afirmar es que esa es la primera explotación observada en público, y que cuando llegó lo hizo de forma automatizada y contra ocho cosas a la vez. Si alguien pensó que su empresa de treinta personas no interesa a nadie, aquí no hace falta interesar. Basta con responder a un escaneo.
Cuándo este 10,0 es un cero para ti
Conviene decirlo aunque no ayude a vender nada: si tu Node-RED tiene adminAuth configurado y su puerto no sale de la red interna, este 10,0 no te toca. Ni corriendo, ni con matices. Un diez de CVSS mide el peor caso, y el peor caso aquí exige que el editor esté alcanzable y abierto; quitas cualquiera de las dos condiciones y el ataque deja de existir. Vale la pena comprobarlo antes de abrir un ticket de urgencia, porque la prisa en un sistema de producción industrial tiene su propio coste.
La pregunta que cuesta más contestar de memoria es cuántos Node-RED hay encendidos en tu casa ahora mismo, y quién los puso. El flujo que alguien montó hace tres años para que el ERP avisara al almacén sigue funcionando, y precisamente porque sigue funcionando nadie ha vuelto a entrar a mirarlo.
El censo que casi nadie tiene escrito
Un inventario normal tiene una fila por servidor y una por licencia. El pegamento no sale ahí: no tiene factura, no tiene contrato de soporte y a menudo no tiene ni nombre de DNS. Estas son las tres columnas que añadimos cuando entramos a mirar esto. Nosotros tenemos un n8n autoalojado para tareas internas y lo tratamos así —inventariado, con dueño y con ventana de actualización—, no por disciplina, sino por haber visto lo que pasa cuando no.
| Columna | Qué se escribe en ella |
|---|---|
| Qué es y dónde escucha | Node-RED, n8n, Jenkins, un Grafana, un script en cron, un contenedor que alguien levantó. Puerto, y si responde desde fuera. Compruébalo desde fuera: la regla del cortafuegos que crees tener y la respuesta que da el puerto no siempre coinciden. |
| Con qué permisos corre | El usuario del proceso y qué credenciales guarda dentro para hacer su trabajo. Una herramienta capaz de ejecutar órdenes pertenece al nivel de privilegio de un administrador, aunque se gestione como una aplicación web más. Si corre como root, averigua quién lo decidió; lo habitual es que no lo decidiera nadie. |
| Quién lo puso y quién lo mira | Un nombre. Si la casilla sale vacía, esa fila es la que hay que mirar primero, antes que cualquier CVSS. La que no tiene dueño es la que nadie va a actualizar. |
Esa tercera columna es la que ordena el trabajo, y explica por qué este tipo de software no aparece en los escaneos: no se compró, así que no está en ninguna lista de activos. Es el mismo mecanismo del que hablábamos en el software que solo usa tu sector, y el mismo que hace que el agente apagó el aviso, no el vigilante cuando se automatiza algo sin decidir antes quién responde de ello.
Automatizar bien consiste en que cada flujo tenga dueño, permisos acotados y un sitio donde se vea lo que hace, que es de lo que va nuestra automatización e IA. Sacar la lista de lo que ya hay encendido, con sus dependencias y sin vender licencias de nada, es trabajo de consultoría. Si quieres que lo miremos contigo, está el formulario de contacto.
El ataque se lee como un tutorial, y esa es la parte que cuesta encajar: no hizo falta entender Node-RED mejor de lo que lo entiende quien montó el flujo de las alertas del almacén. Lo que decidió el resultado fue una línea comentada en un fichero de configuración que nadie había vuelto a abrir, dentro de una máquina que no figuraba en ningún inventario.
Fuentes. Consultadas el 3 de noviembre de 2026. El ataque recogido por el señuelo el 30 de octubre de 2026, la estructura del flujo de tres nodos, la orden del nodo exec, los destinos /dev/shm/.b y /tmp/.kworker, las webshells con nodos http in y function, la IP 4.201.105.116, los dieciséis impactos entre el 30 de octubre y el 1 de noviembre, los 125 impactos contra ocho CVE en el conjunto de sus señuelos y la lista de seis productos (Apache Solr, Camunda, Gitea, MLflow, Traefik y Joomla) son de «Exploitation Targeting Node-RED, a Tool Embedded in ICS Products», de VulnCheck, que es también quien lee esa amplitud como escaneo masivo oportunista y no como ataque dirigido. El identificador CVE-2026-58115, el 10,0 en CVSS 3.1 y 4.0, la frase citada del resumen, el producto afectado —SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2), todas las versiones del Industrial OS anteriores a V4.3.4.1 con Node-RED instalado—, la indicación de actualizar a V4.3.4.1 y las mitigaciones provisionales son del aviso SSA-834709 de Siemens ProductCERT, del 11 de agosto de 2026, recogido por CISA como ICSA-26-237-03. Las dos frases sobre el valor por defecto del editor y la red de confianza, y el ajuste adminAuth, son de la documentación oficial de Node-RED; lo que hace POST /flows y el comportamiento del tipo de despliegue full son de la referencia de su API de administración. El precedente de Pilz es CVE-2025-41656, asignado por CERT@VDE el 1 de julio de 2025 con 10,0 de CVSS. La cronología de la explotación la recoge Help Net Security el 3 de noviembre de 2026. Las citas se dejan en su inglés original para que se puedan buscar literalmente. Los ochenta días entre el aviso y el primer ataque recogido son una resta nuestra sobre esas dos fechas, y no implican que no hubiera actividad antes: implican que esa es la primera observada públicamente. La fotografía de la imagen social es «Control panel displays settings and data for industrial equipment», de Shixart1985, CC BY 2.0 vía Wikimedia Commons.
¿Sabes qué automatizaciones tienes encendidas y quién las puso?
Sacamos el censo contigo: qué pegamento hay montado, desde dónde se puede llegar a él, con qué permisos corre y qué credenciales guarda. Y decidimos fila a fila, sin venderte licencias de nada.
Hablar con everyWAN