Attackers are once again exploiting CVE-2021-35394, a critical remote code execution vulnerability in the Realtek Jungle SDK, to compromise Internet-exposed IoT and networking devices. The flaw carries a CVSS score of 9.8 and affects the diagnostic component commonly compiled as UDPServer. Nozomi Networks says it observed a sharp increase in exploitation attempts beginning around September 5, 2026. Most activity appeared to be routine opportunistic probing, but some successful exploitation attempts downloaded and executed a botnet malware family called Cling.

The vulnerability itself is old, but that is precisely why this campaign matters. CVE-2021-35394 was disclosed in 2021 and has already been exploited heavily in previous botnet campaigns. Palo Alto Networks previously documented the flaw across embedded devices from numerous vendors, while earlier telemetry showed more than 100 million exploitation attempts against the vulnerability. The problem is not lack of awareness. It is that vulnerable SDK code remains buried inside devices that continue to operate years after their manufacturers stopped providing updates.

In the attacks observed by Nozomi, exploitation is straightforward. The attacker sends UDP datagrams beginning with orf;, followed by shell commands. The vulnerable device executes those commands, after which the attacker uses BusyBox wget to retrieve the Cling malware, makes the downloaded binary executable, and launches it with a tag identifying the infection method. The resulting chain is therefore: Internet-exposed Realtek SDK component → crafted UDP packet → unauthenticated command execution → malware download → Cling installation → persistence and botnet enrollment.

Cling is not limited to the Realtek vulnerability that initially delivered it. Nozomi found embedded exploit logic for several other router and DVR vulnerabilities, including CVE-2014-8361, CVE-2023-26801, CVE-2024-3721, CVE-2025-34037, CVE-2016-10372, CVE-2023-41011 and CVE-2016-20016. These affect products from vendors including Realtek, LB-LINK, TBK, Linksys, Eir, FiberHome and MVPower. Once an infected device joins the botnet, it can therefore scan the Internet and attempt to compromise additional systems using multiple known command-injection and remote-code-execution flaws.

This makes Cling a useful example of why botnet operators do not need new zero-days to remain effective. The Internet contains enormous numbers of old devices running known-vulnerable firmware. An exploit published years ago may still deliver a reliable infection if the vulnerable component remains reachable. For attackers, that is considerably cheaper than researching a new vulnerability. Old vulnerabilities with large unpatched populations effectively become permanent infrastructure.

The persistence techniques used by Cling are also more deliberate than the usual one-file IoT infection. The malware copies itself to locations including /root/.cling and /usr/local/bin/.cling, then adds references to those binaries in startup files such as /etc/inittab, /etc/init.d/rcS and /etc/rc.d/rc.boot. This allows the bot to survive reboots on BusyBox and SysV-style embedded Linux systems.

Cling also uses a more unusual persistence technique involving wget replacement. The malware finds the legitimate wget binary, moves it elsewhere under a name such as wget.r, stores the original path in a companion wget.p file, and places Cling itself where wget previously existed. When a legitimate process later invokes wget, the malware executes first and then forwards the original arguments to the preserved genuine binary. That means routine maintenance, cron jobs or even another attacker attempting to download a payload can inadvertently restart or reinstall Cling.

That persistence mechanism is clever because it turns a legitimate administrative utility into a recovery trigger. An administrator may remove the visible .cling file and believe the device is clean, only to have the bot reinstall itself when wget is next used. On embedded devices where endpoint telemetry is already limited, such behavior can survive much longer than defenders expect.

The most distinctive part of Cling, however, is its command-and-control architecture. The bot abuses STUN, or Session Traversal Utilities for NAT, a legitimate protocol widely used to help devices discover their public IP address and NAT-mapped port. STUN traffic is common in applications including Microsoft Teams, Zoom, Cisco Webex and WebRTC-based browser communications, making it a particularly attractive protocol in which to hide malicious activity.

Cling periodically sends STUN Binding Requests to a hard-coded list of 13 STUN servers, roughly every five seconds. Instead of using a properly randomized STUN transaction ID, the malware sets the identifier to all zeros. Each legitimate STUN server responds with the bot’s externally visible IP address and mapped source port. Cling then sends a custom registration datagram containing those mapped ports and the infection method tag, allowing the botnet operator to learn how the compromised device can be reached through NAT.

After registration, the infected device waits for UDP packets containing operator instructions encoded directly inside the 12-byte STUN transaction ID field. That field is normally just an identifier used to associate a STUN response with a request. Cling repurposes it as a covert command channel. Nozomi observed commands instructing infected devices to execute payloads, scan for additional vulnerable systems, start or stop TCP tunnels, operate as proxies and launch denial-of-service floods.

The command set makes Cling more useful than a simple DDoS bot. An infected router or DVR can become a proxy node, TCP tunnel, malware loader and scanning platform. That creates secondary security implications for organizations whose devices are compromised. Even if the bot never attacks the organization itself, the device can be used to relay somebody else’s malicious traffic, hide an attacker’s origin or provide an externally reachable tunnel into network environments that were never intended to accept inbound connections.

Nozomi’s investigation identified one particularly suspicious STUN server at 145.249.115[.]184. Researchers registered fake bot instances while advertising different mapped port lists to each STUN server. Several hours later, ports disclosed only to that server received actual Cling commands, demonstrating that the server was either controlled by or cooperating with the botnet infrastructure.

The campaign becomes even more interesting when examining where command packets appeared to originate. Nozomi observed C2 packets carrying Cling instructions apparently coming from 74.125.250[.]129, an address associated with stun.l.google.com. The researchers concluded that the most likely explanation is source-IP spoofing, enabled somewhere along the attacker’s network path because source address validation was not being properly enforced. The TTL differences between legitimate Google STUN replies and the malicious command packets supported that assessment.

That technique is important because it exploits reputation as a defensive weakness. Security teams naturally treat packets associated with Google infrastructure differently from traffic coming from an unknown VPS. A UDP response that appears to originate from a well-known STUN service after the device has already initiated STUN communication can blend into normal NAT-traversal behavior. The attacker is not compromising Google’s STUN infrastructure; the observed evidence instead suggests spoofing traffic so that commands appear to come from a trusted source.

This distinction should be kept explicit. It would be inaccurate to say that Google STUN servers are hosting the Cling botnet or knowingly relaying malicious commands. The research indicates that legitimate STUN infrastructure is being used for normal mapping operations while command traffic is shaped to resemble trusted STUN responses, with source spoofing the likely explanation for packets appearing to come from Google.

The technique illustrates a broader shift in command-and-control design. Malware increasingly hides inside protocols and infrastructure defenders are reluctant to block: cloud services, collaboration platforms, DNS-over-HTTPS, WebSockets, public repositories and now STUN. The destination or source reputation alone is therefore becoming a weaker security signal. A connection to a trusted service can still participate in malicious behavior.

Protocol-aware inspection becomes more useful in this situation. Cling leaves several behavioral anomalies that distinguish its traffic from normal STUN. Its Binding Requests use all-zero transaction IDs, despite RFC 8489 requiring unpredictable values. The bot sends custom non-STUN registration datagrams to STUN endpoints and polls repeatedly at short intervals. Operator commands also appear in the transaction ID field, which is an unusual place to find structured control data.

Those patterns create detection opportunities even when the endpoints themselves have good reputations. Defenders should look for repeated STUN requests from devices that do not normally generate STUN traffic, particularly routers, DVRs, cameras and embedded appliances. A surveillance camera making STUN requests every five seconds to a rotating list of public servers is considerably more interesting than a Teams client doing the same sort of protocol exchange during a video call.

Organizations should also look for the host indicators identified by Nozomi, including .cling files under /root or /usr/local/bin, startup entries referencing those files, and unexpected wget.r or wget.p files that indicate the legitimate downloader has been replaced.

The challenge is that many embedded devices provide little or no endpoint telemetry. Security teams may not be able to install an EDR agent on a DVR or cheap router, making network visibility and asset inventory considerably more important. If defenders cannot inspect what is running on the device, they need to understand what the device normally communicates with and identify deviations.

Segmentation also matters. Internet-facing IoT and networking equipment should not automatically enjoy broad connectivity into internal business networks. A compromised camera or router that becomes part of Cling should ideally remain confined to a network zone where it cannot directly reach sensitive servers, directory infrastructure or management systems.

The campaign is also a supply-chain lesson, although not in the conventional malicious-update sense. CVE-2021-35394 originated in the Realtek Jungle SDK, and device manufacturers incorporated that SDK into their own routers, cameras, access points and appliances. Customers may not even know that a Realtek component exists inside the product they purchased. As a result, vulnerability tracking at the product-brand level can miss inherited risks buried inside third-party firmware components.

This creates what might be called embedded dependency debt. A vulnerability in one SDK can persist across dozens of downstream vendors, and some of those products will never receive patched firmware because they are inexpensive, unsupported or already considered end-of-life. The vulnerability effectively outlives the product-maintenance process designed to fix it.

CVE-2021-35394 illustrates this exceptionally well. The flaw has been known for years and has been exploited at enormous scale before, yet Nozomi is still seeing renewed exploitation in 2026. That does not indicate the patch failed. It indicates that the vulnerable devices did not disappear.

For organizations, the correct response therefore goes beyond checking whether a patch exists. Security teams need to identify which actual devices in their environment embed the affected Realtek SDK and whether those specific products ever received a vendor firmware update. If no safe firmware exists, the device may need to be isolated or replaced.

The vulnerability affects Realtek Jungle SDK versions 2.0 through 3.4.14B and allows unauthenticated remote command execution against the diagnostic service. CVE-2021-35394 was added to CISA’s Known Exploited Vulnerabilities catalog long ago, so the renewed activity is not a new warning that exploitation is possible. It is evidence that exploitation remains economically useful years later.

That distinction matters for vulnerability-management programs. Many organizations prioritize recently disclosed CVEs because “new” feels synonymous with “dangerous.” Botnet operators have fewer aesthetic concerns. They care about what still works.

A five-year-old vulnerability with 50,000 exposed devices may be far more useful to an attacker than a five-day-old vulnerability affecting a few carefully managed servers.

The Cling campaign therefore argues for exposure-based vulnerability prioritization, not simply age-based prioritization. Known-exploited vulnerabilities should remain relevant until the vulnerable asset population has actually been eliminated.

Another important point is that not every exploit attempt observed by Nozomi resulted in Cling infection. The researchers specifically say most telemetry resembled ordinary opportunistic probing, while only a subset downloaded the Cling malware. That distinction should be preserved when describing the campaign. The spike in CVE-2021-35394 activity is broader than the Cling botnet itself.

This is useful operationally because seeing an exploit attempt does not automatically prove compromise. Defenders should correlate attempted exploitation with subsequent malware downloads, process behavior, persistence artifacts or STUN anomalies before declaring an infection. Conversely, simply blocking one Cling loader address does not solve the underlying vulnerability because other threat actors continue scanning for the same Realtek flaw.

The broader attack chain can be summarized as: Internet-exposed IoT device → CVE-2021-35394 or another embedded RCE exploited → shell command downloads Cling → malware installs persistence → infected device scans for more victims → STUN infrastructure discovers NAT mappings → custom registration announces the bot → C2 commands arrive encoded in STUN transaction IDs → compromised device becomes a proxy, tunnel, scanner or DDoS node.

The most interesting security lesson is not that attackers found another way to infect routers. They have been doing that since routers had enough memory to regret it.

The more important development is that Cling deliberately shapes its command traffic to look like something defenders expect to see. It uses a standard NAT-traversal protocol, communicates with legitimate public STUN infrastructure, and makes malicious commands appear to originate from a high-reputation service.

That weakens simplistic controls based on domain reputation, IP reputation or the assumption that a common protocol is automatically benign.

The right defensive question is increasingly not:

“Is this protocol allowed?”

It is:

“Does this device have a legitimate reason to use this protocol in this way?”

For a video-conferencing workstation, STUN may be routine.

For a DVR sending all-zero transaction IDs every five seconds and suddenly scanning the IPv4 Internet, it is something else entirely.

That contextual difference is where Cling becomes detectable.

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

Source: Realtek Jungle SDK Exploit Attempts Deliver Cling Botnet With STUN-Based C2 via The Hacker News — published 05 Oct 2026.