Node-RED and Android Security Advisories (November 2026): What Is Affected and How to Respond on Each Platform

Key Points

• Node-RED: By default, the editor and admin API have no authentication. Since 30 October, attackers have been seen planting malicious flows on such instances (VulnCheck)
• CVE-2026-58115: A CVSS 10.0 identifier assigned by Siemens, scoped to SIMATIC IoT2050 Advanced with Node-RED installed. It is not a flaw in Node-RED itself
• Fixing Node-RED: Turn on authentication with adminAuth and keep port 1880 off the internet. Updating to the latest 5.0.9 or 4.1.17 does not turn authentication on by itself
• Android: The 2 November bulletin fixes 216 issues, 23 of them Critical (our count). The most severe is a Framework remote code execution flaw, CVE-2026-58868
• As of 4 November, neither is in CISA's KEV catalog (known exploited vulnerabilities). Attacks on Node-RED have been observed, so deal with internet-facing instances first

About This Article

This article summarizes information from Siemens, the US CISA, CVE records, the official Node-RED documentation, Google's Android security bulletin and a VulnCheck report, as of 4 November 2026 (Japan time). The situation can change, so check the official links at the end for the latest status before you start work.

Severity scores differ by publisher. We state whose rating each score is.

First: Are You Affected?

Node-RED

• Is it running?: List everything running Node-RED, including servers, IoT gateways and monitoring terminals, as well as copies built into vendors' gateway products. The default port is 1880
• Listening address: By default (uiHost), Node-RED listens on all IPv4 interfaces (0.0.0.0). On Linux, run ss -ltnp | grep 1880 and check whether it is listening on 0.0.0.0:1880 or an external address
• Is authentication on?: Open http://<host>:1880/ in a browser. If the editor appears without a login screen, there is no authentication. Also check whether adminAuth is set in settings.js (and not left commented out)
• Checking the admin API: If curl -s -o /dev/null -w '%{http_code}\n' http://<host>:1880/settings returns 200, the admin API can be used without authentication. With authentication on, it returns 401 (if adminAuth gives anonymous users permissions through default, it returns 200 even with authentication on. If you have changed httpAdminRoot, check under that path; with httpAdminRoot: false it returns 404)
• Version: Check Node-RED version: vX.Y.Z in the startup log, or the version field in the response from the admin API's GET /settings. Note that node-red -v does not show the version; it turns on verbose logging. On 4.x and later, node-red --version prints the Node-RED and Node.js versions
• Siemens SIMATIC IoT2050 Advanced: Devices with order number 6ES7647-0BA00-1YA2 running Industrial OS before V4.3.4.1 with Node-RED installed are the formal scope of CVE-2026-58115

Android

• Patch level: In Settings, find the Android security update date in the device information (its location varies by model). If it is 2026-11-05 or later, all issues in this bulletin are covered
• Checking from a computer: adb shell getprop ro.build.version.security_patch shows the patch level date
• The two patch levels: 2026-11-01 covers the Android platform (Android runtime, Framework and System) and Google Play system updates. 2026-11-05 also includes the kernel and chip vendor components (Arm, Imagination, MediaTek, Unisoc and Qualcomm)

Node-RED: CVE-2026-58115 and Attacks on Unauthenticated Node-RED

What Happened

• CVE-2026-58115 (rated by Siemens): CVSS v3.1 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and CVSS v4.0 10.0. The weakness is CWE-306 (missing authentication for a critical function), and Siemens published advisory SSA-834709 on 11 August
• Cause (as Siemens describes it): The affected devices do not enforce authentication on Node-RED's HTTP interface. Nodes that can run system commands are therefore usable without authentication, so a remote attacker could create malicious flows and run arbitrary code with the highest privileges
• Publication history: The US CISA republished the same information as ICSA-26-237-03 on 25 August (affected sectors: chemical, critical manufacturing, energy and transportation). In Japan, JVN covered it on 12 August in JVNVU#98375707, its round-up of Siemens' August updates
• Observed attacks (VulnCheck): In a post dated 2 November, VulnCheck said one of its canaries caught an attack targeting this CVE on 30 October. The attack used a single POST /flows request to deploy a flow that downloads and runs a Linux bot. VulnCheck saw 16 hits from the same source between 30 October and 1 November and says it did not analyze the bot itself
• Later attacks: VulnCheck also reports a second payload server and attacks that plant webshells which survive a reboot (an http in node wired to an exec node)
• Difference from official assessments: CISA's assessment in the CVE record (12 August) still says no exploitation, and the CVE is not in the 3 November version of CISA's KEV catalog. As far as we could find, only VulnCheck's observations point to exploitation so far, and VulnCheck has added it to its own KEV list

Scope: Not a Flaw in Node-RED Itself

• Formal scope: According to Siemens, CISA and the CVE record, the scope is limited to SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) running Industrial OS before V4.3.4.1 with Node-RED installed
• The Node-RED project: Node-RED's security advisories on GitHub contain no advisory for this CVE (as of 4 November, the only advisories are two from February 2021). There is no Node-RED release that fixes this CVE
• VulnCheck's view: VulnCheck says its description of this CVE is based on its canary detection signature and the traffic it observed. On that basis it concludes that Node-RED instances without adminAuth are being found and attacked automatically. It does not say the targets were Siemens devices
• The underlying condition: The official Node-RED documentation says the editor is not secured by default and should only be used on a trusted network. These attacks target Node-RED instances that are reachable from outside with this default setting

Some media reports describe this as a critical Node-RED vulnerability, but for Node-RED users the key step is not a software update: it is turning on authentication and making the instance unreachable from outside.

Most Exposed Setups

• Port 1880 is reachable from the internet or an untrusted network
• adminAuth is not set, so anyone can access the editor and the admin API
• OS commands can be run through exec nodes and similar, and Node-RED runs with strong privileges such as root
• Node-RED is built into a vendor's gateway or similar product, and the people responsible do not know it is running

Fix: Turning On Authentication and Updating Node-RED

1. Cut off outside access: First, use a firewall or similar to block port 1880 from the internet and untrusted networks. For remote operation, go through a VPN or similar. If Docker publishes the port with -p 1880:1880, firewall rules such as ufw may not take effect. If Node-RED is only used on the same machine, recreate the container with -p 127.0.0.1:1880:1880
2. Turn on authentication: Set adminAuth in settings.js. You can generate a password hash with node-red admin hash-pw (Node-RED 1.1.0 or later). OAuth and OpenID are also supported. The older httpAdminAuth setting is deprecated
3. Protect public HTTP endpoints: You can add basic authentication with httpNodeAuth for pages and APIs exposed through http in nodes, and with httpStaticAuth for static files
4. Switch to HTTPS: Set a key and certificate (PEM) in the https setting in settings.js
5. Narrow the listening address: If Node-RED is only used on the same machine, set uiHost to 127.0.0.1 (inside a Docker container this makes Node-RED unreachable even from the host, so with Docker use -p 127.0.0.1:1880:1880 from step 1 instead). Where the editor is not needed, httpAdminRoot: false turns off all admin pages and APIs
6. Restart and check: After changing the settings, restart Node-RED and check that a login screen appears and that /settings returns 401

How to update Node-RED itself depends on how it was installed. Before you start, back up the user directory that holds your flows and settings (~/.node-red by default).

• Installed globally with npm: Check node -v first. 5.0.9 will not start on Node.js older than 22.9, so update Node.js first or stay on 4.x with sudo npm install -g node-red@4.1.17 (4.1.17 needs Node.js 18.5 or later). On Node.js 22.9 or later, run sudo npm install -g node-red (without sudo on Windows)
• Installed with the script on Raspberry Pi or Debian-based systems: Run the same script again: bash <(curl -sL https://github.com/node-red/linux-installers/releases/latest/download/install-update-nodered-deb). As of 4 November, the script (v2.2.1) keeps an existing Node.js of 22.9 or later. If Node.js is missing it installs it, and if it is older than 22.9 it removes the existing Node.js and reinstalls it (Node.js 24, or 22 on ARMv6 boards such as the Pi 1 and Pi Zero). It then sets Node-RED up as a service. The official docs still describe the older behavior (at least v20, 22 LTS), which no longer matches the script. Because this changes the Node.js version, take care if other Node.js apps run on the same machine
• Official Docker image: Pull a new tag of nodered/node-red and recreate the container (for example, docker pull nodered/node-red:5.0.9). To stay on 4.x, use a tag such as nodered/node-red:4.1.17-22. Keep your data in the /data volume
• snap: The official Node-RED documentation generally does not recommend snap. The snap version runs in a confined environment, where things such as external commands from the exec node are not available. If you installed it as a snap, sudo snap refresh node-red updates it, but as of 4 November the snap's stable channel is still 3.1.0, so it will not reach 5.0.9 or 4.1.17. If you need a current release, consider reinstalling with npm or Docker
• Latest releases: The latest releases are 5.0.9 (requires Node.js 22.9 or later) and the 4.x maintenance release 4.1.17, both published on 21 October. They contain routine fixes and no security advisory. 5.0.9 includes a fix for a crash on authentication messages when adminAuth is not set
• Siemens SIMATIC IoT2050 Advanced: Update to V4.3.4.1 or later. If you cannot update right away, Siemens suggests uninstalling Node-RED or hardening it according to the Node-RED user guide

Interim Measures If You Cannot Act Right Away (None Is Complete)

• Stop Node-RED instances you do not use. For a script install, stop it with sudo systemctl stop nodered and keep it from starting at boot with sudo systemctl disable nodered
• On your network equipment, limit access to port 1880 to specific management terminals
• If Node-RED runs as root, switch it to a dedicated user with fewer privileges

Checking for Compromise

• In the editor and in flows.json (in ~/.node-red by default; flows_<hostname>.json in older setups, /data/flows.json under Docker), look for flows you do not recognize, especially ones that contain exec or http in nodes
• Look for suspicious outbound connections and for processes or cron entries you do not recognize
• If you suspect a compromise, disconnect the machine from the network and consider reinstalling the OS. Also change the passwords and keys stored in Node-RED's credentials file (flows_cred.json, or flows_<hostname>_cred.json in older setups)

Android: November 2026 Security Bulletin

Main Vulnerabilities Fixed

• Publication: Google published the November 2026 Android Security Bulletin (version 1.0) on 2 November. A Japanese version is also available
• Count (our tally): The bulletin does not give totals. Counting its tables gives 216 issues: 23 Critical and 193 High. Patch level 2026-11-01 covers 119 (8 Critical), and 2026-11-05 adds 97 (15 Critical)
• CVE-2026-58868 (rated Critical by Google): A remote code execution flaw in Framework that needs no additional privileges and no user interaction. According to the CVE record, the cause is a heap out-of-bounds write in onOutputReceived in FrameDecoder.cpp, affecting Android 14, 15, 16, 16-qpr2 and 17
• Other Critical issues: These include remote code execution in System (CVE-2026-58876 and CVE-2026-58936), privilege escalation in the kernel's Bluetooth and pKVM, eight MediaTek modem issues and one Qualcomm closed-source component issue. The bulletin says the most severe kernel issue could lead to remote privilege escalation with no additional execution privileges or user interaction needed
• An issue in the news: CyberInsider reports that CVE-2026-58882, a Critical denial-of-service issue in System, is the flaw a researcher disclosed on 29 October in which a crafted WAP Push message drops calls. The bulletin itself does not say this
• Exploitation: This bulletin has no note about limited, targeted exploitation. CVE-2026-58868 is not in the 3 November version of CISA's KEV catalog, and CISA's assessment in the CVE record (2 November) also says no exploitation
• Source release: Google says it will release the source patches to AOSP within 48 hours of the bulletin. Device makers were notified at least one month in advance

Rollout by Device

• Pixel: As of 4 November, the November 2026 Pixel update bulletin has not been published. The latest is the October bulletin published on 6 October (patch level 2026-10-05)
• Other makers: Timing varies by maker, model and carrier. Check each maker's security information page
• Devices out of support: Devices whose update period has ended will not receive most of these fixes (some may still arrive through Google Play system updates)

Fix: Updating and Checking Devices

1. Check the device's patch level
2. Install the update from System update and restart
3. Check that the patch level is now 2026-11-05 or later
4. For older devices that no longer get updates, consider replacing them for business use, starting with devices used for admin consoles or authentication

• Bring business devices, and devices used for work in data centers, to 2026-11-05 or later as soon as the maker's update arrives
• If you use mobile device management (MDM), use its patch level list to find devices that have not yet received the update

What to Check After Updating

• Node-RED: After restarting, check that a login screen appears, that /settings returns 401 and that 1880 cannot be reached from outside
• Node-RED flows: Check again for flows you do not recognize, especially ones with exec or http in nodes
• Docker: Check that no old containers are left and, with docker ps, that they are running the new image tag
• Android: Check each device's patch level is 2026-11-05 or later
• Embedded products: For equipment with Node-RED built in, check the equipment maker's information

Official Sources

• Siemens: SSA-834709
• US CISA: ICSA-26-237-03
• CVE: Record for CVE-2026-58115
• JVN: JVNVU#98375707, Siemens product updates (August 2026, Japanese)
• VulnCheck: Exploitation targeting Node-RED (2 November 2026)
• Node-RED: Securing Node-RED
• Node-RED: Configuration
• Node-RED: Running Node-RED locally
• Node-RED: Running on Raspberry Pi
• Node-RED: Running under Docker
• Node-RED: Release 5.0.9 (GitHub)
• Node-RED: Security advisories on GitHub
• Android: Security Bulletin, November 2026
• Android: Pixel Update Bulletins
• CVE: Record for CVE-2026-58868
• US CISA: Known Exploited Vulnerabilities Catalog

Disclaimer

This article is Two Sheep Co., Ltd.'s summary of public information as of 4 November 2026 and does not guarantee the behavior or safety of any product. Always check each vendor's latest information before you start. Company and product names are trademarks or registered trademarks of their respective owners. Companies are named only as sources or subjects of this information; this does not imply any business relationship with Two Sheep.

If you need on-site work for servers in a data center, such as reboots, console access or hardware swaps, contact us about our remote hands service.