Explotación activa de CVE-2026-58115 en Siemens IoT2050 permite puertas traseras de ejecución remota

VulnCheck ha verificado que actores maliciosos están explotando de forma activa una falla de máxima gravedad que compromete los equipos SIMATIC IoT2050 Advanced de Siemens. El defecto, catalogado como CVE-2026-58115 y con una calificación CVSS de 10.0, radica en la ausencia de autenticación en una función crítica, lo que permite a un atacante remoto no autenticado ejecutar código arbitrario.

De acuerdo con el boletín emitido por Siemens en agosto de 2026, los dispositivos SIMATIC IoT2050 Advanced que corren Industrial OS con Node-RED instalado presentan una falta de autenticación en la interfaz HTTP de Node-RED. Esta condición faculta a un atacante remoto sin credenciales para crear flujos maliciosos y ejecutar código arbitrario en el servidor subyacente con los privilegios más elevados.

La empresa solventó la vulnerabilidad en la versión 4.3.4.1 y posteriores. Como paliativos, Siemens aconseja desinstalar Node-RED o reforzar su despliegue mediante varias acciones.

  • Habilitar el acceso a través de HTTPS.
  • Proteger el editor y la API de administración con autenticación basada en credenciales o mediante un proveedor OAuth/OpenID.
  • Resguardar los nodos HTTP y el panel de Node-RED con autenticación básica.

El 30 de octubre de 2026, VulnCheck reportó la detección de intentos de atacantes por explotar CVE-2026-58115 contra su red de honeypots, con la finalidad de descargar y ejecutar un bot de Linux. El investigador de la firma Patrick Garrity calificó la petición observada como un exploit completo: desplegaba un flujo de Node-RED, lo activaba automáticamente y descargaba un binario desde un servidor bajo control del atacante, todo ello encubierto con tres capas de codificación.

En concreto, el flujo malicioso ejecuta un envoltorio de script de shell que utiliza wget para obtener el binario del botnet para arquitectura AMD64 desde la dirección 85.215.73[.]250. Si wget falla, se recurre a curl como alternativa. En la fase final, el binario se almacena como "/dev/shm/.b" y se ejecuta.

Más adelante, los responsables de la campaña evolucionaron hacia un proceso en dos etapas en el que wget descarga otro script de shell denominado "wget.sh" desde el mismo servidor. También se ha identificado otra petición que lanza wget o curl contra 45.194.90[.]57:38472 para obtener un payload llamado ".sys_update", guardarlo en disco como "/tmp/.kworker" —con la intención de camuflarlo como un inofensivo hilo de trabajo del kernel— y ejecutarlo. La funcionalidad exacta de "wget.sh" y ".kworker" sigue siendo desconocida, ya que no pudieron recuperarse.

Varias peticiones no desplegaron ningún descargador. En su lugar, el flujo expone un endpoint HTTP de entrada (por ejemplo /cmd o una ruta con nombre aleatorio) conectado mediante un nodo de función a un nodo exec con addpay habilitado, de modo que el atacante podía ejecutar comandos arbitrarios después pasándolos como parámetro de consulta. Esta puerta trasera sobrevive incluso si se pierde un implante alojado en memoria tras un reinicio.

Cybersecurity
Cybersecurity

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *