SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

Cling botnet poses as STUN traffic, but gets in through flaws catalogued up to 4,175 days ago

Nozomi Networks and FortiGuard describe a Linux botnet that sends commands in packets shaped like STUN, the protocol behind video calls. Its way in is old: the oldest of 32 flaws across the two reports has a CVE record from 1 May 2015, 4,175 days before 5 October 2026.

By Parminder Kumar Sharma · · 20 min read

A small router and a small CCTV recorder on a bare shelf in a cupboard, with a laptop in front showing an empty list of blank rows and one hollow slot.

The oldest door is 4,175 days old

On 5 October 2026 the oldest CVE record behind the Cling botnet was 4,175 days old. CVE-2014-8361, a Realtek SDK flaw, was published on 1 May 2015 (CVE.org and NVD records; age computed to 5 October 2026). It is one of 32 distinct flaws that two vendor reports tie to this botnet, as entry points or as exploits it carries for self-spread. The flaw at the centre of the spike that Nozomi Networks measured, CVE-2021-35394, has been in CISA's Known Exploited Vulnerabilities (KEV) catalogue since 10 December 2021: 1,760 days.

The headline is the disguise. Nozomi Networks Labs, in a post dated 1 October 2026, says the malware it calls Cling turns ordinary STUN behaviour into a command channel, so that its traffic can resemble legitimate NAT traversal. STUN is the protocol that helps video calls reach people behind home and office routers. FortiGuard Labs, on 5 October 2026, calls what looks like the same family ClingSTUN and describes a back-connect proxy. Both are vendor research, from companies that sell detection and monitoring, and both are worth reading in full.

What the number does establish is narrower and more useful. The disguise is the late stage of an infection. The early stage is an exposed edge device with a flaw that has had a public record for years, and that is the part a defender can still control. This briefing separates what the two vendors state from what they leave open, works through the flaw lists, and ends with a checklist in the order worth doing. State checked between about 16:45 and 17:05 BST on 5 October 2026.

Two reports, one family? Compare, do not assume

The names differ, Cling and ClingSTUN, so the first test is whether the two vendors describe the same thing. The overlaps are strong. Both report hidden copies of the malware named .cling in two locations, appended to the same three init files so that it runs at boot. Both describe STUN Binding Requests to public servers, a registration step that sends mapped ports to those same servers, and listening for operator packets. And every one of the 13 servers on Nozomi's list is among the 24 that FortiGuard prints (FortiGuard says its third generation uses 13 but does not say which).

Twelve-row comparison of the Nozomi (1 October 2026) and FortiGuard (5 October 2026) reports. Four rows agree: persistence files, STUN servers, registration, and no victim counts. Six differ: name and sample, way in, spread exploits, extras, how the operator learns ports, and commands. Two are reported by one vendor only: the transaction ID and the Google-looking source address.
Drawn from the Nozomi Networks Labs post of 1 October 2026 and the FortiGuard Labs post of 5 October 2026. Row classification is this site's reading.

The differences are as informative as the overlaps, and they mean the two vendors did not analyse the same build.

  • The spread lists differ by one each. Each report lists seven hard-coded exploits for self-spread, and six are shared. Nozomi's seventh is an Eir D1000 flaw, CVE-2016-10372. FortiGuard's seventh is a KGUARD DVR flaw, CVE-2026-87827, whose CVE record was published on 9 September 2026.
  • Each reports behaviour the other does not. Nozomi describes replacing the wget program with a copy of the malware, so that any later wget call restarts it. FortiGuard describes killing the watchdog timer and rival processes, and hiding the malware's process entry.
  • One answers what the other leaves open. FortiGuard says it could not verify how the operator learns where to reach a bot behind a NAT. Nozomi tested exactly that: it advertised different ports to different servers and, several hours later, a port it had given to only one server received commands. It read that server as controlled by, or colluding with, the operator. Nozomi does not say who owns it.
  • Dating is thin on both sides. FortiGuard describes three periods of activity with different download sources; the first lasted two days; it gives no dates. Nozomi gives no start date in its prose, and its chart is the only timeline.

This site's reading: most likely one family, perhaps one operator's changing builds. That is inference. Neither vendor says it compared the other's sample, and this site has not either. For defence, treat Cling and ClingSTUN as one family. For evidence, treat them as two samples.

A spike, measured by one vendor's sensors

Nozomi's text says it saw a spike in attempts to exploit CVE-2021-35394 in anonymised telemetry from sensors in its customers' networks, that most of the hits looked like opportunistic probing, and that a subset led to a botnet. It gives no start date in words. The Hacker News reports the spike as starting around 5 September 2026. That is a reading of Nozomi's Figure 1, whose horizontal axis shows month and day with no year. In that chart the first small bars appear at about 5 September and the tallest, near 175 on a vertical axis with no unit label, at about 6 September. The chart's legend carries 14 country codes, one of them GB. The post does not say whether the codes are the source or the target of the hits, and it gives no UK figure.

Counting from 5 September, Nozomi's post came 26 days later (1 October) and FortiGuard's came 30 days later (5 October). Nozomi's detection rule carries a date field of 17 September 2026: 12 days after the spike began and 14 days before the post. A spike in attempts is not a spike in infections. By Nozomi's own account most of the hits were ordinary probing.

What STUN is, and where the disguise leaks

STUN, Session Traversal Utilities for NAT, is defined in RFC 8489 (February 2020). It lets a device behind a NAT ask a public server what address and port the outside world sees. The device sends a Binding Request, the server copies the source address into its response, and the device learns its own mapping. Repeated requests also keep a NAT binding alive. The RFC's abstract is plain that STUN "is not a NAT traversal solution by itself": it is a tool that other protocols build on.

Three details of the RFC matter here. The transaction ID in the 20-byte header is a 96-bit number that MUST be cryptographically random, and a response MUST carry the same ID as its request. A basic server SHOULD NOT authenticate requests, because checking credentials costs more than answering them. And the default port is 3478 over UDP and TCP, with 5349 for TLS and DTLS.

Two four-step flows. Left, ordinary STUN under RFC 8489: a Binding Request with a random 96-bit transaction ID, an unauthenticated public server, a response that echoes the ID and the public address, and a client that learns its mapping. Right, Cling per Nozomi: all-zero IDs to 13 servers every 5 seconds, a server that does not echo, a non-STUN registration datagram, and commands in the ID field with a Google-looking source.
Drawn from RFC 8489 and the Nozomi Networks Labs post of 1 October 2026. The spoofing explanation is Nozomi's inference.

Against that baseline Nozomi names its tells. The sample sends every Binding Request with a transaction ID of all zeros. One of the 13 servers answers with an all-zero ID instead of echoing the request. And the sample sends a non-STUN registration datagram, carrying its mapped ports and a tag for how it was infected, to every server on its list; conforming servers ignore it. Operator commands then arrive as packets shaped like Binding Success Responses, with the command packed into the 12-byte transaction ID field.

Nozomi lists eight commands: execute a payload, scan and exploit, stop scanning, start and stop a TCP tunnel, relay a proxy, stop the proxy, and flood a target for a set time. Over several days it observed instructions to spread and flood commands aimed at four targets, which it describes as a South Korean internet provider, a US university cluster and two servers it labels as Minecraft. FortiGuard calls the whole thing a back-connect proxy backdoor and does not mention floods.

The most pointed detail is where the commands appeared to come from. Nozomi says the packets carrying them showed a source address that the name stun.l.google.com resolves to. It says it knows of no legitimate way to make a STUN server relay a chosen transaction ID, and that the most likely explanation is source address spoofing from a network that does not validate source addresses, supported by a consistent difference in IP TTL values between genuine replies and command packets. That is Nozomi's inference, labelled as the most likely one. It does not say Google's service was involved, compromised or at fault, and neither does this briefing.

Allowing STUN allows whoever speaks it

A firewall rule that permits a protocol by name permits whoever speaks it. The RFC makes that plain: a basic STUN server does not authenticate, so any host can send it a Binding Request, and any host that can forge a source address can send packets shaped like a reply. Cling does not break into a trusted channel. It uses an open one.

An address is no better as a label than the protocol is. On UDP a source address is a claim, not an identity. Nozomi points at the standard control, ingress filtering under BCP 38 (RFC 2827), and RFC 8489 itself cites source address filtering against reflector abuse. But that control belongs to the network the spoofed packets leave from, not to the organisation receiving them. A rule that waves through traffic from Google's STUN address is trusting the one field an attacker on the right network can write. Nozomi's own conclusion is that reputation alone is not enough when malware shapes its traffic around legitimate infrastructure.

The opposite error is on the record too. FortiGuard warns that the public STUN servers "should not be automatically classified as attacker-controlled infrastructure", and that defenders should judge STUN activity alongside process behaviour, unexpected UDP connections and recurring keepalive traffic. Nozomi singled out one server of its 13 by experiment, and says all 13, the implicated one included, had a clean reputation on VirusTotal at the time of writing, and that most appear on public lists. So neither "STUN is safe" nor "STUN servers are bad" survives. The unit of judgement is the behaviour of the device on your network.

Port-based rules are no safer. Of Nozomi's 13 servers, 12 are listed on the RFC's default port and one, Google's, on a different one. A rule written around the default port covers twelve and misses the one with the best-known name.

Thirty-two flaws: the count, and what it hides

SecurityWeek's headline says "dozens of flaws", so the first job is to count them and show the working. The table de-duplicates by CVE identifier across the two reports.

Counting the CVEs across both reports. Derived by this site from the two posts; the CVE lists are in each vendor's own tables.

  1. Set
    Nozomi: entry flaw plus embedded exploits
    Count
    8
    Working
    1 (CVE-2021-35394) plus 7 hard-coded
  2. Set
    FortiGuard: entry points
    Count
    24
    Working
    12 vendors; Tenda 7, D-Link 6
  3. Set
    FortiGuard: hard-coded for spread
    Count
    7
    Working
    None of them in the 24
  4. Set
    FortiGuard total
    Count
    31
    Working
    24 plus 7
  5. Set
    In both reports
    Count
    7
    Working
    CVE-2021-35394 and six of the seven spread exploits
  6. Set
    Only in Nozomi
    Count
    1
    Working
    CVE-2016-10372 (Eir D1000)
  7. Set
    Only in FortiGuard
    Count
    24
    Working
    31 minus 7; includes KGUARD CVE-2026-87827
  8. Set
    Distinct CVEs across both
    Count
    32
    Working
    8 plus 31 minus 7, or 31 plus 1

Counted by the vendor names the reports use, there are 20. FortiGuard names 12 vendors for entry points and 7 for spread, with Realtek in both, which makes 18. Nozomi adds Eir and FiberHome, which makes 20, or 19 if FiberHome and China Mobile, which Nozomi attaches to a single CVE, are treated as one. Two names carry 13 of the 32 CVEs: Tenda has 7 and D-Link has 6.

The list is not only home routers. It includes Ivanti Connect Secure and Policy Secure gateways, both of whose KEV entries CISA marks as used in ransomware campaigns. It includes Linear eMerge E3-Series, an access-control system for which CISA published an industrial control systems advisory that lists Commercial Facilities as the sector. It includes Lantronix EDS5000, which the CVE record ties to a CISA ICS advisory, and Sunhillo SureLine, from a vendor whose own site presents radar and ADS-B surveillance-data products. And it includes CCTV recorders and cameras from MVPower, TBK, KGUARD and AVTECH.

Timeline of 32 CVE records by publication date, 2015 to September 2026. Ten dots are filled for CISA KEV listing and 22 hollow. A line at 29 April 2024 splits 22 records before from 10 after. Dashed bars show the Linksys record issued June 2025 for a flaw exploited in February 2014, and the KGUARD record issued September 2026 for a flaw written up in July 2021. The oldest record is CVE-2014-8361, 1 May 2015.
Drawn from CVE.org records, CISA KEV version 2026.10.04, a SANS ISC diary of 13 February 2014 and a Netlab 360 post of 1 July 2021. Ages are derived.

CISA's catalogue (version 2026.10.04, released 4 October 2026 at 18:52 UTC, 1,734 entries, read at about 16:45 BST and again at about 17:05 BST on 5 October 2026) lists 10 of the 32. The other 22, 69 per cent, are not in it. A patch list built from KEV alone would have missed six of FortiGuard's seven spread exploits, Nozomi's Eir flaw, and all seven Tenda records. CISA can add entries at any time, so this is a state to re-check, not a fixed fact.

The ten of the 32 that CISA lists, from the KEV catalogue version 2026.10.04 (read 5 October 2026).

  1. CVE
    CVE-2021-35394
    Product as CISA names it
    Realtek Jungle SDK
    Added to KEV
    10 Dec 2021
  2. CVE
    CVE-2023-1389
    Product as CISA names it
    TP-Link Archer AX21
    Added to KEV
    1 May 2023
  3. CVE
    CVE-2019-17621
    Product as CISA names it
    D-Link DIR-859 Router
    Added to KEV
    29 Jun 2023
  4. CVE
    CVE-2014-8361
    Product as CISA names it
    Realtek SDK
    Added to KEV
    18 Sep 2023
  5. CVE
    CVE-2023-46805
    Product as CISA names it
    Ivanti Connect Secure and Policy Secure
    Added to KEV
    10 Jan 2024
  6. CVE
    CVE-2024-21887
    Product as CISA names it
    Ivanti Connect Secure and Policy Secure
    Added to KEV
    10 Jan 2024
  7. CVE
    CVE-2021-36380
    Product as CISA names it
    Sunhillo SureLine
    Added to KEV
    5 Mar 2024
  8. CVE
    CVE-2019-7256
    Product as CISA names it
    Nice Linear eMerge E3-Series
    Added to KEV
    25 Mar 2024
  9. CVE
    CVE-2022-37055
    Product as CISA names it
    D-Link Routers
    Added to KEV
    8 Dec 2025
  10. CVE
    CVE-2025-67038
    Product as CISA names it
    Lantronix EDS5000
    Added to KEV
    23 Jun 2026

Several of the entries tell defenders to stop using the product if no mitigation exists. For CVE-2022-37055, CISA says the affected products could be end-of-life and that users should discontinue use. The most recent of the ten, Lantronix CVE-2025-67038, was added on 23 June 2026 with a due date of 26 June, which is the three-day pattern covered in an earlier briefing.

Scores do not rank these for you. For CVE-2021-35394, NIST (the NVD primary score) and CISA-ADP both give 9.8; the CVE record's own assigner, MITRE, gives none. For five 2024 Tenda records that name the same exeCommand component, CISA-ADP's scores are 8.8, 8.8, 3.8, 8.6 and 8.8. A botnet that exploits all five does not read the scores. On 5 October 2026 four of the 32 NVD records were still unanalysed: three marked Deferred (TBK, Linksys and KGUARD) and one Awaiting Analysis (MeiG).

A CVE record date is also a floor, not the age of the flaw. Three records in these lists were issued years after exploitation began. The Linksys record, CVE-2025-34037, was published on 24 June 2025; its own text says a worm called TheMoon exploited the flaw in 2014, and a SANS ISC diary dated 13 February 2014 summarises that worm, 4,149 days before the record. By that measure the Linksys flaw is the oldest on the list that this site could date to a public source: 4,617 days of public history at 5 October 2026. The KGUARD record, CVE-2026-87827, was published on 9 September 2026, 26 days before this briefing; its text says the affected firmware dates from 2016, and Netlab 360 wrote up its exploitation on 1 July 2021, 1,896 days earlier. The MVPower record, CVE-2016-20016, was published on 19 October 2022 and says the flaw was exploited from 2017. A scanner that ranks by CVE age would call the KGUARD flaw the newest on the list. It is not new.

Realtek's advisory shows why this class of flaw lingers. Realtek supplies the SDK, not the router. Its advisory, released 15 August 2021, covers CVE-2021-35392 to CVE-2021-35395 and lists patches for each SDK series, dated June and July 2021. A patch for an SDK is not a patch for a router: each device maker has to build and ship new firmware, and Nozomi notes that such devices often do not receive updates and stay vulnerable for years. The advisory also frames the effect as denial of service, though its own entry for CVE-2021-35394 names arbitrary command injection and NIST scores it 9.8. A soft summary is not a control.

What this means for a UK estate

Neither report names a UK victim, so what follows is inference from the device lists, labelled as such. The lists run from consumer routers to branch-office and building equipment. Branch and home-office sites, contractor-installed CCTV, door-access panels, serial and device servers and VPN gateways are where a UK organisation is most likely to hold a device that nobody has on a list. These brands are sold in many markets; this site has not established UK install bases for any of them.

The UK's product security regime, the Product Security and Telecommunications Infrastructure Act 2022 and its 2023 Regulations, came into force on 29 April 2024 (OPSS guidance on GOV.UK). It requires makers of consumer connectable products to ban universal default passwords, publish a contact for vulnerability reports, and publish a defined support period, which the Regulations define as the minimum length of time, with an end date, for which security updates will be provided. The Schedule 1 paragraph this site read requires the period to be published and sets no minimum length. Scope runs through section 54 of the Act: products made available to UK consumers, and products made available to businesses where identical products meet the consumer test. A business can be covered when it buys the same box a consumer could. A recorder sold only to installers may not be (inference).

Of the 32 CVE records, 22 were published before 29 April 2024, and a device that was vulnerable on the day its CVE was published was, in the ordinary case, already on sale; that is inference. Nothing in the Act, the Regulations or OPSS's guidance that this site read obliges a maker to patch a unit already sold. PSTI changes what new products ship with. It does not clean up the cupboard.

The NCSC's alert on internet-exposed systems and edge devices, published on 27 August 2026 and updated on 7 September 2026, is aimed at operators of operational technology but has a section for everyone else. Its list for other organisations reads like a checklist for this botnet: keep an accurate inventory of internet-facing systems, understand the function and data flows of edge devices, apply vendor security updates promptly, retire end-of-life equipment, disable insecure management protocols such as SNMP v1, SNMP v2 and Telnet, and monitor for unexpected configuration changes or outbound connections. For boundary devices it says to keep them within vendor support, replace them before end of life, and manage them only from a segregated management network that is not connected to the internet. A joint CISA, FBI and NCSC fact sheet of 5 February 2026 says the same of end-of-support edge devices: inventory them with their support timelines, and replace them.

The NCSC also asks every organisation to register for Early Warning, its free alert service, as its page describes it on 5 October 2026. Sign-up takes the organisation's public IP addresses and domain names, so a branch office on its own broadband line is covered only if its address is on the list (inference from the sign-up requirements). The service says it should not be the only layer of defence. For a related case of a router with no fix and no end-of-life statement, see an earlier briefing.

Stated and not stated

What the two reports state and what they leave open, checked 5 October 2026 against the Nozomi post of 1 October and the FortiGuard post of 5 October.

  1. Question
    How many devices are infected
    Stated
    Nozomi: a spike in attempts on its own sensors, and a subset that delivered Cling
    Not stated
    Any count of infected devices, victims or networks, in either report
  2. Question
    When it started
    Stated
    Nozomi's chart: first bars about 5 September (this site's reading). FortiGuard: three periods, the first lasting two days
    Not stated
    A date for the first infection, the first sample, or any of FortiGuard's periods
  3. Question
    Who runs it
    Stated
    One of the 13 servers behaves as if tailored to the bot; commands reached a port advertised only to it
    Not stated
    Who owns that server, any attribution, or the operator's identity
  4. Question
    Whether the traffic is hidden
    Stated
    Nozomi: can resemble NAT traversal. FortiGuard: blends with VoIP and WebRTC
    Not stated
    That it is undetectable: Nozomi lists four tells, three on the network and one on the host
  5. Question
    Whether STUN command traffic is new
    Stated
    Nozomi: not a new propagation technique; earlier malware used STUN to learn its public address
    Not stated
    Either vendor claiming that STUN-carried command traffic is a first
  6. Question
    Google's role
    Stated
    Command packets appeared to come from an address Google's STUN name resolves to; Nozomi's likely explanation is spoofing
    Not stated
    Any involvement, compromise or fault on Google's side
  7. Question
    UK exposure
    Stated
    Nozomi's chart legend includes the code GB among 14
    Not stated
    Any UK victim, any UK count, or what the codes mean
  8. Question
    Same family
    Stated
    Shared artefact names, init files and server list
    Not stated
    Either vendor saying it compared the other's sample

What to do, in the order worth doing

Take this with you

A UK security lead's order of work

  • Build the list first. Find every router, cellular gateway, DVR or NVR, access-control panel, serial or device server and VPN gateway that answers on a public address or exposes a management page, including branch, home-office and contractor-installed kit. Register the public addresses with NCSC Early Warning.
  • Beside each entry write the vendor's support end date, or unknown. Treat unknown as past end of support until the vendor says otherwise.
  • Retire end-of-life models first, starting with any reachable from the internet. For several of the flaws in these reports CISA's own wording is to apply mitigations or discontinue use if there are none.
  • Patch what is patchable, internet-reachable devices first. Use KEV as a floor, not the whole list: 22 of the 32 flaws are not in it. For white-label gear, find the firmware the actual maker ships, because a fix in an SDK is not a fix in the router until the maker ships it. Take management pages off the internet and onto a segregated management network.
  • Block outbound STUN to the public internet from device VLANs unless a service on that VLAN needs it. This is this site's judgement, not a vendor instruction. It is likely to break softphones, video calls and WebRTC, and may break cameras that use peer-to-peer viewing, so pilot it on one VLAN. Write the rule at the VLAN's egress, not around one port number, because one of Nozomi's 13 servers is on a different port from the other 12.
  • Give IoT and camera VLANs an egress allow-list: default deny outbound, then allow only the DNS, time and vendor cloud services each device type needs. In both reports the command path starts with the device reaching out; take away the reaching out and the pinholes the commands return through are never opened (inference from the two descriptions).
  • Monitor for the published tells. On devices that give telemetry: new hidden executables, edits to inittab, rcS or rc.boot, and a replaced wget with companion files. On the network: a steady rhythm of short-interval Binding Requests with all-zero transaction IDs, non-STUN datagrams sent to STUN servers, and outbound UDP from a device that has never made any. Most embedded devices have no host telemetry, so the network is often the only sensor. Do not put the public STUN servers on a malware blocklist: FortiGuard warns against it.
  • Replace rather than clean. Both reports describe persistence that survives a reboot, and Nozomi describes a replaced system program. On a router or DVR with no support, a reset may or may not remove the implant, you cannot verify it without forensic tooling the device does not have, and the flaw that let it in stays open unless the device is updated or retired. This is judgement, and the cost of a replacement unit is usually lower than the cost of that uncertainty.

The question the number leaves

The disguise took a vendor's sensors, a controlled experiment and a Google-looking source address to expose. The doors took a public database. If a router at one of your branch sites were compromised tonight and produced nothing but packets that looked like a video call, which list in your organisation would tell you the router was there?

Key facts

Sources

  1. PrimaryA STUNning Disguise: Cling Malware Masquerades as Google, 1 October 2026. Read in full: the C2 design, the 13 servers, the experiment, the 8 commands, persistence, indicators and the Figure 1 chart.Nozomi Networks Labsaccessed 2026-10-05
  2. PrimaryClingSTUN Linux Backdoor Abuses Public STUN Infrastructure, 5 October 2026. Read in full: three periods, 24 entry-point CVEs, 7 spread exploits, persistence, 24 then 13 STUN endpoints.FortiGuard Labs (Fortinet)accessed 2026-10-05
  3. PrimaryRFC 8489, Session Traversal Utilities for NAT (STUN), February 2020. Used for what STUN is, the transaction ID rule, server authentication and the default port.IETFaccessed 2026-10-05
  4. PrimaryRFC 2827 (BCP 38), Network Ingress Filtering. Used for the source address spoofing control Nozomi cites.IETFaccessed 2026-10-05
  5. PrimaryKnown Exploited Vulnerabilities catalogue, version 2026.10.04, 1,734 entries. Used for which of the 32 CVEs are listed, the dates added and the required actions.CISAaccessed 2026-10-05
  6. PrimaryNVD record for CVE-2014-8361, the oldest CVE record in the lists (published 1 May 2015). The other 31 records were read through the NVD API and CVE.org.NIST NVDaccessed 2026-10-05
  7. PrimaryNVD record for CVE-2021-35394, the Realtek Jungle SDK flaw behind the spike: NIST and CISA-ADP scores of 9.8, KEV date.NIST NVDaccessed 2026-10-05
  8. PrimaryCVE record for the Linksys flaw (published 24 June 2025), whose text says a worm exploited it in 2014.CVE Programaccessed 2026-10-05
  9. PrimaryCVE record for the KGUARD DVR flaw (published 9 September 2026): firmware from 2016, earlier botnet exploitation.CVE Programaccessed 2026-10-05
  10. PrimaryCVE record for the MVPower DVR flaw (published 19 October 2022): exploited 2017 through 2022.CVE Programaccessed 2026-10-05
  11. PrimaryRealtek AP-Router SDK Advisory for CVE-2021-35392 to CVE-2021-35395, 15 August 2021: affected SDK series and patch files.Realtek Semiconductoraccessed 2026-10-05
  12. PrimaryICS advisory ICSA-24-065-01 for Nice Linear eMerge E3-Series, 5 March 2024: sector listed as Commercial Facilities.CISAaccessed 2026-10-05
  13. PrimarySunhillo field bulletin FB011 on SureLine, and the vendor's own product menu (radar and ADS-B surveillance data).Sunhilloaccessed 2026-10-05
  14. PrimaryAlert on disruptive cyber activity and internet-exposed systems and edge devices, published 27 August 2026, updated 7 September 2026. Used for the actions for non-OT organisations.NCSCaccessed 2026-10-05
  15. PrimaryReducing the Attack Surface for End-of-Support Edge Devices, joint fact sheet, 5 February 2026.CISA, FBI and NCSCaccessed 2026-10-05
  16. PrimaryEarly Warning service page: free for UK organisations, sign-up by public IP addresses and domain names.NCSCaccessed 2026-10-05
  17. PrimaryRegulations: consumer connectable product security. In force 29 April 2024; the three security requirements; OPSS as enforcer.GOV.UK (OPSS)accessed 2026-10-05
  18. PrimaryProduct Security and Telecommunications Infrastructure Act 2022, section 54: meaning of UK consumer connectable product.legislation.gov.ukaccessed 2026-10-05
  19. PrimaryPSTI (Security Requirements for Relevant Connectable Products) Regulations 2023: commencement and the defined support period.legislation.gov.ukaccessed 2026-10-05
  20. Reported byLinksys Worm TheMoon summary, 13 February 2014. Used only to date the 2014 exploitation cited in the Linksys CVE record.SANS Internet Storm Centeraccessed 2026-10-05
  21. Reported byMirai_ptea Botnet is Exploiting Undisclosed KGUARD DVR Vulnerability, 1 July 2021. Used only to date the earlier write-up cited in the KGUARD CVE record.Netlab 360accessed 2026-10-05
  22. Reported byRealtek Jungle SDK Exploit Attempts Deliver Cling Botnet With STUN-Based C2, 5 October 2026. A pointer only; the 5 September start date is its reading of Nozomi's chart.The Hacker Newsaccessed 2026-10-05
  23. Reported byLinux Backdoor Abuses STUN Protocol, Exploits Dozens of Flaws, 5 October 2026. A pointer only.SecurityWeekaccessed 2026-10-05

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.