A Cisco SD-WAN Vulnerability to Malware Was Used to Install Malware That Steals Encryption Keys

The Cisco SD-WAN vulnerability to malware let an attacker install code capable of copying encryption keys, and it had already been fixed when Cisco Talos published its analysis on 28 October 2026 [1]. Even so, the case leaves open a question that no update answers: what happened to those keys while the network's controller was in the attacker's hands.

That is the core of this story. The goal was not only to get into the system that governs the network between sites, but to take what protects the traffic flowing across it. That is why the patch closes the door but does not clarify what happened before.

Talos places the entry point in an authentication flaw in the SD-WAN controller

SD-WAN stands for software-defined wide area network. In Cisco's Catalyst solution, that central point is made up of several control components. According to Cisco Talos, an actor it calls UAT-11473, and which it describes as a highly sophisticated advanced persistent threat (APT), exploited CVE-2026-20127, an authentication bypass flaw in Catalyst Controller instances, to get around access control and enter the affected systems without authorization [1]. This Cisco Catalyst SD-WAN vulnerability is the starting point of the whole episode.

The Hacker News, which reports on the Talos analysis, adds context on how serious the flaw is. According to that outlet, CVE-2026-20127 has a CVSS score of 10.0 and lets a remote attacker without credentials obtain administrative privileges on those control systems [2]. The same outlet says Cisco fixed it in February, that it affects the Controller, the Manager and the Validator regardless of configuration, both in on-premises installations and in deployments hosted in Cisco's cloud, and that the vendor acknowledges limited exploitation and offers no workaround other than the patch [2].

So far, the account matches many security bulletins: a serious flaw and an available update. What sets this case apart is what the attacker installed afterwards.

KeyDrift malware is designed to harvest keys

Talos describes KeyDrift as a custom-built malware framework made up of several pieces. Some collect sensitive key material, others work as a backdoor and others act as intermediate command-and-control (C2) servers [1]. The lab assesses, with high confidence, that the whole set aims to maintain long-term persistent access and to extract that key material in an automated way [1]. As encryption key theft malware, it targets the very thing that protects inter-site traffic.

To understand why this matters, it helps to know how keys circulate in this architecture. The Hacker News explains that, in Cisco's traditional scheme, each SD-WAN router periodically generates a key to encrypt its traffic and sends it to the Controller, which distributes it to the other routers [2]. According to the same outlet, a KeyDrift component called LittleFilch hooks into the process that handles those control connections and reads the messages once they are decrypted; from a preset list of routers, it extracts their addresses and a field that Talos identifies as the AES key material the controller distributes [2].

The main module, PolyFlame, resides in memory inside that legitimate process, can execute commands and read or write files, and is built to receive instructions disguised within the control traffic itself, so the samples analyzed contained no fixed server address, according to The Hacker News [2]. Talos adds that the variations observed in the modules suggest the framework is still under active development [1].

The difference from a ransomware attack is fundamental. Service disruption and the possible extraction of keys pose different problems. The sources do not describe which symptoms would allow the copying of a key to be detected. According to The Hacker News, KeyDrift is designed to copy the keys that encrypt traffic between sites and store them for later use.

What the sources do not clarify: when it happened and whether keys left

Talos classes the activity as historical, and The Hacker News stresses that the lab does not specify when it took place or whether any keys were actually sent out [2]. The same outlet details that LittleFilch encrypts what it collects, stores it in a file and can forward it to an address listed in a configuration file that is deleted after being read; Talos was unable to recover that file [2]. With what has been published, there is no data on the real extent of the exfiltration.

It is also worth not mixing timelines. According to The Hacker News, when Cisco disclosed the flaw in February, Talos attributed its exploitation to a different activity cluster, UAT-8616, which went back to at least 2023 [2]. The outlet notes that Talos does not explain how that cluster relates to UAT-11473 [2], so there is no basis for joining the two episodes into a single story.

Something similar applies to attribution. Talos holds, with high confidence, that UAT-11473's infrastructure overlaps to a large extent with the covert access network associated with Volt Typhoon [1], but The Hacker News clarifies that the lab does not claim it is the same group [2].

The targets Talos observed were space and satellite services, defense and aerospace technology, and public policy research [1]. Talos lists those sectors without specifying whether the affected entities included industrial companies. That they are not documented does not mean the risk does not exist for them, but it does require not overstating it.

The SD-WAN controller concentrates trust between sites and plants

What follows is a reading by the Hodeitek team, not a fact from the sources. The analysis of this case centers on the compromise of the Cisco SD-WAN control plane. In Cisco SD-WAN's traditional key exchange, the Controller distributes among the routers the keys it receives, as The Hacker News describes [2]. The possible impact of a compromised controller should be assessed with its role in key distribution in mind.

For an industrial SME with several plants, this has a practical consequence. It is worth including key protection in the security assessment of encryption between sites. If key exposure is suspected, it is worth working out with the vendor which traffic could be affected, including production traffic when it shares infrastructure.

Hence it makes sense to treat the network's control plane as a critical asset, on a par with an industrial controller: inventory, restricted administrative access, logs stored outside the device itself and a review of which industrial traffic actually runs over the SD-WAN. Reviewing the segmentation between IT and OT is part of industrial OT security.

CISA has treated exposure of Cisco SD-WAN systems as an emergency

The US cybersecurity agency, CISA, published emergency directive ED 26-03 on 25 February 2026, titled "Mitigate Vulnerabilities in Cisco SD-WAN Systems" and updated on 11 March 2026 [3]. It is an instrument that section 3553(h) of title 44 of the United States Code reserves for threats that pose a substantial risk to the information security of federal agencies [3].

In the directive, CISA says it is aware of ongoing exploitation of these systems and mentions CVE-2026-20127 alongside CVE-2022-20775, a path traversal flaw that allows privilege escalation [3]. The directive binds federal civilian agencies and does not apply to contractors [3], but its mere existence indicates how CISA assessed the exposure.

It is not an isolated case. The pattern repeats: the device that connects the network is also the most attractive to anyone who wants to stay inside.

Patching closes the door but does not say who came in before

Since the flaw was fixed in February and Talos describes the activity as historical, the useful question for a company is no longer just whether it has updated, but what happened before it did. The Hacker News points out that Talos's recommendations do not clarify whether updating removes KeyDrift from an already compromised device or whether keys must be replaced, and that Cisco's February remediation guidance warns that access obtained before the update may remain active [2]. The same outlet recalls that blocking access to certain ports does not remove malware that is already installed [2].

As guidance, to be confirmed with the vendor, a reasonable review includes these points:

• Check that the Controller, the Manager and the Validator are on a fixed version according to Cisco's advisory [2].
• Look for administrative access from unknown addresses; The Hacker News reports that Cisco advises reviewing the authentication log for logins with the internal account vmanage-admin from unrecognized IP addresses [2].
• At any sign of compromise, open an incident response process; Talos suggests relying on Cisco's Technical Assistance Center (TAC) [2].
• Decide with Cisco whether to rotate keys or rebuild the control plane. For federal agencies with a compromised root account, CISA requires deploying new instances from patched images and migrating the routers to them [3].

The idea worth keeping is simple: when the flaw affects the system that manages encryption between sites, updating is necessary but not sufficient. You need to check whether the controller was compromised and which keys may have been exposed. Centralized logging and continuous monitoring are worth considering to support that check, as is evaluating whether a managed SOC and detection and response (MDR) service fits the needs of your team and your OT security strategy.