RCE en Node-RED de Siemens IoT2050, explotada en el mundo real (CVE-2026-58115)

TL;DR

• Las pasarelas industriales SIMATIC IoT2050 Advanced ejecutan Node-RED sin autenticación en su interfaz HTTP, así que cualquiera que alcance el dispositivo despliega flujos que ejecutan comandos shell. Siemens divulgó la falla el 11 de agosto de 2026 y la califica con CVSS v3.1 y v4.0 10.0.
• Todo SIMATIC IoT2050 Advanced (número de artículo 6ES7647-0BA00-1YA2) por debajo de la versión de imagen V4.3.4.1 está afectado. VulnCheck añade que cualquier instancia de Node-RED sin adminAuth acepta el mismo despliegue de una sola petición.
• La explotación ocurre en el mundo real: los canarios de VulnCheck registraron exploits completos desde el 30 de octubre de 2026. El CVE no figura en el catálogo KEV de CISA al 3 de noviembre de 2026 (fuente verificada); VulnCheck lo añadió a su propio catálogo.
• Actualice cada IoT2050 a V4.3.4.1 o posterior. Para cada despliegue de Node-RED, verifique que la interfaz no sea alcanzable desde fuera y active adminAuth. "¿Cómo lo corrijo?" detalla el endurecimiento.

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• El dispositivo es un SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) con Industrial OS y Node-RED instalado, por debajo de la versión de imagen V4.3.4.1. Siemens no lista ningún otro modelo afectado.
• La interfaz de Node-RED es alcanzable por el atacante. Node-RED escucha en todas las interfaces IPv4 en el puerto 1880 por defecto, según su documentación de configuración.
• No se exige autenticación en esa interfaz. En el IoT2050, Siemens declara que los dispositivos afectados no exigen autenticación en la interfaz HTTP de Node-RED.

El mismo ataque de despliegue funciona contra cualquier instancia de Node-RED sin asegurar, no solo contra dispositivos Siemens. Node-RED está muy desplegado: el paquete node-red registra 92,432 descargas semanales en npm, y su imagen Docker oficial registra 327,470,066 descargas. Ambas cifras se verificaron el 3 de noviembre de 2026.

Verifique qué ejecuta en cada host y en la pasarela:

# Node-RED on any host: which interface and port it listens on
ss -tlnp | grep ':1880 '

# Node-RED on any host: is editor authentication configured?
grep -n "adminAuth" ~/.node-red/settings.js

Una línea adminAuth que queda comentada, empezando por //, significa que el editor y la API Admin aceptan peticiones sin credencial. Desde fuera de su red, intente abrir la URL del editor de cada despliegue, http://<host>:1880.

Un editor que carga sin un aviso de inicio de sesión está expuesto. Para el IoT2050, compare la versión de imagen Industrial OS desplegada con V4.3.4.1; la entrada de actualización es 109741799 en el portal Siemens Industry Online Support.

¿Cómo lo corrijo?

Actualice la pasarela y luego asegure cada otro despliegue de Node-RED:

1. Actualice cada SIMATIC IoT2050 Advanced afectado a V4.3.4.1 o posterior, desde la entrada de soporte 109741799 de Siemens. Siemens ha publicado la imagen corregida y recomienda actualizar.
2. En cada otro despliegue de Node-RED, active la autenticación del editor y de la API Admin descomentando y rellenando la propiedad adminAuth del archivo de configuración, y reinicie Node-RED:

// ~/.node-red/settings.js, adapted from the Node-RED securing guide
adminAuth: {
    type: "credentials",
    users: [ {
        username: "admin",
        password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
        permissions: "*"
    } ]
}

Sustituya el hash de ejemplo, que la guía usa para la contraseña password, por uno generado con node-red admin hash-pw.

1. Active el acceso HTTPS y proteja los HTTP Nodes y el panel Node-RED con autenticación básica o un proveedor OAuth/OpenID. Siemens recomienda estos mismos tres pasos, o desinstalar Node-RED directamente.

Ninguna versión de Node-RED corrige esto por sí sola, así que actualizar el paquete npm no cambia nada. Si no necesita el editor en un host, desactive los puntos de acceso de administración por completo definiendo httpAdminRoot: false en el archivo de configuración.

La recomendación general de Siemens es proteger el acceso de red a los dispositivos con mecanismos adecuados: mantenga el puerto 1880 fuera de redes no confiables después de actualizar.

¿Cuál es la causa raíz?

El editor y la API Admin de Node-RED sirven una interfaz HTTP que ejecuta comandos por diseño, y los dispositivos afectados no exigen autenticación en ella.

Node-RED es una herramienta de programación por flujos construida sobre Node.js: un operador conecta nodos en un editor del navegador, y el servidor ejecuta lo que los flujos describen. Dos tipos de nodos integrados vuelven la interfaz directamente peligrosa.

Un nodo inject dispara un mensaje según una programación o una vez al arrancar, y un nodo exec ejecuta un comando del sistema en el host.

La API Admin expone ese poder por HTTP. Su punto de acceso POST /flows "establece la configuración de flujo activa" y requiere el permiso flows.write, documentado con el encabezado Authorization: Bearer [token] solo "si la autenticación está activada".

La guía de seguridad lo dice sin rodeos: "By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes."

En el IoT2050, el aviso de Siemens describe la consecuencia: los dispositivos afectados no exigen autenticación en la interfaz HTTP de Node-RED. Eso da acceso sin autenticación a nodos de programación que ejecutan comandos del sistema. El registro CVE lo clasifica como CWE-306, Missing Authentication for Critical Function.

Node-RED se distribuye así porque la herramienta asume una red de confianza, como dice su documentación. En una pasarela industrial con una interfaz alcanzable por la red, ese supuesto falla.

¿Cómo se explota?

La prueba de concepto pública es el propio tráfico de exploit, decodificado y publicado por VulnCheck el 2 de noviembre de 2026:

1. El atacante envía una única petición POST /flows a la interfaz de Node-RED. La petición que VulnCheck capturó el 30 de octubre de 2026 venía de curl/8.5.0.
2. El cuerpo lleva un flujo de tres nodos: una pestaña vacía, un nodo inject y un nodo exec. El nodo inject se dispara una vez tras un segundo. Esta es la capa de codificación uno, citada del análisis:

{"flows":[
  {"id":"t","type":"tab"},
  {"id":"inj","type":"inject","z":"t","once":true,"onceDelay":"1","wires":[["e"]]},
  {"id":"e","type":"exec","z":"t","command":"echo <base64> | base64 -d | sh","addpay":false,"wires":[[],[],[]]}
]}

1. La interfaz responde HTTP/1.1 200 OK con un nuevo hash de revisión del flujo, y por eso el evento queda registrado como un exploit exitoso.
2. Un segundo tras el despliegue, el nodo inject se dispara. El nodo exec ejecuta entonces el dropper decodificado. Según la decodificación de VulnCheck, obtiene un binario por wget con curl como alternativa, lo guarda en /dev/shm/.b, lo marca ejecutable y lo ejecuta desacoplado con setsid o nohup.

El binario nunca se recuperó, así que VulnCheck no hace afirmaciones sobre lo que hace. Peticiones posteriores de la misma fuente variaron la carga: un script intermedio wget.sh, guardado y ejecutado como /tmp/.s, un implante guardado como /tmp/.kworker, y flujos que no despliegan ningún descargador.

¿Cómo fluye el ataque?

Una sola petición HTTP a la interfaz sin autenticación despliega un flujo que ejecuta el comando del atacante en un segundo.

¿Qué puede hacer un atacante?

El impacto demostrado es la ejecución de comandos arbitrarios en el host que ejecuta Node-RED.

• Siemens evalúa que un atacante remoto sin autenticación puede crear flujos maliciosos y "ejecutar código arbitrario en el servidor subyacente con privilegios máximos" a través de la interfaz HTTP.
• VulnCheck observó dos formas de post-explotación: bots guardados en /dev/shm respaldado en memoria, y webshells persistentes. Los flujos webshell exponen un punto de acceso HTTP, por ejemplo /cmd, conectado mediante un nodo function a un nodo exec con addpay activado. El atacante pasa comandos en un parámetro de consulta más tarde.
• Las condiciones son mínimas: alcanzabilidad de red de la interfaz, ausencia de adminAuth, y ninguna interacción del usuario. VulnCheck describe el despliegue como una sola petición HTTP.

Ninguna víctima ha sido confirmada. Los eventos de VulnCheck vinieron de una sola IP de origen, 4.201.105[.]116, y las cargas no se recuperaron ni se analizaron, así que no se puede afirmar nada sobre las capacidades del bot.

¿Por qué funciona la corrección?

La actualización V4.3.4.1 es la solución del fabricante, y el aviso confirma que el rango afectado termina por debajo. Siemens distribuye una imagen industrial de código cerrado, así que no hay un diff de parche público para citar.

La corrección de configuración para cada otro despliegue de Node-RED cierra exactamente el hueco que usa el exploit. Definir adminAuth activa la autenticación por credenciales en el editor y la API Admin.

POST /flows exige entonces el encabezado Authorization: Bearer [token] que describe la documentación de la API, y una petición sin autenticar se rechaza. Definir httpAdminRoot: false elimina los puntos de acceso por completo. Los pasos restantes, HTTPS y autenticación básica en los HTTP Nodes y el panel, cierran las demás puertas que un flujo puede abrir.

Estos pasos reducen el problema en lugar de cambiar Node-RED. El nodo exec conserva su poder por diseño; la corrección logra que solo operadores autenticados puedan conectarlo y desplegarlo.

¿Cómo verifico si estuve comprometido?

VulnCheck publicó los indicadores de la explotación observada. Una coincidencia es una pista para investigar, no una prueba de compromiso, y un intento fallido puede no dejar rastro.

# Look for the dropped files on the Node-RED host
ls -la /dev/shm/.b /tmp/.kworker /tmp/.s 2>/dev/null

# Find every exec node and every HTTP endpoint in the deployed flows
grep -nE '"type": ?"exec"' ~/.node-red/flows*.json
grep -nE '"type": ?"http in"' ~/.node-red/flows*.json

Indicadores de red para bloquear y buscar en los registros de conexiones, publicados por VulnCheck:

• 4.201.105[.]116, la fuente del exploit en el ASN AS8075 de Microsoft. Golpeó esta falla 16 veces entre el 30 de octubre y el 1 de noviembre de 2026.
• 85.215.73[.]250 en el puerto 8080, el servidor de carga de bot-linux-amd64 y wget.sh.
• 45.194.90[.]57 en el puerto 38472, el servidor tras el implante .sys_update guardado como /tmp/.kworker.

Revise los propios flujos en busca de nodos que usted no creó: un nodo exec con un comando inesperado, o un punto de acceso http in como /cmd conectado a uno. En los registros de acceso, busque POST /flows de fuentes desconocidas respondidos con HTTP 200 y un hash rev.

La página de análisis de VulnCheck lleva la tabla completa de indicadores y sus artefactos de acceso inicial para la caza.

Cronología

• 2026-08-11: Siemens publica el aviso SSA-834709 con CVE-2026-58115, las puntuaciones CVSS y la versión de imagen corregida V4.3.4.1.
• 2026-08-12: La evaluación CISA ADP del registro CVE anota SSVC Exploitation "none" en esa fecha.
• 2026-10-27: VulnCheck publica artefactos de detección para el CVE, incluidos un PoC de exploit, un escáner de versiones y reglas Suricata, Snort y YARA.
• 2026-10-30: Los canarios de VulnCheck capturan el primer exploit completo, y VulnCheck añade el CVE a su propio catálogo KEV.
• 2026-10-30 al 2026-11-01: La misma IP de origen envía 16 eventos contra la falla; aparecen cargas intermedias y webshell el 1 de noviembre.
• 2026-11-02: VulnCheck publica el análisis de la explotación.

Preguntas frecuentes

¿Está afectado el proyecto Node-RED?

No existe un CVE para Node-RED, y ninguna versión de Node-RED corrige esto. El CVE pertenece al producto de Siemens, que integra la herramienta sin exigir autenticación en su interfaz. La documentación de Node-RED declara que el editor no está asegurado por defecto y solo sirve para redes de confianza.

¿Está la falla en el catálogo KEV de CISA?

No. La fuente JSON del catálogo no tenía ninguna entrada para CVE-2026-58115 al 3 de noviembre de 2026. VulnCheck lo añadió a su propio catálogo KEV el 30 de octubre de 2026, el día en que sus canarios capturaron el primer exploit.

¿Alguien ha sido comprometido?

No se informa ninguna víctima. VulnCheck registró intentos de explotación contra su red de canarios desde una sola IP de origen y no recuperó las cargas. No hace afirmaciones sobre las capacidades del bot.

La evaluación CISA ADP anotó Exploitation "none" el 12 de agosto, antes de las observaciones de octubre.

¿Los ataques apuntan a dispositivos Siemens concretamente?

El canario emula una instancia de Node-RED, así que los ataques observados golpean cualquier Node-RED sin asegurar que encuentran. La IP de origen también golpeó otros siete CVE en productos sin relación, lo que VulnCheck interpreta como escaneo masivo oportunista.

VulnCheck señala que Node-RED se incluye en productos ICS y OT comerciales. También señala que la documentación de Emerson destaca su propio uso de Node-RED, sin validar el impacto.

¿Qué significa "privilegios máximos" aquí?

Siemens declara que el atacante ejecuta código arbitrario "con privilegios máximos" en el servidor subyacente de la pasarela. En un host Node-RED genérico, los comandos se ejecutan con el usuario del proceso Node-RED. El mismo mecanismo de despliegue se aplica.

¿Dónde escucha Node-RED por defecto?

El editor y la API Admin escuchan en todas las interfaces IPv4, 0.0.0.0, en el puerto 1880 por defecto, según la documentación de configuración de Node-RED. En una pasarela con varias interfaces, cada red que une puede alcanzarla salvo que el despliegue cambie uiHost.

Encuentre interfaces industriales expuestas con Ostorlab

El descubrimiento de superficie de ataque de Ostorlab inventaría los hosts expuestos a internet en sus rangos, para encontrar cada dispositivo que responde en la interfaz de Node-RED. Compare cada uno con la versión corregida. Comience un escaneo con Ostorlab para saber qué hosts actualizar primero.

Referencias

• Aviso de seguridad de Siemens SSA-834709, publicado el 11 de agosto de 2026, con los vectores CVSS v3.1 y v4.0 10.0, la lista de productos afectados, la solución V4.3.4.1 y las mitigaciones: https://cert-portal.siemens.com/productcert/html/ssa-834709.html (verificado el 3 de noviembre de 2026)
• Registro CVE-2026-58115, CNA Siemens, publicado el 11 de agosto de 2026, con el bloque SSVC de CISA ADP: https://www.cve.org/CVERecord?id=CVE-2026-58115 (verificado el 3 de noviembre de 2026)
• VulnCheck, "Exploitation Targeting Node-RED, a Tool Embedded in ICS Products", publicado el 2 de noviembre de 2026, con el exploit decodificado, la tabla de indicadores y las cargas de seguimiento: https://www.vulncheck.com/blog/exploitation-targeting-node-red (verificado el 3 de noviembre de 2026)
• The Hacker News, "Attackers Exploit Critical Siemens IoT2050 Flaw to Plant Remote Command Backdoors", publicado el 3 de noviembre de 2026: https://thehackernews.com/2026/11/attackers-exploit-critical-siemens.html (verificado el 3 de noviembre de 2026)
• Guía de seguridad de Node-RED, "Securing Node-RED", la declaración de editor sin asegurar por defecto y los pasos de adminAuth, HTTPS y nodos HTTP: https://nodered.org/docs/user-guide/runtime/securing-node-red (verificado el 3 de noviembre de 2026)
• API Admin HTTP de Node-RED, POST /flows, el encabezado Bearer token "si la autenticación está activada": https://nodered.org/docs/api/admin/methods/post/flows/ (verificado el 3 de noviembre de 2026)
• Documentación de configuración de Node-RED, valores por defecto de uiHost y uiPort y httpAdminRoot: https://nodered.org/docs/user-guide/runtime/configuration (verificado el 3 de noviembre de 2026)
• Página del paquete node-red en npm, descargas semanales: https://www.npmjs.com/package/node-red (verificado el 3 de noviembre de 2026)
• Página de Docker Hub de nodered/node-red, número de descargas de la imagen: https://hub.docker.com/r/nodered/node-red (verificado el 3 de noviembre de 2026)
• Fuente JSON del catálogo KEV de CISA, buscada para CVE-2026-58115 sin coincidencia al 3 de noviembre de 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (verificado el 3 de noviembre de 2026)