Your SD-WAN doesn't go down: it gets reconfigured

Somebody spent months inside a company's SD-WAN orchestrator and broke nothing. They came in through a peering connection nobody was reviewing, escalated to root, downloaded the configuration templates for the entire network using the product's own API and, before leaving, restored one by one every system file they had touched. Not a link down, not a file encrypted, not a single call to the helpdesk. It is all in the forensic report Google's threat intelligence team published about a real intrusion into a Cisco Catalyst SD-WAN Manager, and it explains far better than any CVSS score why the management plane of an SD-WAN is this year's target.

We deploy multi-site SD-WAN and we run our own network as an operator, so this one lands close to home. A while back we wrote about when SD-WAN pays off and when it is overkill, which is the conversation you have before signing. This is the other half: the day after. And the question that interests us today is not whether your orchestrator is patched — you either know that or you find out in ten minutes — but what trace somebody breaking into it would leave. Fair warning: less than you think.

Nine entries, one place

CISA's KEV catalogue is not a list of severe vulnerabilities. It is the list of the ones somebody is actually using, with confirmed exploitation, which is why every entry carries a deadline. We downloaded the catalogue published on 29 July and counted: 172 entries added in 2026. Nine of them target the management or control plane of an SD-WAN — the Manager and the Controller, where the configuration for every site is written. Eight Cisco, one Arista.

Before anybody jumps to the easy conclusion: nine out of 172 does not prove SD-WAN software is worse than anything else, it proves it is where people are looking hardest. Cisco is the second vendor in the 2026 catalogue with thirteen entries, behind Microsoft with thirty-two, and eight of those thirteen are SD-WAN. That is not bad luck spread around: that is effort concentrated on one target, both by whoever attacks it and by whoever audits it.

There is one detail in the catalogue that says more than any CVSS score. KEV entries carry a remediation deadline, and in 2026 they break down like this: sixty-five at three days, sixty at fourteen days, forty-four at three weeks, one at five days… and two at forty-eight hours. Those two are the two SD-WAN entries from 25 February. There are no others all year. That same day CISA issued an emergency directive — ED 26-03, "Mitigate Vulnerabilities in Cisco SD-WAN Systems" — due on the 27th, plus supplemental hunt-and-hardening guidance for that product family alone. It is the third emergency directive of that cycle and it targets one specific product, not a category.

The last of the nine, Arista's on 27 July, we already pulled apart here when the advisory came out — affected versions, mitigation and which logs to preserve — so we will not repeat it. What read that week as an isolated case reads differently lined up next to the eight before it. And to understand what it really means for somebody to get in there, the best document is not a vendor advisory: it is a forensic report.

The attacker who broke nothing

In June, Google's threat intelligence team published the analysis of a real intrusion into a Catalyst SD-WAN Manager. The full sequence is worth reading, because it looks nothing like what most people picture when they say "our network was attacked".

• Late 2025 and January 2026: unauthorised peering connections appear on the victim's devices. Nobody looks at them.
• March 2026: the attacker brings up a new peer and logs in over SSH with the vmanage-admin account. They change the admin account password to work and, before logging out, put it back the way it was.
• On 7 March, the important part: they download the topology and the network's configuration templates through the product's own API — /dataservice/system/device/vedges, /controllers, and each device's attached and running templates. The requests are all logged within the same minute.
• April 2026: they exploit CVE-2026-20245 by uploading a crafted CSV as if it were a tenant list. The file appends a troot user with UID 0 to /etc/passwd.
• And they clean up. They kept copies of the original /etc/passwd, /etc/shadow and tenant-list file to restore later, and ran a script checking one by one that none of their files was left behind.

Read it again and notice what does not happen in that list. No ransomware, no outage, no extortion, no users calling the helpdesk. There is somebody with root privileges reading how your network is built and able to write to it, behaving like the tidiest administrator you have ever had. And the tool they used to walk off with the configuration is not an exploit: it is the product's API. It is the same call your team makes when pulling an inventory.

Why your monitoring misses it

Think about what your WAN dashboard measures right now: tunnel up or down, latency, loss, jitter, SLA compliance per site. Throughout the months that intrusion lasted, all of that was green. It had to be: the attacker needed the network working just as much as the victim did.

Think of a railway switch: nobody derails the train and nobody rips up the track. Somebody pulls a lever, the train keeps running on time and sounding the same, and arrives somewhere else. A configuration change pushed from the orchestrator is the system operating normally. There is no anomaly to detect in the data plane. The anomaly is in who asked for the change, and no ping answers that question.

The signal lives in three places almost nobody watches. First, the configuration diff against a source of truth that does not live inside the orchestrator itself — we use NetBox as IPAM and DCIM for exactly this — because if the attacker restores their original files, the system's "current state" stops being a reliable source of anything. Second, the inventory of peers and controllers: a new peer should raise an event with a name attached, not a log line nobody reads. That is where it all started, months before root. And third, the actual path traffic takes rather than the state of the link: with NetFlow you can see whether a site's traffic has started leaving via somewhere else; with an availability check, you cannot. It is the same argument we made about alert fatigue: the problem is almost never missing alerts, it is that the ones you have mean nothing.

One clarification before we go on, because it is easy to read all of this as "Cisco writes bad code". It is not about that. A path traversal bug gets fixed and that is that; what no patch fixes is that the configuration for your forty sites lives in one place and is written from one place. Change the vendor and the version number changes: the exercise you have to do does not.

What we ask before the next change window

These are the questions we ask when we sit down in front of somebody else's multi-site network. None of them gets a "yes" on the first attempt, and that is exactly what they are for.

• Is the management plane on the internet? In February, Censys counted around 600 internet-facing SD-WAN Manager instances, roughly a quarter of them with port 22 or 830 open, which is how you reach the SSH and the NETCONF that the authentication bypass ends up handing over. If your orchestrator has a public interface "because the engineers connect from home", the decision is already made; it just has not been written down by anyone.
• Do you have a route to each site that does not go through the orchestrator? If the orchestrator goes down — or you deliberately shut it down, which is the right call after a compromise — the devices keep forwarding with the last configuration they received, but you have lost the steering wheel. Management 4G, console access, the carrier's line: something that does not depend on the box you are investigating.
• Where does the good configuration live? Exported, versioned and stored somewhere the orchestrator cannot write to. If the attacker restores the original files, comparing the system against itself is worthless.
• Who can push configuration, with what approval and what record? Without a written change window, there is no way to tell the attacker's change from Tuesday's change. And yes, this is boring, and yes, it is the first thing to go when there is a rush.
• If there was a compromise, patching is not cleaning. The orchestrator holds the credentials and certificates that authenticate every device in the fabric: they have to be rotated, not just the binary updated. It is the same lesson we already wrote about with the FortiOS symlink, and it is still being learnt late.

What we are not going to tell you

We are not going to tell you to rip out SD-WAN. It would be an easy way to end an article with nine CVEs in it, and it would be foolish. What we will say is where you have filed it mentally. Almost everybody treats the orchestrator as an operations tool: the integrator installs it, three people use it, and it lives in the "network infrastructure" folder. It is a system with administrator privilege over your entire network, and it deserves the same paranoia as your domain controller: restricted access, logs somebody actually reads, credentials that get rotated and a written procedure for when it fails. The day it changes category, half of these questions answer themselves.

Nor are we going to tell you how many VeloCloud On-Prem orchestrators are exposed in Spain right now. We have not measured it and we are not going to invent it. What we do find when we walk into somebody else's network is a "temporary" firewall rule that has been there for three years and an integrator maintenance account nobody has reviewed since go-live. If either of those sounded familiar, you already know where to start on Monday.

We design and operate multi-site SD-WAN networks with monitoring and change control in front, not behind, and we do it from the position of an operator running its own network: BGP, transit, NetFlow and a public looking glass. We are not resellers of any platform, so the answer to "which orchestrator should I use?" depends on your case and not on our commission.

The question we close on is not whether your SD-WAN is patched. It is this: if tomorrow a perfectly legitimate change, signed by your own orchestrator, sent one site's traffic somewhere it should not go, how long would it take you to find out, and through which screen? If the answer is "we would see it", show us the screen where you would.

Sources (verified): the counts — 172 entries added in 2026, nine of them SD-WAN management plane, thirteen from Cisco against thirty-two from Microsoft, and only two entries in the entire year with a 48-hour deadline — are our own calculation over the CISA KEV catalogue file, version 2026.07.29, downloaded on 1 August 2026; each CVE description and the added/due dates come from that same file. Emergency Directive ED 26-03 and its supplemental hunt-and-hardening direction are published by CISA and referenced from the catalogue entries themselves. The intrusion sequence (unauthorised peerings from late 2025, SSH with vmanage-admin, the crafted tenant CSV, the troot account, exfiltration via /dataservice/ and the anti-forensic techniques) comes from "Zero-Day Exploitation of CVE-2026-20245 in Cisco Catalyst SD-WAN Manager" by Google Cloud Threat Intelligence (Mandiant). The CVSS 10.0 for CVE-2026-16812 comes from Arista Security Advisory 0144 and its coverage in BleepingComputer. The exposed-instance count is from the Censys advisory of February 2026 and is a third-party measurement, with the imprecision any scan carries. Ours, not our sources': the reading that the orchestrator is the target by design rather than by bad programming, the three places where the signal lives, the five questions, and the closing section on what we will not tell you.