What this is. Opinion + Experience + Fact (35% opinion · 15% experience · 50% fact). Written in collaboration with AI — I discuss, I do not outsource.

A wave note on the Cling botnet. On October 5, 2026, The Hacker News reported exploit attempts against CVE-2021-35394, a critical flaw in Realtek's Jungle SDK, delivering a botnet called Cling. The vendor fix came out on August 15, 2021. A 2021 CVE is not old news: a fix protects the devices that have installed it.

A fix that exists is not yet a fix that is installed (simplified illustration) A timeline from August 15, 2021, when the vendor fix was released, to October 5, 2026, when the Cling botnet was reported. Below it, one bar shows the fix released by the vendor and a second bar shows the fix installed on devices, which stops short of the end: some devices are still on pre-fix firmware. A fix that exists is not yet a fix that is installed. Simplified illustration of the idea — not to scale. Aug 15, 2021Aug 2021 - Dec 2022around Sep 5, 2026Oct 5, 2026 fix released134 million attemptsexploitation spikeCling reported fix released by the vendor fix installed on devices devices still on pre-fix firmware A fix exists when a vendor ships it. It protects when the device installs it.
Dates and the attempt count come from the cited sources; the "fix installed" bar is a concept, not a measurement. Simplified illustration.

On October 5, 2026, The Hacker News reported that exploit attempts against CVE-2021-35394, a critical (CVSS 9.8) flaw in the Realtek Jungle SDK, are delivering a botnet named Cling. (A CVE is a public bug ID. An SDK is the vendor's software kit a device is built on.) Nozomi Networks published the initial analysis, and Fortinet's FortiGuard Labs later reported on it under the name ClingSTUN. The report describes a spike in exploitation attempts around September 5, 2026.

The vendor fix for this flaw is not new. Realtek addressed it on August 15, 2021. That gap, between a fix existing and a fix mattering, is the interesting part, and it is what this post is about.

1. What does the Cling botnet actually do?

Cling turns infected routers, access points and video recorders into remotely controlled proxy nodes. Besides CVE-2021-35394 it carries exploits for several other router and DVR flaws, including some from as far back as 2014, so a device only needs to match one of them. It also establishes persistence and removes competing malware.

The notable design choice is its command channel. Cling sends STUN requests (STUN is a standard used to help devices find their way through NAT, the address translation in most home and office routers) to a hardcoded list of public STUN servers, and the reported commands travel inside the STUN transaction IDs. Nozomi reports that some of that traffic is made to look as if it comes from a Google STUN address. To a casual observer, it resembles ordinary connectivity housekeeping. Defenders have a pattern to work with, though: repeated Binding Requests with all-zero transaction IDs.

▸ First principle. Attackers reuse what still works, and age is not a defense.

2. Why does a bug fixed in 2021 still work in 2026?

The flaw affects Realtek Jungle SDK versions 2.x through 3.4.14B. An SDK is code that many different vendors build into many different products. When the SDK vendor fixes a bug, the fix still has to travel: into each product vendor's firmware build, through that vendor's testing and release, and finally onto each device in someone's home, office or factory. Every one of those hops takes time, and some devices never make the last hop.

The numbers show how long the tail can be. A BleepingComputer report from January 2023 counted 134 million exploit attempts against this one CVE between August 2021 and December 2022. Fast forward to October 2026 and the same CVE is part of a new campaign. I read that as a property of the whole ecosystem, not a verdict on any one company: shipping the fix is the beginning of the journey, and installing it is the end.

▸ First principle. A fix exists when a vendor ships it; it protects when a device installs it.

3. What can a device maker own?

Three things sit squarely with the team that ships the device, and each has an earlier post in this series. First, knowing what is inside: which SDK and library versions each shipped build contains. That is the thread of know what you shipped and your firmware is not just your code. Second, an update path that still reaches devices years after launch, which is the subject of a patch is not a recovery. Third, a record of what each device does, so that unusual behavior stands out instead of blending in.

On that third point, a note on scope. In EmbedIQ, the open framework I work on, each task is a single thread with a table-based state machine and one message queue, and the Observatory records every transition, message and fault. That gives you facts about what a device did. It is a record of device behavior, not a network defense, and it does not replace patching. Board-specific bring-up and drivers remain your work.

▸ First principle. Security is a lifecycle, and the first build is only day one.

The copyable part: a "which fix reached my fleet?" checklist

QuestionWhat "yes" looks likeWho owns it
1. Do we know which SDK and library versions each shipped build contains?A per-build list kept alongside the release, readable in minutesFirmware
2. When an SDK vendor publishes a fix, do we hear about it?A named person watches vendor advisories and public exploited-vulnerability lists for the components we shipFirmware + security
3. Can we tell which devices in the field run a pre-fix build?Each device reports its build version, and the fleet can be filtered by itFirmware + cloud
4. Can an update reach every one of those devices?A tested update path for devices of every age we still supportFirmware
5. Do we have a record of normal device behavior?A baseline of states, messages and faults, so a change stands outFirmware
6. Do devices avoid unnecessary internet exposure?Diagnostic and management services are off or restricted by defaultFirmware + product
7. Who decides when an old CVE becomes a priority again?One named owner and one page of facts ready before it happensProduct lead

Nozomi's own mitigation advice lines up with items 6 and 7 for devices already installed: prioritize patching CVE-2021-35394, restrict inbound access, remove unnecessary internet exposure, and segment networks.

Firmware and product leads: how do you find out which shipped devices still run a pre-fix SDK build?

Next in this thread: what a product team should know on day one about the parts of its firmware it did not write.

Sources

News and analysis: The Hacker News — Realtek Jungle SDK Exploit Attempts Deliver Cling Botnet With STUN-Based C2 (October 5, 2026: CVE-2021-35394, CVSS 9.8; Nozomi Networks analysis; Fortinet FortiGuard Labs report naming ClingSTUN; spike around September 5, 2026; commands in STUN transaction IDs; other router and DVR CVEs including CVE-2014-8361). Industrial Cyber — Cling botnet uses STUN traffic to conceal command-and-control activity (Nozomi mitigation advice and detection signature). SC Media — Cling botnet exploits Realtek SDK flaw, uses STUN for C2. History of the flaw: BleepingComputer — Botnets exploited Realtek SDK critical bug in millions of attacks (January 25, 2023: SDK 2.x through 3.4.14B; fix addressed August 15, 2021; 134 million exploit attempts between August 2021 and December 2022). Component detail: SentinelOne vulnerability database — CVE-2021-35394. The figures are the sources' own; the reading of them, and the design position, are mine.

FAQ

What is the Cling botnet?
Cling is a botnet that, according to The Hacker News on October 5, 2026, spreads through exploit attempts against CVE-2021-35394 in the Realtek Jungle SDK and several other router and DVR flaws. Infected devices become remotely controlled proxy nodes, and commands travel inside STUN transaction IDs.

Was CVE-2021-35394 fixed?
Yes. Realtek addressed it on August 15, 2021, according to BleepingComputer. A fix only protects devices that have installed firmware containing it, which is why a 2021 CVE can still matter in 2026.

Why do old IoT vulnerabilities keep getting exploited?
An SDK flaw is built into many vendors' products, so a fix has to pass through each vendor's firmware release and then reach each device in the field. Devices that never receive the update stay exposed. BleepingComputer counted 134 million exploit attempts against this one CVE between August 2021 and December 2022.

What should device makers do about old vulnerabilities in their SDKs?
Keep a per-build list of the SDK and library versions shipped, watch vendor advisories, be able to tell which devices run pre-fix builds, keep an update path that reaches older devices, and keep a record of normal device behavior so unusual patterns stand out.

Labels: Opinion 35% · Experience 15% · Fact 50%. Written in collaboration with AI — I discuss, I do not outsource.

This is a Ritzy Lab wave note. If you ship connected devices and want to compare notes on keeping fixes flowing to the field, the longer story and how I work live on my profile. — Ritesh | ritzylab.com

#EmbeddedSystems #IoTSecurity #Firmware #EmbedIQ