-2.png?w=1024)
Malware inside a network controller can put the secrets protecting branch-to-branch traffic within an attacker’s reach.
Cisco Talos published an analysis of historical KeyDrift activity on Oct. 28, describing a malware framework deployed after attackers exploited a Cisco Catalyst SD-WAN authentication flaw. Researchers assess that it was designed to maintain access and collect encryption key material. Observed targets included satellite services, defense, aerospace, and policy research organizations.
For security teams, the findings raise two questions: whether vulnerable controllers received the fix and whether attackers established access before that happened.
How KeyDrift operates inside network controllers
According to Cisco Talos’ investigation, a group tracked as UAT-11473 exploited CVE-2026-20127 to install KeyDrift.
Its PolyFlame component runs inside legitimate controller processes and supports backdoor commands. Another component, LittleFilch, examines decrypted control messages and extracts what Talos assesses to be AES-256 IPsec key material used to protect SD-WAN data traffic. It stores collected information in encrypted form and can transmit it.
Talos describes the attacks as historical. Its infrastructure-overlap assessment involving Volt Typhoon’s Silent Train network does not establish that UAT-11473 and Volt Typhoon are the same actor.
The broader management-system risk also appears in attacks exploiting an Arista VeloCloud Orchestrator vulnerability, which can turn limited portal access into privileged operator control. That is a separate vulnerability and incident.
The underlying Cisco flaw already has patches
Cisco first disclosed CVE-2026-20127 in February. Its security advisory rates the authentication bypass at 10.0 and lists affected Controller, Manager, and Validator software.
An unauthenticated remote attacker can gain administrative privileges. On an affected Controller, that access includes a privileged non-root account capable of manipulating SD-WAN configuration through NETCONF.
Cisco has released fixes and says no workaround resolves the vulnerability. Administrators should compare each control component’s installed release with the advisory’s fixed-software table and check compatibility before upgrading.
Separate Cisco Meraki security updates have their own affected products and firmware requirements. Completing a Meraki update does not establish that a Catalyst SD-WAN controller is remediated.
What administrators should check before closing the response
Cisco recommends reviewing /var/log/auth.log for unexpected public-key logins involving the vmanage-admin account and checking the source IP addresses against the configured System IPs in SD-WAN Manager. It also calls for validating control-connection peering events against authorized IP addresses, device roles, maintenance windows, and change records.
Those checks need an owner and a documented result. A useful review should establish which components were exposed, when they were patched, and whether the available logs cover the period before remediation. Record missing evidence as a visibility gap rather than treating an empty search as proof of safety.
Preserve relevant evidence before making changes where operationally feasible. If suspicious access appears, involve incident responders and Cisco support to determine the scope and recovery steps. Avoid making isolated configuration changes that could disrupt branch connectivity or obscure evidence.
Access restrictions deserve a separate review. Cisco’s SD-WAN hardening guide recommends limiting access to trusted sources and separating management interfaces from public-facing transport infrastructure.
For a business using a managed service, ask the provider for component-level patch status and the outcome of its compromise checks. A general statement that “the network is updated” leaves important questions unanswered.
If an investigation indicates secrets were exposed, coordinate their replacement with containment and recovery. The separate discovery of leaked AWS keys that remained active illustrates why removing the original exposure and invalidating affected credentials are distinct tasks. AWS credentials and SD-WAN encryption keys require different recovery procedures.
The response should therefore produce two conclusions: evidence that the vulnerable software was fixed, and an assessment of whether unauthorized access occurred. A successful upgrade answers the first question. The second requires an investigation.
Read more: Extend your network security review to switching infrastructure by checking five critical Cisco Nexus flaws, affected configurations, and mitigation steps.