Realtek Jungle SDK Exploit Attempts Deliver Cling Botnet With STUN-Based C2
Attackers exploiting Realtek Jungle SDK flaws are deploying the Cling botnet, which hides C2 in STUN traffic.
Nozomi Networks reported a spike, beginning around 5 September 2026, in attempts to exploit the patched critical Realtek Jungle SDK flaw CVE-2021-35394 (CVSS 9.8) to install the Cling botnet. The sample also embeds command-injection and remote-code-execution logic for devices from multiple vendors, including CVE-2014-8361, CVE-2016-10372, CVE-2016-20016, CVE-2023-26801, CVE-2023-41011, CVE-2024-3721, and CVE-2025-34037. Cling persists by adding itself to SysV and BusyBox init scripts or by replacing wget, then uses public STUN servers and transaction IDs for registration and commands. Those commands support worm-like scanning, TCP tunnels, proxies, and timed denial-of-service floods, including traffic aimed at a University of Chicago address and a South Korean ISP.
- Exploit attempts against CVE-2021-35394 rose from about 5 September 2026.
- Cling also carries exploits for several router and DVR flaws.
- It persists through init scripts or by replacing wget.
- Operators hide commands in STUN traffic and transaction IDs.
- Supported actions include scanning, proxying, tunneling, and timed floods.
Vulnerabilities mentionedAll →
- CVE-2014-8361—100%Improper Input Validation in Realtek SDK miniigd SOAP Service Enables Remote RCEpublished —· Realtek SDK KEV
- CVE-2016-103729.882%The Eir D1000 modem does not properly restrict the TR-064 protocol, which allows remote attackers to execute arbitrary commands via TCP port 7547, as…
Full article804 words · extracted from thehackernews.com · click to collapse
Ravie LakshmananOct 05, 2026Vulnerability / Malware
Threat actors have been observed attempting to exploit a now-patched critical security flaw impacting the Realtek Jungle software development kit (SDK) to deploy a botnet malware called Cling.
"Cling is notable not because it introduces a new propagation technique, but because it repurposes ordinary STUN behavior into a practical command-and-control channel," Nozomi Networks said in a report published last week. "The result is a botnet whose traffic can resemble legitimate NAT-traversal activity while still supporting propagation, proxying, tunneling and denial-of-service commands."
The operational technology (OT) security company said it observed a spike in attempts to exploit CVE-2021-35394 (CVSS score: 9.8), a critical remote code execution (RCE) flaw in Realtek Jungle SDK starting around September 5, 2026, with a subset of the activity delivering Cling.
An analysis of the malware sample has found it to embed exploit logic for various command injection and RCE vulnerabilities impacting routers and DVRs from multiple vendors -
- Realtek SDK RCE (CVE-2014-8361)
- Eir D1000 router RCE (CVE-2016-10372)
- MVPower CCTV DVR RCE (CVE-2016-20016)
- LB-LINK routers RCE (CVE-2023-26801)
- FiberHome SR1041F router / China Mobile HG6543C4 RCE (CVE-2023-41011)
- TBK DVR RCE (CVE-2024-3721)
- Linksys RCE (CVE-2025-34037)
"The single-instance check to only run one copy involves binding a socket with SO_REUSEADDR to port 33957 and exiting cleanly if it fails," Nozomi Networks said. "The sample copies itself to /root/.cling and /usr/local/bin/.cling. Both executables are appended to /etc/inittab, /etc/init.d/rcS, /etc/rc.d/rc.boot, thus achieving persistence on SysV and BusyBox init systems."
An alternative persistence mechanism involves identifying the wget binary on the infected system and then replacing it with the malware, but not before moving the original to another location. This, in turn, causes the malware to be executed when a legitimate process invokes the "wget" command.
A notable aspect of Cling is its abuse of harmless-looking STUN traffic and public STUN infrastructure to register infected hosts, receive operator commands, and make malicious activity less obvious from a network monitoring perspective.
STUN, short for Session Traversal Utilities for Network Address Translation (NAT), is a standardized network protocol that's designed to assist devices behind a NAT or firewall in establishing peer-to-peer real-time communications.
Specifically, the malware follows a four-step process for command-and-control (C2) communications -
- Send a STUN Binding Request to a hard-coded list of 13 STUN servers roughly every 5 seconds. The transaction ID is set to all zeros instead of a random value, as per the specification.
- Record the externally observed ports returned by those servers upon receiving a Binding Success Response message containing the public IP address of the endpoint and the associated port numbers.
- Sends a custom registration message (i.e., a UDP datagram) to each server that includes the mapped ports and a tag denoting how the device was infected (e.g., realtek.selfrep, selfrep.router).
- Poll for UDP packets that encode operator commands in the STUN transaction ID field.
"From a network monitoring perspective, the activity appears as innocuous interaction with STUN servers," Nozomi Networks said. "Given that the custom registration message is sent to every STUN server in the list, it is apparent that the operator requires visibility into at least one of the servers, in order to track new bots joining the swarm to know where to send commands to."
It's worth noting these registration messages do not conform to the STUN protocol definition, causing legitimate STUN servers to drop the packet. However, one of the 13 servers ("145.249.115[.]184") is said to have returned an all-zero transaction ID instead of echoing the transaction ID of the original Binding Request in the Binding Success Response.
This unusual behavior, per Nozomi, suggests the STUN server is tailored to the bot's own STUN traffic and that it's used to send operator-issued commands to the infected device by embedding them within the STUN transaction ID field.
The commands allow the threat actor to recursively scan and spread the scale of the botnet in a worm-like fashion, spawn/stop a TCP tunnel, launch/stop a proxy, and perform a denial-of-service (DoS) attack against a specified target for a given time duration. Some of the targets of the flooding attacks are below -
- 112.151.157[.]222:8080 (South Korean ISP)
- 192.170.240[.]137:53 (University of Chicago cluster)
- 23.81.40[.]193:25565 (Minecraft)
- 147.185.221[.]129:25565 (Minecraft)
"The most interesting part of the C2 traffic is where the commands appeared to come from," Nozomi Networks explained. "The packets carrying operator commands originate from 74.125.250[.]129, an IP address that stun.l.google.com resolves to."
"In other words, the operator is not merely hiding commands inside a STUN-looking packet, but they are making those commands appear as if they are legitimate replies from one of the most recognizable STUN services on the internet."
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.