Node-RED: primeros ataques al fallo CVE-2026-58115 y qué revisar
Por Jorge Graells · 4 de noviembre de 2026 a las 13:50 UTC · 5 min de lectura
Actualizado:
Desde el 30 de octubre hay atacantes buscando instalaciones de Node-RED sin contraseña para ejecutar comandos en ellas. De momento VulnCheck ha visto 16 intentos desde una sola IP y no hay víctimas publicadas, pero revisarlo cuesta poco: basta con cerrar el acceso externo y activar el inicio de sesión.
Node-RED: primeros ataques al fallo CVE-2026-58115 y qué revisar
- Tipo
- News
- Autor
- Jorge Graells
- Fecha
- Actualizado
- Lectura
- 5 min de lectura
- Materias
Resumen
Desde el 30 de octubre hay atacantes buscando instalaciones de Node-RED sin contraseña para ejecutar comandos en ellas. De momento VulnCheck ha visto 16 intentos desde una sola IP y no hay víctimas publicadas, pero revisarlo cuesta poco: basta con cerrar el acceso externo y activar el inicio de sesión.
Desde el 30 de octubre hay atacantes buscando instalaciones de Node-RED sin contraseña para ejecutar comandos en ellas, según VulnCheck1, la empresa que lo detectó en uno de sus servidores trampa. El fallo es el CVE-2026-58115, con la nota máxima de gravedad, 10 sobre 10, según el aviso de Siemens2, porque afecta a sus equipos industriales SIMATIC IoT2050.
Actualizado el 8 de noviembre. Siemens ha ampliado el 4 de noviembre la ficha oficial del CVE3: ya no afecta solo al modelo Advanced, sino también a los IoT2050 Basic, M.2 y SM, siempre con versiones anteriores a la V4.3.4-1 y Node-RED instalado. Node-RED se usa en fabricación, servicios públicos, sanidad o agricultura, y a veces viene ya dentro de productos industriales.
Conviene ponerlo en su sitio: de momento hablamos de 16 intentos desde una sola dirección IP. VulnCheck no menciona víctimas y yo no he encontrado ninguna publicada. Lo cuento porque revisarlo cuesta poco y porque, si tienes un Node-RED abierto, basta una sola petición para perderlo. Actualizaré la noticia si hay datos nuevos.
◢Qué es Node-RED y qué ha pasado
Node-RED es un programa que permite conectar sensores, máquinas y servicios arrastrando bloques en un editor web. Es muy cómodo, y por eso aparece en muchos sitios: una pasarela de planta, una Raspberry Pi que alguien dejó montada para una prueba o un servidor en la nube.
Entre esos bloques hay uno que ejecuta comandos en el sistema y otro que lanza el flujo automáticamente. Según VulnCheck1, el atacante envió una única petición al editor con los dos unidos, y el comando se puso en marcha sin que nadie hiciera nada más. En algunos casos descargaba un programa para Linux llamado "bot" y en otros dejaba una puerta trasera web para poder dar órdenes más tarde.
Siemens publicó el aviso y la versión corregida el 11 de agosto2, y CISA, la agencia de ciberseguridad de Estados Unidos, lo recogió4 el 25 de agosto. Los primeros ataques que ha visto VulnCheck han llegado unos dos meses y medio después.
◢¿Afecta solo a los equipos de Siemens?
El CVE cubre cuatro modelos del SIMATIC IoT2050 (Advanced, Basic, M.2 y SM) con versiones anteriores a la V4.3.4-1 que tengan Node-RED instalado, según la ficha oficial3 que mantiene Siemens. Pero el problema de fondo es más amplio. La documentación oficial de Node-RED5 explica que el editor viene sin proteger por defecto: cualquiera que llegue a su dirección puede entrar y desplegar cambios, algo que solo considera aceptable en una red de confianza.
De ahí la conclusión de VulnCheck1: las instalaciones sin adminAuth, el ajuste que activa el inicio de sesión, se están encontrando y atacando de forma automática. Así que tampoco estás a salvo por no tener nada de Siemens. La misma empresa cita a otro fabricante industrial que usa Node-RED, aunque aclara que no ha comprobado si sus productos están afectados.
◢Lo que se sabe y lo que no
Se sabe que la IP de origen está en la red de Microsoft y se ubica en Brasil, y que atacó este fallo 16 veces entre el 30 de octubre y el 1 de noviembre. En total ha lanzado 125 intentos contra ocho fallos de productos sin relación entre sí. VulnCheck lo interpreta como un escaneo masivo y oportunista, no como un ataque dirigido, según su análisis1. No buscan a tu empresa en concreto, sino a quien tenga la puerta abierta.
No se sabe quién está detrás. VulnCheck avisa de que una dirección en un proveedor de nube no identifica a nadie y de que esa máquina puede estar alquilada o comprometida. Tampoco se sabe qué hace el programa descargado, porque no lo han analizado: podría ser un minero de criptomonedas, un bot para ataques de denegación de servicio o un acceso remoto. VulnCheck tampoco da cifras de cuántos Node-RED hay expuestos. Y a 8 de noviembre el fallo sigue sin aparecer en el catálogo de vulnerabilidades explotadas de CISA6, aunque sí en el de VulnCheck.
◢Qué hacer esta semana
Esto sale de lo que recomiendan Siemens2, CISA4 y VulnCheck1, en el orden en que yo lo haría:
- ▹
Busca dónde tienes Node-RED. Pregunta también a tu integrador o a quien mantenga las máquinas, porque puede venir dentro de una pasarela o de un equipo industrial. Su puerto habitual es el 1880.
- ▹
Comprueba si se puede llegar a él desde fuera de tu red. Si es así, córtalo ya. Los equipos de control no deberían estar en internet: ponlos detrás de un cortafuegos y entra por una VPN actualizada.
- ▹
Activa el inicio de sesión con
adminAuth, siguiendo la guía oficial5. Si no usas Node-RED, desinstálalo. - ▹
Si tienes un SIMATIC IoT2050, sea Advanced, Basic, M.2 o SM, actualízalo a la V4.3.4-1 o posterior.
- ▹
Revisa los flujos desplegados en busca de bloques
execo puntos de entrada HTTP que nadie reconozca. Algunos atacantes dejan ahí su puerta trasera, que sobrevive a un reinicio.
Si tienes a alguien técnico, que busque en los registros las direcciones que publica VulnCheck (4.201.105.116, 85.215.73.250 y 45.194.90.57) y los archivos /dev/shm/.b, /tmp/.s y /tmp/.kworker.
Si encuentras algo, no te limites a borrar el flujo. Yo trataría ese equipo como comprometido: lo aislaría de la red, lo reinstalaría desde una copia limpia y cambiaría todas las contraseñas y claves que tuviera guardadas, porque un programa así suele tener acceso a otros sistemas. En España, la línea de ayuda de INCIBE7, el 017, atiende gratis a empresas.
◢Lo que deja este caso
Es el mismo patrón que en los ataques a las neveras de los supermercados: un equipo que no parece informática, instalado para resolver un problema concreto, que acaba conectado a internet sin que nadie lo tenga en su lista. En una fábrica, además, ese equipo suele estar justo en el punto donde se unen la red de oficina y la de las máquinas.
Los ataques automáticos no distinguen entre una multinacional y un taller. Por eso lo primero que recomiendo a cualquier empresa industrial es tener un inventario de lo que está conectado y saber quién puede entrar desde fuera. Ya conté que los ataques casi nunca entran por el servidor. Si quieres que tu plantilla sepa qué preguntar a sus proveedores, lo trabajo en mis formaciones de ciberseguridad para empresas.
Documentos relacionados
- News
Ciberataque a Crédit Mutuel Arkéa: entraron por un proveedor
El banco francés Crédit Mutuel Arkéa ha sufrido un ataque que permitió transferencias fraudulentas desde su propia cuenta. Los atacantes entraron por la plataforma de un proveedor. Qué se sabe, qué no y qué aprender.
- Artículo
Phishing con código de dispositivo: qué es y cómo evitarlo
El phishing con código de dispositivo engaña a la víctima para que escriba en la página real de Microsoft un código que ha generado el atacante. Así entra en su cuenta de Microsoft 365 sin contraseña y sin que la verificación en dos pasos lo frene. Se evita bloqueando ese inicio de sesión.
- News
Claude Code filtra claves en GitHub: qué es settings.local.json
La opción "no volver a preguntar" de Claude Code puede guardar contraseñas y claves de API en .claude/settings.local.json. Apiiro ha encontrado 1.122 copias públicas en GitHub con secretos dentro. Qué se sabe y qué hacer.