Cisco SD-WAN: KeyDrift malware steals keys from controllers
The UAT-11473 group exploited CVE-2026-20127 in Cisco Catalyst SD-WAN controllers to install KeyDrift, malware that steals data-plane keys.

ARX News has already covered CVE-2026-76504 in Cisco Catalyst SD-WAN Manager. On 28 October 2026 Cisco Talos described another case on the same platform, involving a different and older vulnerability, CVE-2026-20127: a group Talos tracks as UAT-11473 exploited it to install KeyDrift on SD-WAN controllers. KeyDrift is a malware framework built to stay in the system for a long time and carry off the cryptographic material that protects traffic between sites.
This article draws on three outlets, but the text of The Hacker News was not available: the details come from SecurityWeek and BleepingComputer, both reporting on the Talos analysis. Where the two differ, we say so.
The vulnerability: CVE-2026-20127
- Product: controller components of Cisco Catalyst SD-WAN; according to BleepingComputer, both Controller and Manager are affected.
- Severity: CVSS 10, the maximum.
- Disclosure and fix: February 2026.
- Effect: according to SecurityWeek, a remote attacker without credentials can bypass the peering authentication between control components, gain administrator rights and change the SD-WAN network configuration. BleepingComputer adds that this access allows attackers to add rogue peers.
- Earlier exploitation: here the sources disagree. BleepingComputer writes that another group, UAT-8616, has exploited the flaw as a zero-day since at least 2023. SecurityWeek reports instead that, according to Lumen, Volt Typhoon was exploiting it by late 2025 and kept doing so long after Cisco’s disclosure.
How KeyDrift works
According to Talos, as reported by both outlets, KeyDrift runs inside legitimate control-plane processes, so it sees control messages after the controller has already decrypted them. It has two main components, and Talos saw signs of ongoing development, including new anti-debugging mechanisms and varied ways of impersonating system processes.
PolyFlame is the backdoor. BleepingComputer reports that it runs inside vdaemon processes, deployed through modified service startup scripts and an injector. It can:
- run commands through a TinyShell-style component;
- upload and download files;
- act as an intermediate command-and-control (C2) node, relaying communications between the attacker’s server and other hosts.
LittleFilch intercepts control sessions. According to BleepingComputer, it hooks the SSL_read function to read messages once decrypted and, for a list of predefined edge nodes, extracts IP identifiers and a 32-byte field that Talos believes is AES-256 key material for data-plane IPsec. The collected data is encrypted with RSA, saved to /var/tmp/vdaemon.bin and then sent to the attackers over UDP.
In practice, whoever holds these keys may be able to decrypt traffic between sites protected by the SD-WAN’s IPsec tunnels, provided they can also intercept it. The sources do not say whether this happened.
In MITRE ATT&CK terms, the techniques described map to: T1190 (Exploit Public-Facing Application) for initial access, T1037 (Boot or Logon Initialization Scripts) for the modified startup scripts, T1055 (Process Injection) and T1036 (Masquerading) for running inside vdaemon, T1622 (Debugger Evasion), T1090 (Proxy) for the relay role, T1074 (Data Staged) for the file in /var/tmp, and T1048 (Exfiltration Over Alternative Protocol) for the UDP transfer.
Who is behind it
Talos describes UAT-11473 as a highly sophisticated APT group targeting space and satellite services, defence and aerospace technology, and policy research organisations. According to SecurityWeek, Talos calls the activity “historical” without saying when the attacks took place.
Talos assesses with high confidence that UAT-11473’s infrastructure overlaps considerably with Silent Train, the network of ephemeral chains of compromised devices that Lumen’s Black Lotus Labs attributes to Volt Typhoon. Talos, however, does not say they are the same group, and SecurityWeek points out that Lumen’s report mentions neither KeyDrift nor UAT-11473.
Impact for European and Italian organisations
The victims mentioned are mainly in the United States, in sectors such as defence, space and telecommunications. But the case concerns anyone running Cisco Catalyst SD-WAN: controllers are where the configuration and keys of the entire wide-area network pass through. A compromise is not visible from the branch devices and, if data-plane keys have been stolen, the confidentiality of traffic between sites is no longer guaranteed even after the malware is removed.
For NIS2 entities, and especially for organisations working in defence, aerospace, telecommunications, or healthcare with several facilities connected over SD-WAN, a controller compromise should be treated as a significant incident and assessed for notification to the national CSIRT, which in Italy is CSIRT Italia at ACN.
What to do now
- Check the update: make sure all Catalyst SD-WAN components (Controller and Manager, including disaster recovery environments) have the February 2026 fix for CVE-2026-20127. The sources do not list the versions: refer to the Cisco advisory.
- Apply the hardening guide that Cisco recommends for Catalyst SD-WAN deployments.
- Look for traces of KeyDrift on the controllers:
- the file
/var/tmp/vdaemon.bin; - changes to service startup scripts;
- anomalous or duplicate
vdaemonprocesses; - outbound UDP traffic from the controllers to unknown destinations.
- the file
- Check the peers: review the list of registered peers and recent configuration changes, looking for devices you do not recognise.
- If you find signs of compromise, consider the data-plane keys exposed: rebuild the controllers from clean images, regenerate keys and certificates, preserve evidence before acting and assess your notification obligations.
- Isolate management: controllers must not be reachable from the Internet or from untrusted networks.
How ARXDOME helps
ARX Expose shows which services your organisation exposes on the Internet and which have known vulnerabilities, so you know whether SD-WAN components can be reached from outside. ARX Sentry collects logs from firewalls and other network devices in a central collector, useful for spotting unusual outbound traffic from the controllers. ARX Horizon lets you look up vulnerabilities from the portal and search for indicators of compromise.
Last updated:


