Unknown Attackers Target Node-RED With Linux Bot and Webshell Payloads

Key points

• Unknown actors made several attempts to exploit Node-RED from a single source IP.
• Observed payloads included a Linux bot component and webshell code.
• No CVE identifier has been tied to the activity.
• Internet-exposed Node-RED services should be reviewed and hardened.

Unknown threat actors have made repeated attempts to exploit Node-RED, an open-source flow-based programming environment. The activity was linked by a common source IP address across several intrusion attempts. In at least some cases, the attackers moved beyond probing and delivered malicious payloads, including a Linux-targeting bot component and web shell code. No CVE has been published for this activity, so defenders cannot rely on a single vulnerability identifier to guide detection.

Any organization running Node-RED should treat exposed instances as a priority review item. For K-12 and public-sector IT teams, that includes departmental automation servers, lab systems, and any developer-owned instances that may have been stood up outside standard change control. Node-RED is often used to connect APIs, devices, and internal services, so an overlooked instance can sit close to sensitive workflows.

The impact is not limited to the Node-RED process itself. Web shell payloads can provide persistent remote access, while a Linux bot component can enroll a compromised host into a botnet and enable follow-on activity. Because the attackers used the same IP across multiple attempts, that address is a useful hunting lead, but it should not be the only indicator: source addresses can change, and payload delivery may vary between attempts.

With no CVE assigned, detection depends on operational visibility. Administrators should inspect Node-RED logs, authentication records, flow changes, and process behavior for signs of unauthorized access. Network telemetry should be reviewed for unusual outbound connections that could indicate bot enrollment or command-and-control traffic. File integrity monitoring and web directory reviews can help identify dropped web shell components.

What to watch: unexpected Node-RED flows, new administrative users, altered credentials, suspicious child processes, and outbound traffic from Node-RED hosts. Any host showing these signs should be isolated and investigated before remediation. The absence of a CVE does not mean the activity is low risk; it means defenders must lean on exposure management, logging, and host-based hunting.

What to do now

1. Inventory all Node-RED instances, then remove direct internet exposure or restrict access through VPN, allowlists, or a reverse proxy with authentication.
2. Update Node-RED and its dependencies to a supported release, and review authentication, authorization, and administrative endpoint settings.
3. Search perimeter, web, and Node-RED logs for exploitation attempts and the shared source IP; block confirmed malicious addresses at the edge.
4. Hunt for webshell files, unexpected flow changes, new users, and suspicious processes on Node-RED hosts; compare against a known-good baseline.
5. Monitor outbound traffic from Node-RED systems for botnet or command-and-control patterns, and isolate any host showing compromise indicators.
6. Enforce least privilege for Node-RED service accounts, disable unused admin features, and require strong credentials with MFA where supported.
7. Preserve logs and forensic evidence before cleanup, and follow incident reporting procedures if unauthorized access or payload delivery is confirmed.

Original source

SecurityWeek