Ya se explota el Node-RED sin contraseña que Siemens parcheó en agosto

Un único POST a /flows enviado el 30 de octubre de 2026 desde la dirección 4.201.105.116 bastó para que un señuelo de VulnCheck que imitaba un Node-RED sin autenticación aceptara un flujo con un nodo exec y descargara un bot para Linux. Es la primera explotación observada de CVE-2026-58115, el fallo con CVSS 10,0 que Siemens corrigió el 11 de agosto en sus SIMATIC IoT2050 Advanced y que el 3 de noviembre seguía fuera del catálogo KEV de CISA.

• El fallo es la interfaz HTTP de Node-RED sin autenticación en los SIMATIC IoT2050 Advanced con Industrial OS anterior a V4.3.4.1, y la misma configuración por defecto afecta a cualquier Node-RED sin adminAuth.
• VulnCheck registró 16 intentos desde una sola IP entre el 30 de octubre y el 1 de noviembre, con un bot para Linux, un segundo servidor de payload y webshells persistentes en nodos http in.
• El parche existe desde el 11 de agosto de 2026 y NVD aún no ha analizado el CVE, que tampoco está en el catálogo KEV de CISA.
• Lo urgente es cortar el acceso desde internet al puerto de Node-RED, revisar los flujos desplegados en busca de nodos exec y actualizar a V4.3.4.1.

Tres nodos y un POST a /flows, la cadena que VulnCheck decodificó capa a capa

Patrick Garrity, investigador de VulnCheck según lo presentan The Register y The Hacker News, publicó el 2 de noviembre de 2026 el análisis del incidente a partir de la telemetría de los canarios de la empresa, los servidores señuelo que responden como un producto vulnerable para registrar quién intenta explotarlo. La petición llegó con el user-agent curl/8.5.0 y llevaba en el cuerpo una definición de flujo de Node-RED con tres nodos. Un nodo tab vacío, un nodo inject configurado para dispararse una sola vez un segundo después del despliegue y un nodo exec cableado al anterior. VulnCheck lo resume así: «The attacker's request was a complete exploit» (la petición del atacante era un exploit completo).

El diagrama de VulnCheck recoge las tres capas. La primera es el JSON del flujo. La segunda, el comando del nodo exec, donde wget y curl no aparecen a la vista porque lo único visible es una cadena en base64 que se decodifica y se pasa a sh, de modo que un filtro que busque esas palabras en el cuerpo de la petición no las encuentra. La tercera es el dropper real, que intenta descargar con wget el binario bot-linux-amd64 desde el puerto 8080 de 85.215.73.250, recurre a curl si wget no existe, lo guarda como /dev/shm/.b en un sistema de archivos en memoria, le da permisos de ejecución y lo lanza con setsid, con nohup como alternativa. No hay comprobación de que la descarga haya funcionado ni limpieza posterior.

VulnCheck lo describe con tres palabras, «trivial to weaponize» (trivial de convertir en arma), y lo explica por la combinación de los dos nodos integrados. El nodo inject dispara un mensaje a una hora fija o al arrancar y el nodo exec ejecuta un comando de shell, así que basta cablear uno con otro para que el flujo se ejecute en cuanto se despliega, sin más interacción. El canario respondió como lo haría cualquier Node-RED abierto, con un código 200 y el hash de la nueva revisión del flujo. Esa respuesta es la que convierte el evento en una explotación con éxito y es también lo que conviene buscar en los registros de un proxy inverso o de un firewall de aplicación que tenga delante un Node-RED. Así quedó registrada en el señuelo.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 74

{"rev":"4662660a5924cc8f09736d32ca1b8d8728d8e69805e7d1e8c9efdbdffa3cf0f1"}

Un POST a /flows que devuelve ese 200 desde una dirección externa a la red de control es, por sí solo, un despliegue de código ajeno en el equipo.

CVE-2026-58115 en el aviso SSA-834709 de Siemens y lo que NVD todavía no ha puntuado

Siemens ProductCERT publicó el aviso SSA-834709 el 11 de agosto de 2026 y no lo ha revisado desde entonces, de modo que la versión V1.0 sigue sin ninguna mención a la explotación. El texto es claro sobre el alcance. Los SIMATIC IoT2050 Advanced con Industrial OS y Node-RED instalado no exigen autenticación en la interfaz HTTP de Node-RED, lo que permite a un atacante remoto sin credenciales crear flujos y, en palabras del fabricante, «execute arbitrary code on the underlying server with maximum privileges» (ejecutar código arbitrario en el servidor subyacente con los máximos privilegios). La debilidad está catalogada como CWE-306, falta de autenticación para una función crítica.

La ficha de NVD existe desde el mismo 11 de agosto, pero el 3 de noviembre seguía en estado Awaiting Analysis, con la última modificación del 23 de octubre y sin puntuación propia del NIST. Las dos métricas que muestra, 10,0 en CVSS 4.0 y 10,0 en CVSS 3.1, son las que aporta Siemens como CNA. Tampoco está en el catálogo KEV de CISA, cuya última actualización antes de cerrar esta noticia es del 30 de octubre, y VulnCheck lo hace constar en su informe tras incorporarlo a su propio catálogo de vulnerabilidades explotadas. Entre los avisos que Siemens publica cada mes y que INCIBE-CERT suele recoger en su boletín, no hemos localizado a 3 de noviembre un aviso español específico sobre SSA-834709.

La corrección es la versión V4.3.4.1 de Industrial OS, disponible en el portal de soporte de Siemens con la referencia 109741799. Como mitigaciones, el aviso ofrece dos: desinstalar Node-RED o endurecer la instalación siguiendo la guía de seguridad del proyecto, que es la misma que llevan años recomendando los propios desarrolladores. Siemens no acredita a ningún investigador externo por el hallazgo.

Del bot en /dev/shm a las webshells en /cmd, lo que cambió entre el 30 de octubre y el 1 de noviembre

La misma dirección atacó el señuelo de Node-RED 16 veces entre el 30 de octubre y el 1 de noviembre, y en el conjunto de la red de canarios de VulnCheck acumuló 125 impactos contra ocho CVE distintos en esos días. Entre ellos está CVE-2019-17558, un fallo de Apache Solr de 2019 que CISA incluyó en KEV el 3 de noviembre de 2021, además de productos tan dispares como Camunda, Gitea, MLflow, Traefik y Joomla. Las peticiones contra Node-RED llegaron con al menos cinco user-agents, de curl a python-requests, Python-urllib y cadenas de navegador. Para VulnCheck es la firma de un «opportunistic mass scanning rather than a targeted attack» (escaneo oportunista indiscriminado más que un ataque dirigido) y probablemente de infraestructura compartida o alquilada por más de un operador. La IP pertenece al AS8075 de Microsoft y se geolocaliza en Brasil, lo que dice poco de quién está detrás, porque lo habitual en el rango de un gran proveedor de nube es una máquina virtual comprometida o alquilada. Los indicadores que publica VulnCheck, con el punto entre corchetes tal como los distribuye en las URL de descarga, son los de la tabla siguiente.

La actualización del 1 de noviembre añade tres variantes. Una segunda versión del dropper que descarga el script wget.sh del mismo servidor y lo guarda en /tmp/.s. Un servidor de payload distinto, 45.194.90.57, que sirve en el puerto 38472 un archivo llamado .sys_update que se escribe en /tmp/.kworker, un nombre que imita a los hilos del kernel, y se ejecuta con nohup. Y la que más debería preocupar a quien gestione uno de estos equipos. Varias peticiones prescindieron del descargador y desplegaron un flujo con un nodo http in en una ruta como /cmd, o en una ruta aleatoria, conectado a través de un nodo function con un nodo exec con addpay activado, de modo que el atacante puede ejecutar cualquier comando más tarde pasándolo en un parámetro de la URL. «This backdoor survives even if a memory-backed implant is lost on reboot» (esta puerta trasera sobrevive aunque el implante en memoria se pierda al reiniciar), advierte el informe.

VulnCheck no descargó ni bot-linux-amd64 ni wget.sh ni .sys_update, así que no afirma nada sobre lo que hacen una vez en ejecución, y tampoco vincula esta actividad con ninguna familia conocida. Un flujo desplegado por esta vía queda guardado en el fichero de flujos de Node-RED y sobrevive a los reinicios del servicio, por lo que la revisión de los flujos desplegados forma parte de la respuesta y del análisis forense a partes iguales.

Quién corre Node-RED sin saberlo, de los IoT2050 a FUXA y ocho años de avisos

Node-RED es una herramienta de programación por flujos construida sobre Node.js, con editor en el navegador y, por defecto, escuchando en el puerto 1880. Corre en una Raspberry Pi o en la nube y se ha extendido por fabricación, energía, sanidad y agricultura, en automatización doméstica e industrial. VulnCheck subraya que el CVE lo asignó Siemens porque el software va embebido en un producto comercial de ICS y OT, y añade que la documentación de Emerson también recoge el uso de Node-RED en sus productos, aunque no ha comprobado si están afectados. En el aviso de Siemens no hay ninguna indicación de cuántos IoT2050 Advanced están en servicio ni de cuántos tienen Node-RED instalado.

La documentación oficial del proyecto lo dice desde hace años. Por defecto el editor no está protegido y «anyone who can access its IP address can access the editor and deploy changes» (cualquiera que pueda llegar a su dirección IP puede acceder al editor y desplegar cambios). Quentin Kaiser documentó en septiembre de 2018, durante una auditoría, el mismo flujo para ejecutar comandos en un Node-RED expuesto, con un disparador, un nodo exec y un nodo debug que devuelve la salida. Su captura del editor muestra lo poco que hace falta y lo poco que ha cambiado en ocho años.

Ese mismo mes, la cuenta knolleary del foro del proyecto avisaba de un número creciente de instancias sin proteger en las que alguien desplegaba automáticamente flujos de minería de criptomonedas, recomendaba activar adminAuth como mínimo y, para los equipos ya afectados, reinstalar desde cero. Kaiser contó entonces en Shodan 777 servidores Node-RED expuestos, de los que 227, el 29,2 %, no pedían ninguna autenticación y otros 18 aceptaban las credenciales por defecto.

El patrón se ha repetido después con otros fabricantes. CERT@VDE publicó el 1 de julio de 2025 CVE-2025-41656, también con CVSS 10,0 y el mismo vector, porque la autenticación del servidor Node-RED no venía activada por defecto en los IndustrialPI 4 de Pilz con firmware Bullseye hasta la versión de agosto de 2024, según el aviso VDE-2025-045. Y el 9 de febrero de 2026 se publicó CVE-2026-25938, un salto de autenticación en el software SCADA de código abierto FUXA, versiones 1.2.8 a 1.2.10, que permite ejecutar código sin credenciales cuando el plugin de Node-RED está activo y que se corrigió en la 1.2.11. Quien compre un equipo industrial con Node-RED dentro hereda la configuración que el fabricante haya decidido, y en estos tres casos la decisión fue no exigir contraseña.

Ocho años después de la cuenta de Kaiser no disponemos de un recuento público equivalente. Ni VulnCheck ni Shadowserver ni Censys habían publicado, cuando cerramos esta noticia, cifras de instancias de Node-RED expuestas o de IoT2050 alcanzables desde internet, y las consultas para Shodan, Censys, GreyNoise, FOFA y ZoomEye que VulnCheck preparó el 27 de octubre, junto con reglas Suricata, Snort y YARA, están reservadas a sus clientes. En España no hay cifras de exposición ni aviso específico, pero los SIMATIC están en buena parte de la industria del país y esta pieza encaja en el hilo que el blog sigue desde octubre sobre controladores de OT abiertos a internet, el mismo que explicaba por qué los frigoríficos de siete países seguían accesibles con la fecha del día como contraseña. Lo que un atacante puede hacer desde una pasarela de planta lo repasamos hace tiempo en nuestro análisis de los ciberataques a infraestructuras críticas, y el ejemplo de los supermercados demuestra que no hace falta más que un panel abierto. El reparto que Kaiser publicó en 2018 sigue siendo, de momento, la última foto pública del problema.

Cerrar el puerto 1880 hoy y buscar nodos exec antes de actualizar a V4.3.4.1

El orden que proponemos es el que permite cortar la entrada primero y limpiar después, porque la actualización no elimina un flujo malicioso ya desplegado.

1. Comprueba desde fuera de tu red si algún Node-RED responde, en el puerto 1880 o detrás de cualquier otro, y corta ese acceso en el firewall perimetral antes de seguir. Es la primera recomendación de Garrity, que en su post de LinkedIn recogido por The Register pedía «check today whether it’s reachable from outside your network» (comprobar hoy si es alcanzable desde fuera de tu red).
2. En cada IoT2050 Advanced, actualiza Industrial OS a V4.3.4.1 o posterior desde el portal de soporte de Siemens, y si el equipo no necesita Node-RED, desinstálalo, que es la primera mitigación del aviso.
3. En cualquier otro Node-RED, activa adminAuth en settings.js con contraseñas generadas con node-red admin hash-pw, protege los nodos http in con httpNodeAuth y sirve el editor por HTTPS, como indica la guía del proyecto.
4. Revisa el fichero de flujos y el editor en busca de nodos exec, nodos http in en rutas que no reconozcas y nodos function que no haya creado tu equipo. Un flujo con inject, exec y una cadena en base64 es la firma exacta de este ataque.
5. Busca en el sistema los artefactos del informe, /dev/shm/.b, /tmp/.s y /tmp/.kworker, y procesos lanzados con setsid o nohup desde el usuario de Node-RED. Si aparece alguno, trata el equipo como comprometido, aíslalo y reinstala, que es también lo que aconsejaba el foro del proyecto en 2018.
6. Bloquea y busca en los registros de proxy y firewall las tres direcciones del informe y cualquier POST a /flows que haya devuelto un 200 desde fuera de la red de control.
7. Si confirmas un compromiso, notifícalo a INCIBE-CERT desde una empresa o al CCN-CERT desde una administración pública, y guarda el fichero de flujos y la copia del binario si llegaste a recuperarlo.

Estas comprobaciones cubren los pasos 4 y 5 en un Linux con Node-RED instalado del modo habitual, con el directorio de usuario en ~/.node-red.

# ¿Hay un Node-RED escuchando en todas las interfaces?
ss -ltnp | grep -E ':1880\b'

# Nodos exec, http in y function en los flujos desplegados
grep -oE '"type":"(exec|http in|function)"' ~/.node-red/flows.json | sort | uniq -c

# ¿Está activada la autenticación del editor?
grep -nE '^\s*adminAuth' ~/.node-red/settings.js

# Artefactos descritos por VulnCheck
ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null

Un recuento vacío de nodos exec en la segunda orden no garantiza nada si el atacante ya borró el flujo, pero la ausencia de la línea adminAuth en la tercera es, por sí sola, motivo para sacar el equipo de internet antes de terminar de leer.

Un fallo de configuración con número de CVE y lo que cambia para quien lo despliega

A primera vista, CVE-2026-58115 es un CVE extraño. Node-RED no tiene ningún bug nuevo, el comportamiento que Siemens describe es el de instalación por defecto que el proyecto documenta desde hace años, y la corrección consiste en activar una opción que siempre ha estado ahí. Lo que el identificador hace es trasladar la responsabilidad al fabricante que integró el software en un equipo industrial y lo entregó sin contraseña, y eso es lo que permite que un escáner lo detecte, que un inventario lo liste y que un contrato de mantenimiento lo exija. Sin CVE, el mismo Node-RED abierto en un IoT2050 habría seguido siendo una recomendación de buenas prácticas que nadie audita.

La parte que falta por saber es la que más pesa. VulnCheck lo ha visto desde una sola dirección, contra señuelos y sin recuperar el binario, así que no se puede hablar de una campaña contra la industria ni de un actor concreto, y sería un error leerlo como tal. Lo que sí sabemos es que ese escáner probaba a la vez un fallo de Apache Solr de 2019 y uno de Node-RED de 2026, y que el que acierta cobra en forma de equipo Linux con acceso a una red de control, el tipo de activo que después se revende o se usa para algo más ruidoso, como vimos con la variante de Mirai que probaba exploits de PHP2Shell a los pocos días de publicarse. Los señuelos que atraparon este intento son la misma idea que explicamos hace años en nuestro repaso a los sistemas de decepción, y un canario Node-RED en la red de control es, a día de hoy, la forma más barata de saber si alguien está probando este flujo contra tu planta.

Quien administre pasarelas de OT debería dar por hecho que cualquier software de automatización con editor web que llegue preinstalado viene sin autenticación hasta que compruebe lo contrario, y que el aviso del fabricante llegará, como en este caso, meses antes de que alguien lo explote y sin actualizarse cuando eso ocurra. Las recomendaciones básicas para dispositivos conectados que publicamos en 2018 siguen valiendo palabra por palabra, y la primera de ellas era no exponerlos. Si tu IoT2050 responde desde internet en el puerto 1880, no esperes a la ventana de mantenimiento para cerrarlo.