Your SD-WAN rotates the key every 24 hours. So does the implant

One component of the implant Cisco Talos described on 28 October 2026 is called LittleFilch, and it does exactly one thing: it hooks the SSL_read call inside the control-plane process of a Catalyst SD-WAN controller and extracts key material from decrypted control traffic, for a list of predefined edge nodes. Talos assesses — that is its own word, assessed, not confirmed — that those 32 bytes are OMP-distributed AES-256 IPsec data-plane key material. It picks it up at the place where, according to Cisco's own documentation, that material has to pass.

What the manual says, before we talk about any attacker

Cisco's security guide describes the data-plane key cycle in two sentences. First: "Each router generates a new AES key for its data path periodically." And then, at rekey time: "the router sends it immediately to the Cisco SD-WAN Controllers using DTLS or TLS. The Cisco SD-WAN Controllers send the key to the peer routers." The router makes it, the controller hands it out.

The design has its logic: somebody has to distribute keys across dozens or hundreds of sites that do not know each other in advance, and that somebody is the controller. The price of that convenience is written on the same page. By construction, the controller is the place where each site's key exists in the clear for an instant.

The other number in the manual is the one that gives this piece its title. By default, a key is valid for 86,400 seconds: 24 hours. The configurable range runs from 10 seconds to 1,209,600 — fourteen days. That rotation is sold, rightly, as cryptographic hygiene: if somebody captures a key, it expires on them the next day.

Why rotation stops being a defence

An implant living inside the process that receives the keys does not need the key to last. It needs to still be there tomorrow. Talos is quite explicit on that point: persistence is built by modifying the runit service scripts under /etc/sv/sshd/ and /etc/sv/aaamgr/, which remount /rootfs.rw as executable and launch the injection chain at every boot.

Put that way — and this is our reading, not Talos's: as long as the implant is inside, the 24-hour rotation cycle stops being a defence and becomes a delivery schedule. Every time the fabric rekeys, it comes past the same spot again. You do not need to break AES or decrypt anything; you need to be in the room when the envelopes are handed out.

And keys alone would be worth little without the map. Which is why the same component takes, alongside the key material, the public IPs and system-IPs of the vEdge devices pulled out of the control-session buffers. The key, and which tunnel it belongs to.

Writing into /etc/sv takes root. CISA added two CVEs on the same day

The way in is CVE-2026-20127, a 10.0 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and CWE-287: a failure in peering authentication on Catalyst SD-WAN Controller (formerly vSmart), Manager (formerly vManage) and Validator (formerly vBond). Cisco is blunt in the advisory: "There are no workarounds that address this vulnerability." The KEV catalogue description adds the detail that explains the rest: the attacker lands as "an internal, high-privileged, non-root user account" and from there reaches NETCONF — that is, the fabric configuration.

Note the "non-root". Writing into /etc/sv/ and remounting a filesystem takes root, and Talos does not say how that last jump was made: its report names no second CVE. What is verifiable is that CISA added to the KEV catalogue, on the same day and with the same deadline, CVE-2022-20775: published on 30 September 2022, a 7.8 that lets an authenticated, local attacker "execute arbitrary commands as the root user" from the application CLI. That two simultaneous entries fit together this neatly is, let us be clear, a hypothesis of ours and nobody's finding.

Three years and almost five months passed between that 7.8 being published and the day CISA declared it exploited. Only yesterday we were looking here at what happens when you rank a 2.7 fifth, and the pattern is the usual one: a low score sends the line to the bottom of the patching queue, and the day it shows up at the top is because somebody has found it a place in a chain.

Nine KEV entries this year. We counted them ourselves

We pulled CISA's KEV catalogue on 31 October 2026 (version 2026.10.30, 1,766 vulnerabilities) and filtered by product. Cisco SD-WAN accounts for nine entries added so far in 2026, eight of them carrying a CVE from this same year:

Nine entries between February and September against the same management plane say something a single one does not: the controller is the target, and has been all year. It makes sense from the attacker's side. Compromising a site gets you a site. Compromising the controller gets you the map and the policy, and — if Talos's assessment is right — what opens the tunnels.

The countermeasure was published eight months before the proof

On 25 February 2026 — the same day as Cisco's advisory and the two KEV entries — CISA issued Emergency Directive ED 26-03, "Mitigate Vulnerabilities in Cisco SD-WAN Systems". The inventory of affected systems was due by 11:59 PM ET the following day; the updates, by 5:00 PM ET on 27 February. It binds only US federal civilian agencies, so it obliges a company over here to nothing. But the supplemental direction that goes with it, carrying the hunt and hardening guidance, contains two sentences that are just as valid in Manresa as in Maryland:

What that first line means technically — and this part is ours, CISA does not spell it out that way — is: stop routing the symmetric key through the controller. The second is harder than it first looks: for anyone who finds a root compromise, the instruction is not to clean the controllers they have but to stand up new ones from vendor images and migrate the edges across. Both are dated February, when nobody had yet published an implant that read key material inside the controller. The answer had been published, and free, for eight months by the time the analysis explaining what it was for turned up.

What pairwise keys actually change (and what they do not)

The difference is in what travels. In the default mode, what the router sends to the controller is the key. With pairwise keys, Cisco's documentation puts it this way: "IPSec devices share public values from Diffie-Hellman (DH) algorithm with the controllers. The controllers relay the DH public values to authorized peers of the IPsec device as defined by a centralized policy." What flows through the controller becomes public values, and the session key is derived by the two endpoints. An implant sitting on SSL_read still sees things go by; what it sees no longer opens the tunnel.

Now the drawbacks, because there are some and they are worth saying before somebody turns this on a Friday:

The email we would send to whoever operates your controller

In many managed deployments the control plane is not in the customer's inventory, because it is not theirs. That does not remove the question, it only changes who you ask. Copy, paste, and ask for the answer in writing:

Three honest caveats

First, on scope. Cisco speaks of "limited exploitation" and the targets Talos describes are space and satellite services, defence and aerospace technology, and policy research. Talos adds, with high confidence, that this actor's infrastructure overlaps considerably with "Silent Train", Volt Typhoon's covert access network. If you run ten sites and sell office supplies, you are not these people's target. What everybody inherits sooner or later is their techniques.

Second, on the vendor. Back in September we wrote here about a 10.0 in another vendor's orchestrator — a different problem, the same place compromised. We are not saying switch platform, and it is worth remembering why you centralised the control plane in the first place: it is what lets a small team run a hundred-site network, and that is still true this afternoon. Moving vendor because of a news item is the most expensive way of solving nothing, because whatever the control plane concentrates gets concentrated just the same in the next one's control plane. We sell nobody's licences, so this recommendation does not put food on our table.

Third, on us. We have not verified the implant ourselves: the component names, the files and the persistence mechanism come from Talos's 28 October publication, and attributing the material to AES-256 is their assessment, not a confirmed fact. What we did do is count the KEV catalogue, put the dates in order and read the manual.

Where the secret lives in your network

The question holds for any encrypted mesh, whatever it is called: if there is a place in your network through which the secret of every other site passes, even for an instant, that box deserves the inventory, the patching, the integrity monitoring and the rebuild plan you would give a safe. Today, in most deployments, what it gets is a quarterly update ticket.

It is the same conversation we had here when we looked at two carriers on the invoice, one core on the network: two links on the invoice are not two paths if underneath they share a single element. There the shared element was a carrier's core. Here it is your own controller, and what it shares is the keys.

We design and operate multi-site SD-WAN and networks and communications on our own network — BGP, transit, peering — and in the deployments we run the control plane sits in the inventory like any other production service: with an owner, an update window and a measured number of hours to rebuild it from scratch. If you do not know that number for your network, drop us a line and we will measure it, even if the result is that everything is fine.

Sources (checked on 31 October 2026): the KeyDrift framework analysis, its component names (PolyFlame/libdssl.so, LittleFilch/libcommon.so, rsshd, conf_sshd, aaamgrd), the SSL_read hook inside vdaemon and the extraction of keying material for a list of predefined edge nodes — which Talos assesses to be OMP-distributed AES-256 IPsec data-plane key material, not a confirmed fact — alongside vEdge public IPs and system-IPs, the persistence via runit service scripts under /etc/sv/sshd/ and /etc/sv/aaamgr/ with the /rootfs.rw remount, the targeted sectors and the infrastructure overlap with Volt Typhoon's "Silent Train" covert access network all come from the Cisco Talos report "Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN", published 28-10-2026. The 10.0 score, the vector, CWE-287, affected products, fixed releases, the no-workarounds sentence and the first-published (25-02-2026) and last-updated (28-10-2026) dates come from Cisco advisory cisco-sa-sdwan-rpa-EHchtZk. The data-plane key cycle, the 86,400-second default and the 10 to 1,209,600 range are from Cisco's security configuration guide. Pairwise keys, the Diffie-Hellman public-value exchange relayed by the controllers, the 3,600-second default validity, the required reboot and the minimum releases (SD-WAN 19.2.1 and IOS XE SD-WAN 16.12.1b) are from the IPsec Pairwise Keys pages of the same documentation. Emergency Directive ED 26-03 (25-02-2026, updated 11-03-2026) and its supplemental hunt and hardening direction are CISA's; the two quoted sentences and the 5:00 PM ET 27-02-2026 deadline come from there. The nine Cisco SD-WAN entries in the KEV catalogue, their dates, and the description of the internal account and NETCONF access, we counted ourselves from the catalogue JSON, version 2026.10.30. CVE-2022-20775 details (published 30-09-2022, 7.8, arbitrary command execution as root from the application CLI) are from the NVD. What is ours, and it is worth separating: reading the 24-hour rekey as a delivery schedule for as long as the implant persists, the hypothesis that CVE-2022-20775 is the second rung up to root (Talos names no second CVE; all that is verifiable is that CISA added both on the same day), the technical translation of CISA's pairwise-keys recommendation, the KEV count, the February-to-October chronology and the email to the provider. Cover photo: Optical-fiber-distribution-frame-0a, CC BY-SA 3.0, via Wikimedia Commons.