SD-WAN controller auth bypass: why the patch does not contain control of your network

An authentication-bypass flaw in an SD-WAN management controller teaches a lesson responders keep learning the hard way: the box you patched is not the incident. When the class that includes Cisco Catalyst SD-WAN Manager lands in the CISA Known Exploited Vulnerabilities catalog, the reflex is to patch the appliance and close the ticket. That reflex is wrong here, because the controller is not an appliance. It is the management plane for the entire WAN fabric, and bypassing its authentication is control of the network, not compromise of one box.

How it works

The controller’s management interface is reachable and running a version with an authentication-bypass class flaw. An attacker sends a crafted request and receives an authenticated administrative response with no login, no MFA, and no session in front of it (T1190, Exploit Public-Facing Application, landing on the effect of T1556, Modify Authentication Process). No credential was needed to get in.

From that admin context the attacker reads what the controller holds. That is the whole point of a controller: it stores the per-device credentials for every edge router, the controller’s own API keys, the token for the automation or orchestrator system it bridges to, and the device-onboarding certificates (T1552, Unsecured Credentials). Then it does what a controller does. It pushes a templated policy and routing change to every managed edge at once: a permissive rule and a new route that steers a segment’s traffic through an attacker-reachable next hop. Minutes later the harvested orchestrator token is replayed against the automation system, and the device credentials are reused to log directly into edge routers (T1078, Valid Accounts; T1046, Network Service Discovery). The blast radius is the fabric.

Why the controller is Tier 0

A management-plane controller has three properties that make it a Tier 0 asset, not a network appliance.

It pushes to everything. One authenticated action on the controller becomes a config change on every edge router it manages. There is no per-device compromise to chain: the fan-out is the product feature. A single malicious route or rule reaches the whole estate in one push.

It holds the fabric’s secrets. The controller stores the device and API credentials for every router it onboarded, plus the token for the automation system it bridges to. Once its auth is bypassed and its config is read, assume every one of those secrets is exposed. Patching the flaw does not un-copy them.

It bridges to identity and automation. The controller does not live alone. It talks to the orchestrator, to RADIUS or the directory for device and admin auth, and to the automation that provisions sites. That bridge is a pivot the attacker inherits the moment they hold the controller.

Those three together are why this is control of the network fabric. The attacker can steer or intercept traffic across the estate, reuse fleet credentials, and reach the systems the controller bridges to. A patch closes the door they came through and leaves all of that in place.

How to detect it

The signal of the bypass is an authenticated administrative action with no authentication behind it. A management-plane controller normally requires a named admin over MFA before any admin action succeeds. The tell is an administrative response in the management-plane log with no preceding successful login, no MFA challenge, and no session establishment. Request volume and CPU are noise; a template read by an authenticated admin is routine. The absent auth event is the signal.

After that, the authoritative record of what happened is the controller’s own change history. The policy-deployment and device-template audit logs record every push: which template changed, who pushed it, and which edges received it. Reading the current running config on each router shows the present state, not what changed or when, and can miss a subtle route. Scope the exposure window in the deployment logs, and correlate the automation platform’s audit log for the harvested orchestrator token to see what moved across the bridge.

How to contain and shut it down

This is the part people get wrong. Patching the controller closes the bypass, but it does not un-expose the fleet credentials the attacker already copied, and it does not un-push the malicious route already sitting on every edge. Isolating the one box is not containment. Treat the controller as full compromise of the management plane:

• Patch or isolate the controller and revoke every live management and automation session it issued during and after the bypass window.
• Rotate every secret it held or brokered: the per-device credentials for the edge routers, the controller API keys, the automation or orchestrator token, and the device-onboarding certificates.
• Audit the policy-deployment and device-template logs for the window, identify every config and routing push, and roll back the malicious ones on the affected edges.
• Take the management interface off the public internet, put it behind a bastion with enforced MFA, and segment the automation bridge token.

Then scope honestly. Control of the management plane means the attacker could steer or intercept traffic across the fabric, so treat any segment whose traffic could have been steered as potential data exposure, and treat the exposed device credentials and automation bridge as a broad estate exposure until forensics narrows it. Obligations follow the scoped exposure, not the fact that the entry point was a network controller.

Recovery must not re-import the problem. Rebuild on a known-good patched controller with rotated credentials and re-issued certificates, and restore a policy baseline from before the exposure window, not the most recent config backup, which may already contain the attacker’s push. Eradication closes the class: audit every other controller or orchestrator that pushes config to a fleet the same way.

Practice it

We built this as a scenario in GraphLattice Range: an unauthenticated auth bypass on an SD-WAN management controller, stored device and API credentials read, a malicious policy pushed to every edge, and the automation bridge and routers taken with reused credentials. It forces the non-obvious call under time pressure. Patch the controller and watch, or treat the fabric as under attacker control: rotate every credential and certificate it held and audit and roll back what it pushed. Teams that have made that call in a drill make it faster when it is real.