Node-RED: first attacks on CVE-2026-58115 and what to check
By Jorge Graells · November 4, 2026 at 1:50 PM UTC · 5 min read
Updated:
Since October 30, attackers have been looking for Node-RED installations with no password so they can run commands on them. VulnCheck has seen 16 attempts from one IP so far and no victims have been reported, but checking is cheap: close outside access and turn on login.
Node-RED: first attacks on CVE-2026-58115 and what to check
- Type
- News
- Author
- Jorge Graells
- Date
- Updated
- Reading time
- 5 min read
- Subjects
Summary
Since October 30, attackers have been looking for Node-RED installations with no password so they can run commands on them. VulnCheck has seen 16 attempts from one IP so far and no victims have been reported, but checking is cheap: close outside access and turn on login.
Since October 30, attackers have been looking for Node-RED installations with no password so they can run commands on them, according to VulnCheck1, the company that spotted it on one of its decoy servers. The flaw is CVE-2026-58115, rated 10 out of 10 for severity in Siemens' advisory2, because it affects its SIMATIC IoT2050 industrial devices.
Updated November 8. On November 4 Siemens widened the official CVE record3: it no longer covers only the Advanced model but also the IoT2050 Basic, M.2 and SM, in every case on versions before V4.3.4-1 with Node-RED installed. Node-RED is used in manufacturing, utilities, healthcare and agriculture, and it sometimes ships inside industrial products.
Some perspective first: so far we're talking about 16 attempts from a single IP address. VulnCheck doesn't mention any victims and I haven't found any reported. I'm covering it because checking takes little effort and because, if you have an open Node-RED, one request is enough to lose it. I'll update this story if new information comes out.
◢What Node-RED is and what happened
Node-RED is a tool for connecting sensors, machines and services by dragging blocks around a web editor. It's very convenient, which is why it turns up in so many places: a plant gateway, a Raspberry Pi someone set up for a test, a cloud server.
Among those blocks is one that runs system commands and another that starts a flow automatically. According to VulnCheck1, the attacker sent a single request to the editor with the two wired together, and the command ran with no further interaction. In some cases it downloaded a Linux program called "bot", and in others it left a web backdoor for sending commands later.
Siemens published the advisory and the fixed version on August 112, and CISA, the US cybersecurity agency, republished it4 on August 25. The first attacks VulnCheck has seen came about two and a half months later.
◢Does it only affect Siemens devices?
The CVE covers four SIMATIC IoT2050 models (Advanced, Basic, M.2 and SM) on versions before V4.3.4-1 with Node-RED installed, according to the official record3 maintained by Siemens. But the underlying issue is wider. The official Node-RED documentation5 explains that the editor is unprotected by default: anyone who can reach its address can get in and deploy changes, which it considers acceptable only on a trusted network.
That's why VulnCheck1 concludes that installations without adminAuth, the setting that turns on login, are being found and attacked automatically. So not owning anything from Siemens doesn't make you safe. VulnCheck also mentions another industrial vendor that uses Node-RED, while making clear it hasn't checked whether those products are affected.
◢What we know and what we don't
We know the source IP sits on Microsoft's network and geolocates to Brazil, and that it hit this flaw 16 times between October 30 and November 1. In total it has made 125 attempts against eight flaws in unrelated products. VulnCheck reads this as opportunistic mass scanning, not a targeted attack, according to its analysis1. They aren't after your company in particular, just anyone with the door open.
We don't know who's behind it. VulnCheck warns that an address at a cloud provider doesn't identify anyone and that the machine may be rented or compromised. We also don't know what the downloaded program does, because it hasn't been analysed: it could be a cryptominer, a denial-of-service bot or a remote access tool. VulnCheck doesn't give figures for how many Node-RED instances are exposed either. And as of November 8 the flaw still isn't in CISA's catalog of exploited vulnerabilities6, though it is in VulnCheck's own.
◢What to do this week
This draws on what Siemens2, CISA4 and VulnCheck1 recommend, in the order I'd do it:
- ▹
Find out where you run Node-RED. Ask your integrator or whoever maintains your machines too, because it may be inside a gateway or an industrial device. Its usual port is 1880.
- ▹
Check whether it can be reached from outside your network. If it can, cut that off now. Control equipment shouldn't be on the internet: put it behind a firewall and connect through an up-to-date VPN.
- ▹
Turn on login with
adminAuth, following the official guide5. If you don't use Node-RED, uninstall it. - ▹
If you have a SIMATIC IoT2050, whether Advanced, Basic, M.2 or SM, update it to V4.3.4-1 or later.
- ▹
Review deployed flows for
execnodes or HTTP endpoints nobody recognises. Some attackers leave their backdoor there, and it survives a reboot.
If you have someone technical, have them search the logs for the addresses VulnCheck published (4.201.105.116, 85.215.73.250 and 45.194.90.57) and for the files /dev/shm/.b, /tmp/.s and /tmp/.kworker.
If you find something, don't just delete the flow. I'd treat that device as compromised: isolate it from the network, rebuild it from a clean copy and change every password and key stored on it, because a tool like this usually has access to other systems. In Spain, INCIBE's helpline7, 017, helps businesses for free.
◢What this case leaves behind
It's the same pattern as the attacks on supermarket fridges: a device that doesn't look like IT, installed to solve one specific problem, that ends up on the internet without being on anyone's list. In a factory, that device also tends to sit right where the office network meets the machine network.
Automated attacks don't tell a multinational from a small workshop. That's why the first thing I recommend to any industrial company is an inventory of what's connected and who can get in from outside. I've written before about how attacks rarely come in through the server. If you want your team to know what to ask your suppliers, I cover it in my cybersecurity training for companies.
Related documents
- News
Crédit Mutuel Arkéa cyberattack: attackers came in through a vendor
French bank Crédit Mutuel Arkéa suffered an attack that allowed fraudulent transfers from its own account. The attackers got in through a service provider's platform. What we know, what we don't and what to learn.
- Article
Device code phishing: what it is and how to stop it
Device code phishing tricks the victim into typing a code generated by the attacker into Microsoft’s real sign-in page. That gives the attacker access to their Microsoft 365 account without a password and without two-step verification getting in the way. Blocking that sign-in flow stops it.
- News
Claude Code leaks keys on GitHub: the settings.local.json problem
Claude Code's "don't ask again" option can save passwords and API keys in .claude/settings.local.json. Apiiro found 1,122 public copies on GitHub with secrets inside. What we know and what to do.