Node-RED Flaw Gets Critical 10/10 Rating as Hackers Exploit It

Hackers have been caught exploiting a critical Node-RED security vulnerability that carries the maximum severity score of 10.0. The attacks involved attempts to install a Linux bot and create hidden ways to run commands on affected devices.

The vulnerability, tracked as CVE-2026-58115, allows an unauthenticated attacker to access a vulnerable Node-RED interface and create malicious workflows capable of executing commands on the underlying system.

Security researchers at VulnCheck detected the exploitation on October 30, 2026. Their investigation also uncovered further attempts involving different payloads and webshells that could allow attackers to maintain access.

However, the affected-product scope is important. Siemens identifies the vulnerability in SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed, on versions earlier than V4.3.4.1. This does not mean every device or installation running Node-RED is affected by this specific CVE.

What researchers still don’t know

Despite identifying the attack commands and payload servers, researchers have not established what the downloaded malware actually does.

VulnCheck did not retrieve or analyse the bot-linux-amd64 binary or the additional scripts. Its filename suggests a Linux payload designed for AMD64 systems, but there is no confirmed evidence that it was a cryptocurrency miner, DDoS bot or remote-access tool.

The identity of the attackers also remains unknown. The source IP belonged to Microsoft’s cloud network and geolocated to Brazil, but this does not establish the operator’s location or identity.

VulnCheck confirmed that its canary received and accepted malicious workflows, but its report did not identify a real-world organisation whose device was successfully infected. The findings therefore establish exploitation attempts and malicious workflow deployment in a monitored environment, not confirmed infections of named victims.

Why is the Node-RED vulnerability rated 10/10?

Siemens published its security advisory, SSA-834709, on August 11, 2026. It assigned CVE-2026-58115 a CVSS score of 10.0 under both CVSS 3.1 and CVSS 4.0, the highest possible severity rating.

The problem is a missing authentication check on the Node-RED HTTP interface. This means an attacker who can reach the vulnerable interface does not need valid login credentials to create malicious workflows.

The risk is particularly serious because those workflows can use programming components that execute commands on the device itself. Siemens warns that an attacker could run arbitrary code on the underlying system with maximum privileges.

The scoring reflects several serious conditions: the attack can be carried out over a network, requires low effort, needs no existing privileges and does not depend on a user clicking or approving anything. The potential impact includes the confidentiality, integrity and availability of the affected system.

How does the attack work?

Node-RED is a flow-based programming tool that allows users to connect devices, applications and services through visual workflows. It is used in different environments, including industrial automation and Internet of Things systems.

VulnCheck’s investigation shows how attackers can abuse two of its built-in components.

An Inject node can automatically start a workflow, while an Exec node can run a command on the underlying operating system. By connecting the two, an attacker can make a system command run automatically when the malicious workflow is deployed.

In the observed attack, the attacker sent a request to Node-RED’s /flows interface to add a workflow containing these components. The workflow was configured to start after a short delay and pass a command to the Exec node.

The request also contained three layers of encoding. The final command was hidden inside a Base64-encoded string, which was decoded before being passed to the system shell. This made the actual download commands less obvious when looking at the original request.

VulnCheck’s canary returned an HTTP 200 response and a new workflow revision hash. This showed that the test system had accepted the malicious workflow, and the researchers classified the event as a successful exploit.

What malware were the attackers trying to install?

After deploying the workflow, the attacker attempted to download a Linux binary named bot-linux-amd64 from a separate server.

The command first used wget to retrieve the file. If that failed, it tried curl as an alternative. It then attempted to make the downloaded file executable and start it in the background.

The file was saved as /dev/shm/.b. This location is important because /dev/shm is a memory-backed temporary filesystem. The hidden filename also makes the file less noticeable during a basic directory listing.

The researchers explained that this approach can avoid leaving the downloaded file on ordinary disk storage. However, a file stored there normally disappears after a reboot unless the attacker establishes persistence through another method.

VulnCheck did not retrieve or analyse the bot-linux-amd64 binary. Its actual purpose is therefore unknown. The researchers could not establish whether it was designed for cryptocurrency mining, distributed denial-of-service attacks, remote access or another activity.

It would be inaccurate to describe it as confirmed ransomware, a DDoS bot or any other specific type of malware.

Attackers also tried other payloads and webshells

The investigation did not stop with the first Linux bot attempt.

In an update covering activity observed through November 1, VulnCheck described additional requests from the same source IP.

One variation attempted to download a shell script named wget.sh and run it. Instead of downloading the bot directly, this method first retrieved the script and then executed it.

Another request used a different server to download a file named .sys_update, saving it as /tmp/.kworker before attempting to run it. The filename resembles the naming convention used for Linux kernel worker processes, although that name alone does not establish what the file does.

More concerning were attempts to create webshells.

Rather than downloading a separate binary, these malicious workflows created an HTTP endpoint connected to a Function node and an Exec node. This could allow an attacker to send a later web request containing a command for the device to execute.

That creates a different kind of risk. The first payload was placed in temporary memory-backed storage and could disappear after a reboot. A webshell stored as part of the Node-RED workflow could remain in the configuration and continue providing a route for remote commands after the device restarts.

VulnCheck did not retrieve or analyse the additional shell script or the .sys_update payload either. Their exact capabilities remain unknown.

How widespread were the exploitation attempts?

VulnCheck recorded 16 events targeting CVE-2026-58115 from the same source IP between October 30 and November 1.

The researchers also found that the address had generated 125 hits involving eight different vulnerabilities across their wider monitoring network. The other products included Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla.

The activity involved several different payloads and at least five user-agent strings. VulnCheck said the range of products and vulnerabilities suggested opportunistic mass scanning rather than an attack aimed at one particular organisation.

The source IP was part of Microsoft’s AS8075 network and geolocated to Brazil. However, that does not identify the attacker or prove that Microsoft was involved. VulnCheck noted that infrastructure in a major cloud provider’s network may be rented or compromised and used by someone else.

The researchers also identified separate servers used to host the downloaded payloads. They did not directly observe those servers through their canary monitoring, so the available evidence does not establish who operated them.

These findings show that attackers attempted to exploit the flaw, but they do not establish how many real organisations were compromised or whether the downloaded malware successfully ran on victims’ devices.

Which Siemens devices are affected?

According to Siemens’ original security advisory, the affected product is:

• Product: SIMATIC IoT2050 Advanced
• Order number: 6ES7647-0BA00-1YA2
• Operating system: Industrial OS
• Required configuration: Node-RED installed
• Affected versions: Earlier than V4.3.4.1
• Fixed version: V4.3.4.1 or later

The distinction is important for organisations checking their equipment. The Siemens advisory does not list every Node-RED installation or every Siemens device as affected by CVE-2026-58115.

Node-RED’s own security documentation also warns that its editor is not secured by default. Anyone who can access an unsecured editor may be able to deploy changes. This is a broader configuration concern, not proof that every such installation falls within the Siemens CVE.

How can organisations protect their devices?

Siemens recommends updating affected SIMATIC IoT2050 Advanced devices to V4.3.4.1 or a later version.

If updating is not possible, Siemens advises customers to uninstall Node-RED or harden the installation using the official Node-RED security guidance.

That guidance explains how to enable authentication for the editor and Admin API through the adminAuth setting in the settings.js file. It also covers HTTPS and protection for HTTP endpoints exposed by Node-RED workflows.

Organisations should also take these steps:

• Check network access: Do not expose the Node-RED editor or Admin API to untrusted networks or the public internet.
• Enable authentication: Confirm that adminAuth is properly configured and that only authorised users can deploy or change workflows.
• Review existing workflows: Look for unfamiliar Exec nodes, unexpected HTTP endpoints and workflows that were not created by authorised staff.
• Investigate suspicious activity: Check system and network logs for unexpected downloads, shell commands or connections to unfamiliar servers.
• Respond carefully to suspected compromise: Restrict access and investigate the device before restoring normal operation. In industrial environments, coordinate isolation with operational teams to avoid disrupting essential processes.

The central concern is not just the maximum severity score. Researchers have observed attackers using the missing authentication to deploy malicious workflows, attempt Linux payload delivery and create possible command-execution backdoors.

Organisations using the affected Siemens configuration should check their software version and secure their Node-RED interfaces rather than assume that an internet-facing editor is safe.

How we checked this

We reviewed Siemens’ original security advisory, VulnCheck’s independent analysis of observed exploitation attempts, CISA’s industrial control systems advisory and Node-RED’s official security documentation. We distinguish successful workflow deployment in a test environment from malware execution that has not been confirmed on a real victim’s device.

Siemens advisory VulnCheck research CISA advisory Node-RED security guidance