Node-RED flaw turned into Linux bot dropper

A flow-based programming tool that shows up inside industrial control and operational technology setups is being used as an entry point for Linux malware. VulnCheck researchers say they caught an attacker abusing a maximum-severity Node-RED vulnerability to deploy a flow that pulls down and runs a Linux bot — a chain that needs no authentication on the affected Siemens devices.

The finding lands against a backdrop of criminals paying closer attention to OT and ICS devices that can be reached from the internet, where a successful intrusion can affect equipment in the physical world rather than just a server rack.

Anatomy of the Node-RED flaw

Node-RED is commonly used for workflow automation in ICS and OT environments. It is built on top of Node.js and appears in commercial products, including the Siemens SIMATIC IoT2050.

According to the source reporting, Siemens assigned the vulnerability identifier CVE-2026-58115 in August to describe the bug and explain its perfect 10-out-of-10 CVSS rating. Affected Siemens devices do not enforce authentication on the Node-RED HTTP interface, which allows unauthenticated access to programming nodes capable of executing system commands on the device.

That combination means an unauthenticated remote attacker can create malicious flows. VulnCheck researchers began documenting activity against the flaw last Friday.

Two built-in nodes do the work

The exploit does not require a bespoke toolchain. VulnCheck researcher Patrick Garrity noted that two Node-RED built-in nodes make the vulnerability trivial to weaponize.

One is an inject node, which fires a message either on a schedule or once at startup. The second is an exec node, which can run shell commands. Chaining the two produces a flow that runs a command the moment it is deployed.

“Wire one to the other and the flow executes a command as soon as it is deployed, with no further interaction,” Garrity said.

— Patrick Garrity, researcher at VulnCheck

Because both components ship with the product, an attacker does not need to find a separate command-execution primitive. The flow itself is the payload delivery mechanism.

One POST and a single source address

The activity VulnCheck observed originated from a single IP address, 4.201.105[.]116, which sits in Microsoft's AS8075 network and geolocates to Brazil.

“It didn't just scan us. It sent the complete exploit, flow and dropper, in a single POST /flows,” Garrity wrote.

— Patrick Garrity, researcher at VulnCheck

That single-request pattern delivered everything needed to trigger the flaw and stage the follow-on download. The researchers did not retrieve a binary or staged scripts to analyze.

The filename, bot-linux-amd64, indicates the malware targets Linux running on AMD64 processors. It also suggests the malware operator may have other builds. As Garrity noted, the team did not fetch the binary, so what it does once running remains unknown.

Sixteen attempts and a wider canary net

Between October 30 and November 1, the researchers saw the same IP address target the Node-RED vulnerability 16 times. Across their wider canary network, that address logged 125 hits against eight different CVEs.

Among the targets was a seven-year-old Apache Solr flaw tracked as CVE-2019-17558, affecting Camunda, Gitea, MLflow, Traefik, and Joomla, alongside Node-RED.

• October 30, 2026: a VulnCheck canary caught an attacker exploiting CVE-2026-58115
• 10 out of 10: the CVSS rating assigned to the Node-RED vulnerability
• 4.201.105[.]116: the single source IP address, in Microsoft's AS8075 network, geolocating to Brazil
• 16: times that address targeted the Node-RED vulnerability between October 30 and November 1
• 125: hits logged against eight different CVEs across VulnCheck's wider canary network
• 7: approximate age in years of the Apache Solr flaw CVE-2019-17558 also targeted
• 12: US states affected by water system attacks over the summer, per the source reporting

A second server in the chain

One of the hits delivered a different payload pointing to a separate server, 85.215.73[.]250. VulnCheck now tracks that address but has no telemetry beyond the URL itself.

Garrity described the likely arrangement in the advisory. Because the download host is a different machine from the one that sent the exploit, he wrote that the probable setup is a scan-and-infect arrangement in which hosts that find and exploit vulnerable instances pull the implant from a separate, dedicated server.

Why the spread of bugs matters

The mix of old and new bugs across unrelated products points to one conclusion in Garrity's assessment: this is opportunistic mass scanning rather than a targeted attack.

That framing matters for defenders deciding where to spend time. A campaign that sprays a fresh 10-out-of-10 flaw alongside a seven-year-old Solr bug is not picking its victims carefully. It is looking for whatever answers.

The Node-RED exposure is the newest element in that mix, and it arrives on devices that may sit inside networks operators consider closed.

Catalog status and the OT backdrop

The bug has been added to VulnCheck's Known Exploited Vulnerabilities catalog. The source reporting notes that, as of press time, it had not appeared in the US Cybersecurity and Infrastructure Security Agency's KEV list.

The exploitation also comes as criminals increasingly look to target internet-exposed OT and ICS devices, a shift that lets cyberattacks reach the physical world. The source points to the ongoing refrigeration controller hacks across Europe and attacks on water systems across at least 12 US states over the summer as examples.

What Garrity tells operators to do

The advisory does not stop at describing the intrusion. It carries a direct instruction for anyone running the tool, wherever it sits.

“If you run Node-RED anywhere, including inside OT environments, check today whether it's reachable from outside your network, apply updates where available and implement detections to reduce the risk of exploitation,” Garrity added in a LinkedIn post.

— Patrick Garrity, researcher at VulnCheck

That advice breaks into three checks: whether the interface is reachable from outside the network, whether updates are available and applied, and whether detections exist to catch exploitation attempts.

The limits of what is known

Several gaps remain in the public picture. VulnCheck did not retrieve the binary, so the post-exploitation behavior of bot-linux-amd64 is undocumented. The second host, 85.215.73[.]250, is tracked only by URL, with no further telemetry.

What is documented is the mechanics: an unauthenticated HTTP interface, two built-in nodes, and a single POST that carries the whole chain. Those are the facts operators can act on now, even while the payload's purpose stays opaque.

What this means for defenders

The practical consequence for anyone running Node-RED — and especially for those running it in OT environments — is that reachability is the whole ballgame. A device that enforces no authentication on its HTTP interface and can be reached from outside the network does not need a sophisticated attacker to fall; it needs a single request. This suggests that inventorying which automation tools are internet-facing, and closing that path where it is not required, may matter more than waiting for a full analysis of the payload.

For the wider OT and ICS sector, the episode reinforces a pattern the source already documents: criminal interest in exposed industrial gear is not hypothetical, and campaigns that mix fresh critical flaws with years-old bugs are inexpensive to run. The inference is uncomfortable but reasonable — operators who assume a network boundary is doing the protecting may want to verify that assumption directly, because the scanning side is not making the same assumption on their behalf.