What happened

On 28 October 2026, Cisco Talos published research on an advanced persistent threat tracked as UAT-11473. According to Talos, the group exploited CVE-2026-20127, an authentication bypass in Cisco Catalyst SD-WAN Controller instances, and then installed a custom malware framework Talos calls KeyDrift. BleepingComputer and SecurityWeek report that the flaw has a CVSS score of 10, was disclosed in February 2026, and lets a remote attacker without credentials bypass peering authentication and obtain administrative access. Cisco has released patches and a hardening guide for Catalyst SD-WAN.

Talos describes KeyDrift as designed for long-term persistent access and automated exfiltration of sensitive keying material. It has two main components. PolyFlame is a memory-resident module deployed through modified runit service paths and injected into legitimate vdaemon processes; it can also masquerade as a packed aaamgrd loader variant, and it acts as a backdoor and a relay for command-and-control traffic. LittleFilch hooks SSL_read inside vdaemon, inspects control-plane messages after decryption, extracts key material for a list of predefined edge nodes, and stages it locally in encrypted form. Press coverage of the research says the staging file is /var/tmp/vdaemon.bin.

Talos says the infrastructure overlaps considerably with the Silent Train covert access network associated with Volt Typhoon, but it does not state that the two are the same actor. Talos also calls the activity historical and does not say when the intrusions took place. Observed targets were space and satellite services, defense and aerospace technology, and policy research organizations.

Why it matters

An SD-WAN controller is a trust anchor. It authenticates peers, distributes policy and sees control traffic in the clear. A malware framework that lives inside the control-plane process can read that traffic after decryption, which means TLS or DTLS on the wire does not protect it. If the key material for data-plane IPsec tunnels is taken, the impact extends beyond the controller to the traffic it helps secure.

It also matters that the fix has existed since February. A patch applied today closes the door but does not tell you whether someone walked through earlier. Talos's research is about historical activity, so the practical question for most teams is not only "are we patched" but "were we compromised before we patched".

What defenders should check

  • Inventory every Catalyst SD-WAN Controller and Manager, including lab and forgotten instances, and confirm each runs a release that fixes CVE-2026-20127. Use Cisco's advisory for the fixed versions that apply to you.
  • Apply Cisco's Catalyst SD-WAN hardening guide, and restrict management and control-plane access to known peers and administrative networks.
  • Check external exposure from your own side with internet scanning tools scoped to your organization's address ranges.
  • Review the list of control connections and peers on each controller for any you cannot map to a known device.
  • Review authorized SSH keys, local accounts and NETCONF configuration changes for entries nobody can explain.
  • Establish when each controller was patched. Anything exposed before that date deserves the investigation steps below.

Detection ideas

The following are starting points to adapt and test in your environment. They are not production-ready detections, and the indicators come from public reporting that may not cover every variant. Talos saw signs of ongoing development in the framework, including new anti-debugging and varied process impersonation.

File and script checks on a controller shell:

# staging file reported for LittleFilch
ls -la /var/tmp/vdaemon.bin 2>/dev/null

# script named in the PolyFlame sshd deployment
find / -xdev -name 'conf_sshd' 2>/dev/null

# recently modified runit service run scripts
find /etc/sv /service /etc/service -name run -mtime -90 -ls 2>/dev/null

# the root filesystem remounted read-write
mount | grep -i rootfs

If you forward controller syslog or EDR data to a SIEM, look for unexpected peers and administrative changes. A generic KQL starting point:

Syslog
| where Computer in ("<your sd-wan controllers>")
| where SyslogMessage has_any ("vdaemon", "aaamgrd", "authorized_keys", "netconf")
| where SyslogMessage has_any ("added", "modified", "new peer", "Accepted publickey")
| project TimeGenerated, Computer, SyslogMessage

Also consider alerting on outbound UDP from controllers to destinations outside your known peers, since press coverage of the research says the collected data is sent over UDP. Talos lists Snort SIDs 65938 and 65958 for CVE-2026-20127 exploitation attempts.

Investigation

If a controller was reachable before patching, or any check above hits, treat it as a possible compromise and preserve evidence before you rebuild or reboot.

  • Capture volatile data first. PolyFlame is described as memory-resident and injected into vdaemon, so a memory image or process memory capture of vdaemon and related processes may be the only place it is visible. Compare the memory mappings of running processes against known good.
  • Collect the runit service directories and their run scripts, with timestamps, and compare them against a clean image of the same software version.
  • Collect authentication logs, the list of authorized SSH keys, NETCONF and configuration change history, and the list of control peers with their first-seen times.
  • Collect network flow records for the controller to find unexplained destinations, especially UDP.
  • Build a timeline from the first suspicious peer or configuration change forward. Identify which edge devices the controller held key material for, because those are the ones whose keys may be exposed.

If compromise is confirmed, plan for key and credential rotation across affected edge devices and controller accounts, not only a controller rebuild. Our incident response and compromise assessment teams work through exactly this kind of scoping.

Mitigation

  • Patch to a fixed release per Cisco's advisory for CVE-2026-20127, and keep the controllers on a regular update cadence.
  • Follow the Catalyst SD-WAN hardening guide and keep control-plane and management interfaces off the public internet wherever the design allows.
  • Forward controller logs off-box so an attacker with local access cannot erase them.
  • Add the controllers to your threat hunting scope on a recurring basis, since network appliances often sit outside EDR coverage.
  • Document a key rotation procedure for the SD-WAN fabric before you need it.

Source: Cisco Talos, "Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN"; additional reporting by BleepingComputer and SecurityWeek.