After Supermarket Freezers, Factories Next? Attackers Hijack Unsecured Node-RED Systems

First, unknown attackers remotely defrosted supermarket freezers across Europe; now attackers are hijacking Node-RED, a widely used tool that factories, utilities and hobbyists rely on to control devices. No link between the two has been established, but the pattern is the same: control interfaces exposed to the internet without protection. With Node-RED, a single request is enough to take over a device.

On the night of October 11, temperatures in the refrigerated shelves of hundreds of French supermarkets were set to around 50 degrees Celsius (122 degrees Fahrenheit). Unknown attackers had remotely switched the refrigeration controllers into defrost mode. France’s Minister of the Economy and Finance, Roland Lescure, put the number of affected stores at around 700 out of 10,000. In early November, a second wave followed in other European countries, including Germany. In the freezer attacks, the targets were specialized controllers.

Node-RED, by contrast, is a general-purpose tool. The freely available software connects devices and services with a few mouse clicks. On a web page called the editor, users drag small boxes onto a canvas and wire them into a sequence: if a sensor reports 30 degrees Celsius, a fan switches on. Factories use it to collect machine data, and hobbyists use it to run their smart homes. One of these boxes executes arbitrary commands on the device. That is intentional, because Node-RED is meant to control devices. It becomes dangerous when the editor can be reached from the internet without a password. Then any stranger can add such boxes and take over the device. That is exactly what has been happening since late October.

What happened?

On October 27, the security company VulnCheck provided its customers with detection rules for CVE-2026-58115. Three days later, one of its decoy systems was triggered. Such honeypots are deliberately exposed traps that researchers use to observe attacks. According to VulnCheck, the attacker sent a single request to the /flows endpoint, which Node-RED uses to accept new workflows. The request contained a ready-made workflow, which Node-RED calls a flow.

It consisted of two building blocks: an inject node, which triggers a flow on a schedule or at startup, and an exec node, which runs commands on the operating system. The intercepted flow was designed to download a program called bot-linux-amd64 from an external server, store it in memory and launch it. In other cases, the attackers created a flow that sets up a web shell. This hidden backdoor accepts further commands later and even survives a reboot.

By November 1, VulnCheck had counted 16 such attacks, all from the same IP address on Microsoft’s network. The company considers them mass scanning of the internet rather than a targeted attack. VulnCheck did not examine what the program actually does. The timeline is revealing. Siemens had already disclosed the vulnerability on August 11 and released an update. The following day, the US Cybersecurity and Infrastructure Security Agency (CISA) rated it as automatable but had not yet seen any attacks. The attacks came 80 days after the update. VulnCheck now lists the vulnerability in its catalog of actively exploited vulnerabilities.

Which devices are affected?

Officially, the vulnerability affects Siemens industrial gateways. The SIMATIC IoT2050 is a small industrial computer for control cabinets. It collects data from machines and controllers and forwards it to IT systems or a cloud. It runs Industrial OS, a Linux-based operating system from Siemens. According to security advisory SSA-834709, affected devices do not enforce authentication on the Node-RED interface. Without a password, an attacker can create their own flows and execute code with the highest privileges. Siemens rates this at 10.0, the maximum on the CVSS scale the industry uses to measure the severity of vulnerabilities. In August, Siemens listed only the IoT2050 Advanced.

On November 4, the company clarified the list. It now names four variants: Advanced, Basic, M.2 and SM, each running Industrial OS before version V4.3.4-1 with Node-RED installed. Many reports still mention only the Advanced. Siemens recommends the update. Alternatively, operators should uninstall or secure Node-RED and restrict network access. The attackers, however, don’t care about the brand. They look for any Node-RED installation that lacks authentication. Whether the device comes from Siemens, is a Raspberry Pi in someone’s basement or a server in the cloud makes no difference to the attack.

Why is this not a flaw in Node-RED’s code?

Node-RED does what its documentation says. In essence, the documentation states that without further configuration the editor is not secured, and anyone who can reach its IP address can change flows. This, it says, is only acceptable on a trusted network. For more protection, users enable the adminAuth setting, which requires a username and password. The security guide explains this step by step. Network access adds to the problem. According to the configuration documentation, the editor accepts connections on port 1880 across all of the device’s network interfaces by default. Without further configuration, it is therefore reachable from every network the device is connected to, unless a firewall sits in between.

The exec node isn’t a flaw either. It is meant to run commands; that is its purpose. Siemens accordingly classifies the CVE as CWE-306, missing authentication for a critical function. So the problem lies not in the program but in the state it runs in. Siemens is not the first vendor with this problem. In July 2025, CERT@VDE, a German coordination center for industrial security vulnerabilities, reported CVE-2025-41656 in the IndustrialPI 4 industrial PC from Pilz, also rated 10. According to CERT@VDE, authentication for Node-RED was not configured by default on that device. The case of the visualization software FUXA is different. There, authentication on the Node-RED integration could be bypassed even when it was enabled. That was a genuine programming error, which the developers fixed in February 2026 with version 1.2.11.

Who is responsible: the project or the vendors?

The Node-RED project wanted to do away with the open default. In a design proposal dated October 21, 2022, maintainer Nick O’Leary announced that from version 4.0 onward Node-RED would refuse to start unless adminAuth was set. Anyone who wanted to run without protection would have had to say so explicitly. Warnings were planned for versions 2 and 3. Version 4.0 was released on June 20, 2024. The release blog post mentions neither adminAuth nor a startup block. The documentation still describes the editor as unsecured by default. The announcement of versions 5.0.9 and 4.1.17 on October 22, 2026, does not mention any change in this respect either. The project does ship security fixes, though.

According to the announcement in the Node-RED forum, both versions close an important vulnerability in the Projects feature. We found no public statement from the project on CVE-2026-58115. At least two vendors have adopted the open default. At Pilz, authentication was not configured by default; at Siemens, affected devices did not enforce authentication, according to the advisory. On top of that, operators connect such devices directly to the internet. Each of these three levels can close the door. As long as each relies on the others, it stays open.

How many Node-RED editors are exposed online?

To get a rough estimate, WeSpeakIoT analyzed data from the search engine Shodan. Shodan does not index web pages but devices: the service continuously queries addresses on the internet and records what responds. Beginning of November, a search for pages titled “Node-RED” initially returned 19,062 hits. This number alone is misleading. Shodan counts services, meaning every combination of address and port separately, not devices. Our samples show how much this matters. In Cyprus, all 20 entries we checked came from the same address, and every queried port appeared exactly once. The 1,155 hits there apparently come from a single system.

In Israel, our samples indicate that around 4,200 hits stem from four systems. Together with what is probably a single server in Frankfurt, these systems account for 31 percent of all hits. Another cluster in Finland with 1,095 hits probably follows the same pattern. Whether these are researchers’ decoy systems or real devices behind a router that forwards all ports cannot be determined from the outside. Nor does Shodan show whether a reachable editor requires a password. The only reliable takeaway is an order of magnitude: we estimate that several thousand Node-RED editors are reachable. How many of them are unsecured cannot be determined from the outside without actually trying.

In Germany, Shodan counted 992 hits. Of these, 539 probably come from a single server of a cloud provider in Frankfurt. Of the rest, around 390 are hosted by cloud and hosting providers such as AWS, Hetzner or Contabo, and only 54 sit in the networks of internet service providers serving residential and business customers. However, Shodan covers IPv6 addresses only partially, so home networks are likely underrepresented.

What should operators do now?

For refrigeration systems, authorities have already spelled out what to do. Starting October 12, France’s government computer emergency response team, CERT-FR, reported numerous compromises of controllers made by Danfoss, Copeland and Dixell. It advises making such devices no longer publicly reachable and allowing access only via a VPN or a protected network. Operators should also update firmware and, for Danfoss devices, check that default passwords have been changed.

According to Danfoss, mainly older products that no longer receive updates were affected. Germany’s Federal Office for Information Security (BSI) casts the net wider. Its warning of October 13 is aimed at operators of small industrial facilities, such as those used for food refrigeration or power generation. Direct access from the internet should be blocked, and remote access should be protected by a VPN and multiple authentication factors. “The incidents in France clearly show how cyberattacks can affect and disrupt our everyday lives,” said BSI President Claudia Plattner. The same rules apply to Node-RED. In concrete terms:

1. If you run a Siemens IoT2050 with Industrial OS and Node-RED, install the update to V4.3.4-1 or uninstall Node-RED.
2. Check whether the editor is reachable from the outside. By default, it accepts connections on port 1880. If you only need it on the device itself, set uiHost to 127.0.0.1.
3. Enable adminAuth in the settings.js configuration file. The node-red admin hash-pw command generates the required password hash.
4. Do not allow direct access from the internet. Use remote maintenance only via a VPN with a second factor.
5. Check existing flows for unknown exec and HTTP-in nodes.
6. If you find flows you did not create, rebuild the device from scratch. Cleaning up is not enough, because attackers may have left further backdoors.

Conclusion

In this case, no programming error in Node-RED opens the door. The door is open because the project ships the software without authentication, vendors adopt this default and operators connect devices to the internet. So far, the known attacks hit decoy systems and were meant to load a bot. Nothing so far shows that factories are now being hit after the freezers. But the freezer attacks show what happens when someone uses such access for sabotage. Siemens’ update has been available since August, and the instructions for enabling authentication for years. What is missing is a default that doesn’t leave closing the door to chance.

Is Node-RED insecure?

In the case of CVE-2026-58115, Node-RED’s program code contains no flaw. The insecure part is the default state: the editor starts without authentication, and anyone who can reach it can run commands on the device via the exec node. With authentication enabled via adminAuth and no direct internet access, Node-RED can be operated much more securely.

What is CVE-2026-58115?

CVE-2026-58115 is a vulnerability reported by Siemens in SIMATIC IoT2050 industrial gateways, rated the maximum score of 10.0. Affected devices do not enforce authentication on the Node-RED interface, allowing attackers to execute code with the highest privileges without a password. According to VulnCheck, the vulnerability has been actively exploited since October 30, 2026.

Which Siemens devices are affected?

The Advanced, Basic, M.2 and SM variants of the SIMATIC IoT2050 are affected if they run Industrial OS before version V4.3.4-1 with Node-RED installed. Siemens clarified the list on November 4, 2026; previously, only one model was named. The fix is to install the update or uninstall Node-RED.

How do I protect Node-RED with a password?

Enable the adminAuth section in the settings.js configuration file and add a user. The node-red admin hash-pw command generates the required password hash. After a restart, the editor requires users to log in.

How can I tell whether my Node-RED has been compromised?

Warning signs include flows that nobody deliberately created, especially with exec nodes that run commands or HTTP-in nodes that open new web endpoints. Unknown processes or files in temporary directories can also indicate an attack. Affected devices should be rebuilt from scratch.

Should Node-RED be directly accessible from the internet?

The Node-RED documentation considers an unsecured editor acceptable only on trusted networks. Anyone who needs remote access should enable authentication, use HTTPS and route access through a VPN. Germany’s Federal Office for Information Security (BSI) generally recommends blocking direct internet access to control systems.