Cisco SD-WAN KeyDrift malware planted via CVE-2026-20127, Talos reports
Cisco Talos reports KeyDrift malware planted on Catalyst SD-WAN control systems via CVE-2026-20127, so upgrade to a fixed release and hunt for compromise.
- Published
- Ecosystem
- Network edgeEnterprise softwareCloud
- Fixed in
- 20.9.8.2, 20.12.5.3, 20.12.6.1, 20.15.4.2, 20.18.2.1
- Exploitation
- Yes, Cisco says it is aware of limited exploitation and Talos reports KeyDrift was planted through the flaw, per The Hacker News
Live scores
CVE-2026-20127- EPSS
- 0.876
very likely to be attacked soon - VEDAS
- 0.978
strong exploit evidence - On CISA KEV
- Yes, since 2026-02-25
- Detection rule
- No public rule yet
Thin horizontal line: the “likely exploited” threshold (EPSS 0.10, VEDAS 0.5). Shaded “no data” areas are periods when cve-scores did not publish.
What happened
According to The Hacker News, Cisco Talos said on October 28 that attackers exploited CVE-2026-20127, a Cisco Catalyst SD-WAN flaw fixed in February, to plant custom malware it calls KeyDrift on the systems that control an SD-WAN network. The outlet reports that Talos calls the attacks historical but does not say when they occurred or whether any keys were sent out. Victims are not named in the source.
The Hacker News reports the flaw has a CVSS score of 10.0 and lets an unauthenticated remote attacker bypass authentication and gain administrative privileges on these control systems. CISA describes CVE-2026-20127 the same way in its Emergency Directive 26-03, issued February 25, 2026, which also lists CVE-2022-20775 as a known exploited vulnerability in these systems.
What KeyDrift does, according to Talos as reported by The Hacker News:
- A component called LittleFilch hooks into the vdaemon process on a compromised Controller, reads decrypted control messages and, for a preset list of edge routers, extracts their IP addresses and a 32-byte field Talos assesses to be AES-256 key material passed between routers.
- LittleFilch encrypts the collected data with RSA, writes it to a file and can send it over UDP to an address in a settings file that it deletes after reading. Talos could not recover that settings file.
- The main module, PolyFlame, runs in memory inside vdaemon as a backdoor or relay and is built to accept commands within SD-WAN control traffic. Analyzed samples had no hardcoded server address.
- Persistence comes mainly through modified runit scripts. On a Validator, a fake aaamgr service runs a packed loader. Talos also reports signs of timestomping.
Attribution, per the same report: Talos tracks the group as UAT-11473 and says it has targeted space and satellite services, defense and aerospace technology, and policy research. Talos assesses with high confidence that its infrastructure overlaps considerably with Silent Train, a network Lumen’s Black Lotus Labs says Volt Typhoon used. Talos does not say UAT-11473 and Volt Typhoon are the same group, and does not say how UAT-11473 relates to UAT-8616, the cluster it reported in February. Separately, Lumen said Volt Typhoon was exploiting CVE-2026-20127 by late 2025 and after disclosure. Lumen does not tie that activity to KeyDrift.
Not confirmed: when the attacks took place, how many organizations were affected, whether any key material was exfiltrated, and whether upgrading removes KeyDrift from an already compromised device.
Am I affected?
According to The Hacker News, CVE-2026-20127 affects the Catalyst SD-WAN Controller (formerly vSmart), Manager (formerly vManage) and Validator (formerly vBond), regardless of configuration. On-premises systems are affected, as are Cisco’s hosted SD-WAN cloud deployments, including the Cisco Managed and FedRAMP environments. Cisco added the Validator to its advisory on June 16.
First fixed releases, as listed by The Hacker News. There is no workaround:
| Release train | First fixed release |
|---|---|
| Earlier than 20.9 | Migrate to a fixed release |
| 20.9 | 20.9.8.2 |
| 20.11 | 20.12.6.1 |
| 20.12 | 20.12.5.3 or 20.12.6.1 |
| 20.13 | 20.15.4.2 |
| 20.14 | 20.15.4.2 |
| 20.15 | 20.15.4.2 |
| 20.16 | 20.18.2.1 |
| 20.18 | 20.18.2.1 |
Releases earlier than 20.9 and the 20.11, 20.13, 20.14 and 20.16 trains have reached end of software maintenance.
What to do now
- Upgrade every Controller, Manager and Validator to a fixed release from the table above (The Hacker News).
- Until you can upgrade, on-premises customers can limit access to ports 22 and 830 to the IP addresses of known controllers and other known systems. Cisco says this worked in a test environment but should be validated in your own network. Blocking the ports does not remove malware already present (The Hacker News).
- Check for exploitation of the flaw: Cisco says to look in /var/log/auth.log for “Accepted publickey for vmanage-admin” entries from unknown IP addresses (The Hacker News).
- Check for KeyDrift artifacts listed by Talos, per The Hacker News:
- a modified run script under etc/sv/sshd/ that starts conf_sshd
- a fake service directory /etc/sv/aaamgr/ on a Validator
- files named aaamgrd, conf_sshd, rsshd, libdssl.so (PolyFlame) and libcommon.so (LittleFilch)
- /tmp/system-vdaemon, /var/tmp/vdaemon.bin and /var/tmp/vdaemon.conf
Talos did not publish file hashes, IP addresses or domains.
- Enable the Talos Snort rules for inbound KeyDrift command-and-control connections: SIDs 67387 through 67416 for Snort 2, which ship disabled by default in the Snort Subscriber rule set (Snort), and 7:44 through 7:73 for Snort 3. Rules 65938 and 65958 cover CVE-2026-20127 itself (The Hacker News).
- If you find signs of compromise, start incident response. Before opening a Cisco TAC case, run request admin-tech on each control component. Cisco’s remediation guide also recommends rescanning those files with the Check Bug Applicability feature for bug CSCws52722, and warns that exploits from before an upgrade may still be in place (The Hacker News).
- US federal civilian agencies that find a root account compromise must report it to CISA and rebuild the control plane from patched images, then migrate edges to the new infrastructure, per CISA ED 26-03.
Whether SD-WAN encryption keys should be replaced after a compromise is not confirmed by the sources.