How to Secure Node-RED With adminAuth and HTTPS

To secure Node-RED, turn on adminAuth in its settings file so the editor and admin API require a login, serve the editor over HTTPS, protect any HTTP endpoints your flows expose with httpNodeAuth, and keep the editor off untrusted networks. Node-RED ships with none of this enabled. Attackers exploiting the Siemens IoT2050 Node-RED flaw in late October 2026 went after exactly that default. This guide covers each setting, based on the Node-RED security documentation.

Before you start

Check what you are dealing with first.

• Is it a vendor build? If Node-RED came with a device, such as the Siemens SIMATIC IoT2050, follow the vendor's advisory first. For CVE-2026-58115, Siemens says to update to device version V4.3.4.1 or later, or uninstall Node-RED if you do not use it.
• Do you still need it? If nobody can name a flow that matters, uninstalling it is the strongest fix.
• Has it already been touched? If the editor was reachable without a login, assume someone else may have deployed flows. Export and review the flows before you change anything, so you keep a record of what was there.

How do you turn on Node-RED authentication?

You turn on Node-RED authentication by adding an adminAuth block to the Node-RED settings file. Once it is set, the editor and the admin API both require a login.

The Node-RED guide describes these adminAuth properties:

• type: use "credentials" for local usernames and passwords, or "strategy" to sign in through an OAuth or OpenID provider.
• users: a list of accounts. Each has a username, a password stored as a bcrypt hash, and permissions.
• permissions: "*" gives full access; "read" gives read-only access. Finer-grained permission lists are also supported.
• default: an optional anonymous user. If you set one, give it "read" at most, never "*".
• sessionExpiryTime: how long a login token lasts, in seconds. The default is 7 days; shorten it for shared engineering workstations.

Give full permissions only to the people who deploy flows. Operators who need to look at a flow get "read".

How do you generate the password hash?

You generate the bcrypt hash with Node-RED's own admin tool, then paste the hash (never the plain password) into the user's password field.

On Node-RED 1.1.0 or later, run:

node-red admin hash-pw

It prompts for the password and prints the hash. Older releases use the separate node-red-admin package for the same job. Store the plain password in your password manager, not in the settings file or a flow.

If your organization already runs an identity provider, the "strategy" type lets Node-RED use it instead of local accounts. That gives you central offboarding and MFA, which local credentials do not.

Serve the editor over HTTPS

Without TLS, the login you just added crosses the network in clear text. The settings file has an https property that takes a key and a cert in PEM format; the default settings file includes it commented out. Since Node-RED 1.1.0 the property can also be a function, which together with httpsRefreshInterval lets Node-RED pick up renewed certificates without a restart.

If Node-RED already sits behind a reverse proxy that terminates TLS, make sure the Node-RED port itself is not reachable directly, or the proxy adds nothing.

Protect HTTP endpoints your flows expose

adminAuth covers the editor and admin API. It does not cover HTTP In nodes, the endpoints your flows publish. Those are exactly what attackers used as persistent backdoors in the IoT2050 incidents, wiring an HTTP endpoint to a command execution node.

Use httpNodeAuth with a user and a bcrypt pass to put basic authentication in front of HTTP In node routes. If your flows serve static files, httpStaticAuth does the same for that content. The guide notes MD5 hashes are still accepted for backward compatibility but recommends bcrypt.

Limit who can reach the editor

Authentication is one layer. Network reach is the other.

• Block the editor port at the firewall from every network except the engineering workstations that need it.
• Never port-forward the editor to the internet for remote access. Use a VPN into the engineering network instead.
• On dual-homed gateways, check which interface the editor answers on. It should not answer on the plant floor side if engineers connect from the office side, or the reverse.

The same principle applies to any management interface; see how to audit read-only accounts on a management portal for a review checklist you can reuse.

How do you check for unwanted flows?

You check for unwanted flows by exporting every deployed flow and looking for command execution and inbound HTTP nodes you did not build. Do this before and after hardening.

Look for:

• Exec nodes, or function nodes that spawn processes or download files.
• HTTP In nodes on paths nobody recognizes (VulnCheck saw paths such as /cmd and random strings).
• Flows that run immediately on deploy rather than on a real trigger.
• Hidden files in /dev/shm and /tmp, such as .b, .s or .kworker, the names VulnCheck recorded.

If you find any, treat the host as compromised: preserve the flow export and logs, reimage the device and rotate every credential stored in its flows.

Keep it current

Hardening does not replace updates. Track Node-RED releases, and for vendor-bundled copies track the vendor's advisories, since you may not be able to update Node-RED independently. For background on how the tool works and why the editor matters, read what Node-RED is and why an open editor is a risk.