Attackers used a peering-authentication flaw in Cisco Catalyst SD-WAN to enter controllers, then planted malware inside the process that handles network control traffic. Cisco Talos traced the activity to UAT-11473 and named the framework KeyDrift. Its analysis describes a module that intercepts decrypted traffic and extracts material it assesses as IPsec data-plane keys. For teams running SD-WAN, this is a controller-compromise investigation as well as a patch job.
The October 28 Talos report adds the implant analysis to Cisco advisory CVE-2026-20127, first published in February and updated in October. The Cisco-assigned CVE record also identifies the peering-authentication bypass. Cisco says its PSIRT is aware of limited exploitation. Talos writes, “Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.” These are targeted sectors; use the controller inventory to establish local exposure.
The peering identity reaches NETCONF
Cisco rates the flaw critical, with a CVSS 3.1 base score of 10.0. An unauthenticated remote attacker can send crafted peering requests to an affected control component and log in to a Controller, formerly vSmart, as a privileged internal non-root account. That identity can reach NETCONF and change SD-WAN fabric configuration. Manager, formerly vManage, and Validator, formerly vBond, are also in Cisco’s affected-product scope, regardless of device configuration. Cisco lists on-premises, hosted, Cisco-managed and FedRAMP-hosted control deployments. Cisco identifies the faulty peering-authentication mechanism as the entry point, so use the fixed-release table to plan remediation.
Talos says UAT-11473 installed KeyDrift after exploiting the bypass. Its PolyFlame module ran in the legitimate vdaemon process, where it could inspect in-process control-session state; modified runit service launchers supplied a path back into that process after restart. Talos observed a packed aaamgrd loader on an affected Validator and an sshd launcher that started conf_sshd and rsshd to inject libdssl.so. A separate module, LittleFilch (libcommon.so), hooked SSL_read inside vdaemon, collected identifiers and assessed key material from decrypted control messages, then staged RSA-encrypted records in /var/tmp/vdaemon.bin. Its configuration file /var/tmp/vdaemon.conf was deleted after reading. Talos describes the framework as capable of persistent access and encrypted staging or exfiltration; inspect the named files and service launchers when investigating a suspected intrusion.
Normal peers can hide intrusions
Cisco’s example auth.log entry shows Accepted publickey for vmanage-admin in /var/log/auth.log. Search Controller authentication logs for that marker and compare the originating IP with the configured System IPs in Manager under WebUI > Devices > System IP. Investigate unfamiliar sources against peering history and authorized change records before assigning an actor. Cisco also calls for manual validation of control-connection peering events: compare timestamp with maintenance and change records, public IP with authorized infrastructure, peer System IP with documented topology, and peer type (vmanage, vsmart, vedge, vbond) with the assigned role. Correlate unexpected peers with authentication and user activity.
The implant complicates network-only hunting. Talos found no hardcoded callback address or fixed polling interval in the PolyFlame samples it analyzed; in-band control traffic could carry tasking inside apparently ordinary controller communications. That makes controller logs, authorized-peer inventory and service-file inspection more useful than a hunt for one universal C2 address. Talos assesses with high confidence that UAT-11473 infrastructure substantially overlaps the Volt Typhoon “Silent Train” network. Use that overlap to guide infrastructure triage while assigning activity from local evidence.
Fixed releases and temporary restrictions
Cisco supplies first fixed releases by branch: 20.9.8.2 for 20.9; 20.12.6.1 for 20.11; 20.12.5.3 or 20.12.6.1 for 20.12; 20.15.4.2 for 20.13, 20.14 and 20.15; and 20.18.2.1 for 20.16 and 20.18. Earlier releases must migrate to a fixed release. Cisco marks 20.11, 20.13, 20.14 and 20.16 as past end of software maintenance and encourages a supported release. Check component compatibility and the current Cisco release table before scheduling the upgrade.
Cisco says there is no workaround that fixes the authentication flaw. For customer-hosted deployments, it recommends temporary ACL, security-group or firewall restrictions on ports 22 and 830 to known controller and authorized IPs, plus IP access limited to the hosts that need the control components. Test those restrictions against actual peer paths so the SD-WAN fabric still works. Cisco says these guardrails are already in place for its hosted options. Those deployments are also affected; upgrade their control components to a fixed release.
Verify the controller and its peers
Inventory Controller, Manager and Validator instances in each deployment, compare their running release against the matching Cisco first-fixed release, and move vulnerable instances to an appropriate fixed build. Before treating an upgraded node as clean, compare Accepted publickey for vmanage-admin entries and peering events with the authorized System IPs, public IP ranges, role assignments and change windows. Inspect runit launchers and the Talos-named KeyDrift artifacts if the logs or peer history look wrong. Cisco recommends collecting request admin-tech from each control component and opening a TAC case when compromise is suspected. Talos says to activate incident response for unauthorized activity.
A release comparison tests patch status; a topology-and-log comparison tests whether someone was already inside. The expected result is a fixed release on each affected component and peer and login events that match authorized systems and maintenance activity. Investigate discrepancies before returning a controller to routine operations.