Node-RED CVE-2026-58115: Check Your Instances
CVE-2026-58115 is a critical Node-RED flaw that lets an unauthenticated attacker create flows that run system commands, and it is reported as exploited in attacks as of 5 November 2026, so check today whether your instance is open to the internet and has adminAuth turned on.
This post is for anyone who runs Node-RED, or who has a device or vendor that does: small businesses, agencies, makers, and teams with Siemens IoT2050 gear. You will get a plain-English explanation of the flaw, a five-minute exposure check, a way to review your flows for risky nodes, and what to do if something looks wrong.
One note on sources. The facts below come from the SecurityWeek report on the Node-RED flaw, which cites advisories from VulnCheck and Siemens. Open the advisory links in that article, and the references section of the NVD record for CVE-2026-58115, for the exact severity score, affected versions and fixed versions. We do not list Node-RED or firmware version numbers here because we do not want you to rely on a number we cannot back up.
What happened with this Node-RED vulnerability
Node-RED is a visual tool for wiring together devices, APIs and online services. You build "flows" by connecting boxes (called nodes) in a browser editor. Many people use it for home automation, sensors, small business integrations and industrial gateways.
The flaw is missing authentication on the Node-RED HTTP interface. In simple terms, the web door that lets you build flows does not ask who is knocking. An outsider who can reach it can create a flow, and a flow can include a node that runs commands on the server.
According to the reporting:
- The flaw is rated critical and has been reported as exploited in attacks.
- The risky situation is an instance that can be reached from the internet and does not have
adminAuthenabled. - Siemens IoT2050 devices are affected. Check the Siemens advisory for the fixed firmware version.
None of this means your instance has been hit. It means the risk is real, so a quick check is worth your time.
What adminAuth means in plain words
adminAuth is a setting in Node-RED's settings.js file. It puts a login in front of the editor and the admin API (the behind-the-scenes web endpoints the editor uses). With it on, a visitor must sign in before they can view or change flows. Without it, anyone who can load the page can act like the owner.
The official Node-RED guide to securing Node-RED explains it. A minimal setup looks like this:
adminAuth: {
type: "credentials",
users: [{
username: "admin",
password: "PASTE_BCRYPT_HASH_HERE",
permissions: "*"
}]
},
Create the hash with Node-RED's own tool, then paste the output in place of the placeholder:
node-red admin hash-pw
Restart Node-RED afterward. Use a long, unique password and never reuse one from another account.
Two cautions:
adminAuthis not a patch. Update to a fixed release as the maintainers' advisory directs. Use both: a login and the update.adminAuthcovers the editor and admin API. Public pages built with HTTP nodes are protected separately (the guide covershttpNodeAuth).
Step 1: Check if your instance is reachable from the internet
The default Node-RED port is 1880. Run these checks only against systems you own or manage.
- Test from outside your network. Turn off Wi-Fi on your phone and open
http://YOUR-PUBLIC-IP:1880or your domain with:1880. If the editor loads, it is exposed. - Check what the server is listening on. On the host, run:
ss -tlnp | grep 1880
127.0.0.1:1880 (or [::1]:1880) means local only. 0.0.0.0:1880, *:1880 or [::]:1880 means all network interfaces.
- Check whether a login is required. From a machine that can reach it, run:
curl -s -o /dev/null -w "%{http_code}\n" http://YOUR-HOST:1880/flows
A 200 means the flow list came back with no login, which is the situation attackers look for. A 401 means a login is being asked for. A 401 means you are not in the open-door situation described by the reporting, but it does not mean you are patched. Update anyway, because we have not verified whether the flaw can be reached when adminAuth is on.
- Check your router and firewall. Look for port forwards to 1880 and cloud security group rules that allow it from "anywhere".
- Check reverse proxies. If Nginx, Caddy or a tunnel service sits in front, confirm it does not publish the editor path to the public.
Our free website security check looks at your public website passively. It will not scan port 1880 or tell you whether Node-RED is exposed, so use the checks above for that.
Step 2: Lock it down today
| Your situation | What to do now |
|---|---|
Exposed to the internet, no adminAuth | Block port 1880 at the firewall first, then enable adminAuth, then update. Then follow the review steps below, because you may already have been reached |
Exposed, adminAuth on (or /flows returns 401) | Update per the advisory anyway, since we have not verified whether the flaw can be reached with adminAuth on. Also restrict access to known IPs or a VPN |
Local network only, no adminAuth | Enable adminAuth and update. Other devices on your network can still reach it |
| Siemens IoT2050 | Update firmware as directed in the Siemens advisory |
| Not sure | Treat it as exposed until the checks above say otherwise |
How to update a standard install: the official Node-RED getting started docs have upgrade instructions for each install type (npm, Docker, Raspberry Pi and others). Follow the one that matches how you installed it, and take the target version from the advisory.
Useful hardening steps:
- Bind Node-RED to localhost with
uiHost: "127.0.0.1"insettings.jsif only the same machine needs it. - Put access behind a VPN or an authenticated reverse proxy rather than a public port.
- On Ubuntu with UFW (not for Docker-published ports, which bypass UFW), use
sudo ufw deny 1880/tcp, then confirm withsudo ufw status verbose. UFW applies the first matching rule, so an earlier allow rule can still win. Runsudo ufw status numberedand, if needed, put the deny first withsudo ufw insert 1 deny 1880/tcp. Make sure you will not lock yourself out of your own access first, then retest from outside your network. - If Node-RED runs in Docker, publish the port on localhost only (for example
-p 127.0.0.1:1880:1880) or block it at a cloud or network firewall outside the host.
A missing login is fixed by closing the door and updating, not by headers.
Step 3: Review your flows for exec nodes
The reported attack creates flows that run system commands. The Node-RED node built for that is the exec node, which runs a command on the host. Some people use it legitimately, so the goal is to find ones you do not recognize.
In the editor (after logging in):
- Open the menu (top right) and choose Search flows or press Ctrl+F.
- Search for
exec, then look for unknown tabs and nodes. - Open each exec node and read the command. Ask whether you or a teammate created it.
- Check every tab, including disabled ones, and note the creation context if you can.
On the server:
Your flows are stored in JSON files inside Node-RED's user directory (the exact file name depends on your setup).
grep -E '"type": ?"exec"' ~/.node-red/flows*.json
Function nodes can also run code, so search for them separately and read any you did not write:
grep -E '"type": ?"function"' ~/.node-red/flows*.json
The ~/.node-red/ path is only the default. Under Docker the flows directory is usually /data. It also differs in Node-RED projects or when a custom userDir is set. Look for the userDir path in settings.js or in the Node-RED startup log, and point the commands there.
Any match is a place to look, not proof of a problem. No exec nodes does not prove you were not hit. Attackers can run a command and delete the flow afterward. If the instance was exposed without adminAuth, treat it as possibly compromised: check for unfamiliar processes, files and outbound connections, rotate secrets, and consider rebuilding from a known good image.
Also watch for:
- Flows with names you do not recognize, or an inject node set to run on a timer.
- Commands that download files, such as
curlorwgetpiped into a shell. - New files in web-accessible folders, unfamiliar processes, or outbound connections you cannot explain.
If you find something suspicious
Stay calm and work in order:
- Disconnect the machine from the network, or block it at the firewall.
- Save copies of
flows.json, logs and unfamiliar files before changing anything. - Treat every secret the instance could read as exposed. That includes API keys and passwords stored in flows and credentials files. Rotate them from a clean machine.
- Rebuild from a known good image and restore only flows you have reviewed line by line.
- Update, enable
adminAuth, and keep the editor off the public internet before reconnecting.
The what to do if your website was hacked guide walks through cleanup in more detail. If your Node-RED box shares a network with a website or store, review those too. Our is my website hackable guide shows how to think about that wider exposure.
How to avoid the next one
This kind of flaw repeats across many tools: an admin interface left open to the internet. A few habits cut the risk a lot:
- Never publish admin panels on the open internet. Use a VPN or allowlist.
- Turn on authentication before the first deployment, not after.
- Subscribe to vendor security notices for tools you run.
- Keep a list of what you run and where it is reachable from.
- Run an outside check on a schedule, because configuration drifts.
Key takeaways
- CVE-2026-58115 is a critical Node-RED flaw reported as exploited in attacks. Missing authentication on the HTTP interface lets outsiders create flows that run commands.
- Check now whether port 1880 is reachable from the internet, and whether
/flowsreturns data without a login. A 401 is good, but update anyway. - Enable
adminAuth, restrict access, and update using the maintainers' and vendors' advisories. On Siemens IoT2050, follow the Siemens advisory for the fixed firmware. - Review your flows for exec nodes and anything you do not recognize, but a clean search does not prove a clean host. If the instance was exposed, check processes and files, rotate secrets, and consider a rebuild.
Want a human to look at it?
A tool can tell you a port is open. A person can tell you what it means for your business. A Circuit audit from Bug Circuit is $49 one time: a security engineer manually reviews your site and writes up every issue with severity, evidence and exact fixes. The Circuit audit covers your website. If Node-RED runs on a separate server, tell us and we will say plainly whether it is in scope. It is a small-site audit, not a compliance certificate or a long enterprise engagement. Start with the free website security check if you just want a first look at your public site.
A real human security engineer audits your whole site by hand and sends a full report: every issue, its severity, and the exact fix. From $49, with a 14-day money-back guarantee.
See pricing