What Is Node-RED and Why Is an Open Editor Risky?

Node-RED is an open-source, browser-based tool for wiring together devices, APIs and services as visual "flows." Engineers use it on industrial gateways, building controllers and lab hardware to move data between PLCs, MQTT brokers and cloud services. The question for security teams is simple: what is Node-RED able to do if someone else reaches its editor? The answer is anything the host can do, because Node-RED includes nodes that run operating system commands, and its editor ships without a login.

What is Node-RED?

Node-RED is a flow-based programming tool that runs on Node.js and is edited in a web browser. You drag nodes onto a canvas, connect them, and click Deploy to make the flow live on the server.

Each node does one job. An input node listens for an MQTT message or an HTTP request. A function node runs a short piece of JavaScript. An output node writes to a database, sends a message or calls an API. The visual editor makes it quick for automation engineers who are not full-time developers to build integrations, which is why it shows up in manufacturing, utilities, healthcare, agriculture and home automation.

Vendors bundle it too. Siemens offers Node-RED as an optional package on the SIMATIC IoT2050 industrial gateway, and VulnCheck notes Node-RED is referenced in Emerson documentation.

How does the Node-RED editor work?

The editor is a web application served by the same Node-RED process that runs the flows. When you click Deploy, the browser sends the full flow configuration to Node-RED's admin API, and the runtime replaces what was running.

That admin API is the control plane. Anything that can call it can read every flow (including credentials stored in node settings), change flows and deploy new ones. The browser editor is only one client of it; a script can call the same endpoints directly.

Why is an open Node-RED editor dangerous?

An open Node-RED editor is dangerous because deploying a flow is the same as running code on the host. Node-RED includes an exec node that runs shell commands, and function nodes run JavaScript inside the runtime.

The Node-RED security guide states that the editor is not secured by default. Out of the box, anyone who can reach the editor's address can deploy whatever they like. Authentication has to be turned on in the settings file with the adminAuth option.

This is not a theoretical concern. In the Siemens IoT2050 Node-RED attacks (CVE-2026-58115), Siemens confirmed that affected gateways did not enforce authentication on the Node-RED HTTP interface. VulnCheck then recorded attackers deploying flows that downloaded a Linux bot binary, and in other cases planting HTTP endpoints wired to command execution nodes. VulnCheck observed the same traffic going after any Node-RED instance without adminAuth, not only Siemens devices.

What can an attacker do with Node-RED access?

With admin API access an attacker can run commands as the Node-RED user, read stored secrets and change what the integration does. On a gateway that bridges a plant network to the cloud, that is a lot of reach.

In practical terms:

• Run code. An exec node or function node runs whatever the attacker supplies. On the IoT2050, Siemens says this happens with maximum privileges.
• Persist in configuration. A flow is saved configuration, not a running process. A backdoor built as an HTTP input node feeding an exec node comes back after every reboot, and it will not show up in a file integrity check of the binaries.
• Steal credentials. Flows often hold MQTT broker passwords, database logins and cloud API keys.
• Tamper with data. The flow may be what moves sensor readings into a historian or sends setpoints to equipment. Changing it changes what operators see and what devices receive.
• Pivot. Gateways usually sit on two networks. A foothold there can reach systems that were never exposed directly.

Where does Node-RED usually run unprotected?

Node-RED usually runs unprotected wherever someone installed it for a quick integration and never revisited the settings file. Common places:

• Industrial IoT gateways where Node-RED was an optional package enabled during commissioning.
• Raspberry Pi and small Linux boxes in labs, workshops and building systems.
• Cloud VMs or containers stood up for a proof of concept with the editor port published.
• Home automation hubs that were later port-forwarded for remote access.

Asset inventories rarely list Node-RED as software because it lives inside a device or a container. Network scans for the editor's web interface and a review of what is installed on each gateway are usually the only way to find it. Our article on why industrial IoT gateways need a named patch owner covers that ownership gap.

How do you reduce Node-RED risk?

You reduce Node-RED risk by turning on authentication, limiting who can reach the editor and removing it where nobody uses it. Siemens' own mitigation list for CVE-2026-58115 is: update the device, uninstall Node-RED, or harden it according to the Node-RED user guide.

The core controls are:

• Enable adminAuth so the editor and admin API require a login, and give read-only access to anyone who does not deploy flows.
• Serve the editor over HTTPS.
• Protect HTTP endpoints that flows expose with httpNodeAuth.
• Keep the editor off the internet and reachable only from engineering workstations.
• Review deployed flows regularly for exec nodes and HTTP endpoints you cannot explain.

Step-by-step settings are in how to secure Node-RED with adminAuth and HTTPS.