Node-RED se instaló para que un operario pudiera conectar una máquina con una hoja de cálculo sin escribir una línea de código, y esa misma facilidad es la que ahora lo convierte en una puerta abierta. La interfaz HTTP de la herramienta no exige autenticación por defecto, así que cualquiera que llegue a ella puede crear un flujo nuevo y ejecutar código con los permisos del proceso. No hace falta una contraseña, ni una sesión, ni un fallo de memoria que explotar.
El problema está registrado como CVE-2026-58115 y Siemens, que distribuye la herramienta dentro de su sistema industrial, lo puntúa 10.0, la nota máxima. VulnCheck observó el primer exploit completo el 30 de octubre y lo incluyó en su catálogo de vulnerabilidades explotadas, según el repaso de parches que publicó el boletín Patchwork de heise el 4 de noviembre. CISA no lo había añadido a su lista cuando se publicó ese parte.
La explotación observada no es un experimento de laboratorio. Los atacantes despliegan un bot para Linux y webshells, que es lo que se instala cuando el objetivo no es robar datos sino quedarse dentro. El fallo afecta a instalaciones de Node-RED de cualquier sector, y de forma más incómoda a los equipos industriales que lo traen de fábrica y que nadie actualiza porque nadie sabe que llevan Node-RED dentro.
Un ataque de 10.0, una pesadilla de seguridad
En la práctica, el editor Node-RED es una aplicación web completa con acceso al sistema operativo detrás, y la única barrera entre ambos es una pantalla de login que hay que activar a mano.
La vulnerabilidad es una falta de autenticación en la interfaz HTTP. El editor de flujos está pensado para abrirse en un navegador y arrastrar bloques, y en esa configuración por defecto no pide credenciales a quien entra. Un atacante con acceso de red puede abrir el editor, crear un flujo con un nodo que ejecute comandos del sistema y esperar a que el flujo se dispare.
La nota 10.0 no exagera. Una puntuación así se reserva para fallos que se explotan de forma remota, sin autenticación, sin interacción del usuario y con impacto total en confidencialidad, integridad y disponibilidad. Aquí se cumplen las cuatro: no hay credenciales que robar, no hay víctima que tenga que hacer clic y el código resultante corre con los permisos de quien arrancó el servicio.
La comparación con otros fallos de este mes ayuda a situarlo. Los dos 9.8 de LangFlow en sus agentes de IA exigían una configuración concreta; este no exige nada más que la instalación por defecto.
Bot Linux y webshells en instalaciones sin login
Lo que se ha visto instalar es un bot para Linux y webshells, dos piezas que suelen ir juntas. El bot convierte la máquina en parte de una red de mando y control y le da al atacante una puerta que sobrevive a reinicios; la webshell le da acceso cómodo por HTTP sin abrir puertos nuevos, algo valioso en redes donde solo el 80 y el 443 salen al exterior.
Una webshell en un servidor que además tiene Node-RED es especialmente molesta porque el servicio legítimo ya corre con permisos amplios. El atacante no necesita escalar privilegios: hereda los que el proceso tenía para hablar con los dispositivos conectados, que en un entorno industrial incluyen PLC, sensores y pasarelas de protocolo.
El detalle que separa este incidente de un compromiso web cualquiera es el contexto. Un Node-RED comprometido en una oficina es un servidor más; un Node-RED comprometido en una planta, es una vía de escritura hacia el proceso físico, y eso cambia el orden de prioridades de cualquier respuesta.
Un ataque capaz de tocar el PLC
Siemens advirtió en agosto de que los equipos con Industrial OS anterior a la versión 4.3.4.1 llevaban Node-RED dentro, entre ellos el SIMATIC IoT2050 Advanced, una pasarela industrial que se usa para llevar datos de planta a sistemas de gestión. La versión 4.3.4.1 o posterior corrige el fallo en ese entorno, y el aviso de la compañía es el único que ofrece un número de versión claro para el parque industrial.
Fuera de Siemens la cosa se complica, porque Node-RED se instala a mano en cualquier sitio: una Raspberry Pi en un armario, un contenedor en la nube, un servidor de integración que alguien montó para conectar la máquina de etiquetado con el ERP. Ninguno de esos casos tiene un fabricante que publique un boletín, y todos comparten la misma configuración por defecto.
La recomendación oficial para esas instalaciones es concreta y se puede aplicar hoy: activar `adminAuth`, que obliga a autenticarse antes de abrir el editor, y no exponer el servicio directamente a internet. Ninguna de las dos cosas tapa la vulnerabilidad, pero las dos eliminan la vía de entrada que se está usando.
Tres medidas que sirven hoy sin parchear
La primera es la autenticación del editor. `adminAuth` se configura en el fichero de ajustes y admite usuarios con contraseña o con tokens, y a partir de ese momento la interfaz deja de ser anónima. Es la medida con más impacto y la más barata: un cambio de configuración y un reinicio del servicio.
La segunda es cerrar el camino de red. Si Node-RED solo tiene que hablar con cuatro dispositivos, no necesita estar accesible desde toda la red corporativa. Un cortafuegos delante del puerto del editor, o una regla de segmentación, reduce el número de personas y de máquinas que pueden intentarlo sin tocar el software.
La tercera es revisar si el editor está publicado sin querer. Los escaneos de internet encuentran instancias de Node-RED con el editor abierto con una facilidad que sorprende, y muchas veces son pruebas de hace dos años que nadie apagó. Buscar las propias antes de que las encuentre otro es una tarde bien empleada.
Cómo detectar una instalación ya comprometida
Un compromiso de este tipo deja rastro en tres capas distintas y conviene revisarlas en orden, porque cada una explica lo que la anterior no puede: primero la aplicación, después el sistema y al final la red.
La señal más directa son los flujos que nadie escribió. El editor guarda los flujos en un fichero de configuración y en su almacenamiento interno, y cualquier flujo con un nodo de ejecución de comandos que no corresponda a un proceso documentado merece una explicación. En una instalación con decenas de flujos, la comparación con la copia de seguridad de la semana anterior resuelve la duda en minutos.
Después hay que mirar el sistema, no la aplicación. Un proceso que arranca desde una ruta temporal, una tarea programada nueva, una clave SSH añadida a un usuario de servicio o una conexión saliente periódica hacia una dirección desconocida son las huellas del bot. El caso de PwnEscape, el fallo que deja a un invitado atacar el anfitrión, dejó el mismo rastro en los equipos afectados.
El tercer sitio es el registro del propio Node-RED. Los flujos nuevos dejan entradas de despliegue con fecha y usuario, y en una instalación sin autenticación ese usuario aparece vacío. Un despliegue sin autor a las tres de la mañana es exactamente lo que hay que buscar.
El nuevo borde entre OT e IT
La herramienta que nació para que un operario no dependiera del departamento de sistemas ha terminado siendo el punto donde ese departamento pierde el control. Node-RED es útil precisamente porque cualquiera puede montar una integración en una tarde, y esa autonomía es la que deja instalaciones fuera del inventario, sin parchear y sin dueño identificable.
El arnés de IA que ayudó a reventar 200 organizaciones mostró la otra cara del mismo problema: cuando el software de integración no tiene dueño, tampoco tiene quien lo defienda. La lista de activos de cualquier planta debería incluir ya las herramientas de pegamento, no solo los equipos que producen.
Mientras eso pasa, la tarea de esta semana cabe en tres líneas. Localizar las instancias de Node-RED de la organización, activar `adminAuth` en todas y comprobar si alguna tiene flujos que nadie reconoce. Lo demás, incluido el debate sobre quién debería haber avisado antes, puede esperar al lunes.
