Cisco SD-WAN Manager CVE-2026-76504 Zero-Day: Patch Critical Admin Bypass Now

What Cisco disclosed​

Cisco's advisory, identifier cisco-sa-sdwan-webauth-xr8beuuU, is titled "Cisco Catalyst SD-WAN Manager API Authentication Bypass Vulnerability." Cisco's public advisory listing shows it went live at 13:00 GMT on September 30, 2026. The listing rates it Critical, tracks it as bug CSCww79570, classifies it as CWE-177 (Improper Handling of URL Encoding), and says no workaround is available.

The main points:

• Where the flaw is: The advisory text says the bug is in the API session-based authentication management of Cisco Catalyst SD-WAN Manager. It lets an unauthenticated, remote attacker in with the privileges of the admin user.
• Root cause: It is due to improper handling of URI encoding in an HTTP request, which allows the request to bypass an authentication rule that is intended to restrict access to a specific API endpoint.
• Severity: Several trackers list it at CVSS 9.8. The Hacker News reports that CVE-2026-76504 carries a CVSS score of 9.8 out of 10.
• Exploitation status: Cisco says: "In September 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability"
• Configuration doesn't save you: BleepingComputer reports the flaw affects all deployments regardless of system configuration. No feature toggle makes a deployment safe.

Catalyst SD-WAN Manager is the product formerly called vManage. BleepingComputer describes it as the dashboard that lets admins monitor and manage up to 6,000 SD-WAN devices from a single dashboard. A pre-auth admin bug here is not like one weak branch router. The attacker gets the console that configures all of them.

Section summary: This is an unauthenticated remote bypass to admin on the SD-WAN management plane. It is being exploited now, it has no workaround, and your configuration doesn't matter.

How the bypass works​

The flaw depends on URL encoding. Any character in a URL can be written as a percent sign followed by its hex value, so the letter "j" can also be sent as %6a. A server that checks the raw path before decoding it can be fooled: the security rule looks for one string and misses it, but the application decodes the request and serves it anyway.

That is what happens here. According to BleepingComputer, Cisco's indicators of compromise say attackers are using %6a as the URI-encoded "j" in malicious requests. The relevant endpoint is j_security_check, the standard Java login-form handler. One independent write-up on DEV Community explains the mechanic this way: the authentication rule for j_security_check doesn't match. The request then reaches the protected endpoint without credentials.

This is general industry knowledge, not something from the advisory: path-normalization bugs like this have hit web stacks for decades. They keep coming back because access-control checks and request routing often decode URLs at different stages. Anyone who runs reverse proxies or WAFs in front of Windows or Linux web apps has seen this failure mode before.

Fixed releases​

The table below matches what BleepingComputer published. daily.dev's summary gives the same list and notes that systems earlier than 20.9 must migrate to a fixed release.

For Cisco's hosted service, HOL's summary of the advisory says Cisco Catalyst SD-WAN Cloud Hosted (Cisco Managed): Cisco already shipped fixed Release 20.15.605. No user action is required. daily.dev reports the same. The urgent work therefore falls on on-premises and customer-managed Managers.

Section summary: Every supported train from 20.9 through 26.2 has a fix. Anything older has to move to a new train, and Cisco-managed cloud tenants reportedly have nothing to do.

A practical response plan​

This is the order I'd work in, based on Cisco's published guidance as reported by BleepingComputer and HOL:

1. Inventory every Manager. List every Catalyst SD-WAN Manager instance, including lab and disaster-recovery copies, with its release train and build.
2. Cut exposure right away. The Hacker News reports that Managers exposed to the internet are at risk of compromise, according to Cisco. If you can't upgrade immediately, HOL reports that Cisco's temporary measure is to put Control Components behind a filtering device, allow only known trusted hosts, and follow the Cisco Catalyst SD-WAN Hardening Guide. Filtering reduces risk. It does not fix the flaw.
3. Preserve evidence before you patch. Cisco advises collecting admin-tech files to support any compromise review. An upgrade can overwrite the state an investigator needs, so capture first.
4. Hunt in the logs. BleepingComputer reports that Cisco points investigators to two files:
   • serviceproxy-access.log under /var/log/nms/containers/service-proxy/
   • vmanage-server.log under /var/log/nms/
   Look for j_security_check entries from unknown or unauthorized IP addresses, and look at requests that use %6a in place of "j".
5. Don't panic over one match. According to HOL, Cisco notes these IOC patterns can also appear in normal operations, so compare against your baseline. The source IP is the most important field.
6. Escalate if in doubt. Cisco says "For help determining if a Cisco Catalyst SD-WAN Manager has been compromised, customers may open a case with the Cisco TAC,"
7. Upgrade to the first fixed release or later on your train. HOL points to the Catalyst SD-WAN Control Component Compatibility Matrix and the Cisco Catalyst SD-WAN Upgrade Matrix for planning the cutover.

If you find evidence of compromise, patching is not the end of the job. An attacker with admin rights on the Manager could have changed configuration or created access that survives the upgrade. Treat it as an incident, not just a maintenance window.

Five zero-days in one year​

BleepingComputer lists the earlier 2026 SD-WAN zero-days as CVE-2026-20127 (February), CVE-2026-20182 (May), and CVE-2026-20245 and CVE-2026-20262 (early June). It says the June pair were exploited to gain root privileges on vulnerable systems.

Cisco's own advisory listing adds some detail:

Two findings stand out. First, BleepingComputer calls CVE-2026-20127 an SD-WAN Manager information disclosure flaw, but Cisco's listing titles it a Controller peering authentication bypass rated Critical. Go by Cisco's wording. Second, the June bugs need authentication. That makes them ideal second stages: an attacker gets in through a pre-auth bypass, then escalates to root with an authenticated bug. That is my analysis, not something Cisco has attributed. It is still a good reason to confirm the June patches are installed while you apply this one.

BleepingComputer also notes that since November 2021, CISA has marked 90 Cisco vulnerabilities as exploited in the wild, four of them in Catalyst SD-WAN Manager. I haven't checked that count against CISA's catalog, so treat it as BleepingComputer's figure.

What's still unknown​

Cisco hasn't named an attacker, said how many customers were hit, or described what intruders did after getting in. BleepingComputer notes the company didn't share further details regarding attacks. The IOCs and log paths are real, but the scale of exploitation isn't public. Be wary of anyone claiming to know it.

Some context helps here too. SD-WAN managers exist to centralize control, and that is exactly why attackers target them. One compromised console can give an attacker the whole branch network. Five exploited zero-days in nine months should prompt a basic review: does your management plane need to be reachable from the internet at all? For most organizations the honest answer is no.

Bottom line​

If you run Catalyst SD-WAN Manager yourself, do four things today: restrict access to trusted hosts, collect admin-tech files, check the service-proxy and vmanage-server logs for suspicious j_security_check traffic, and upgrade to the fixed build for your train. Customers on the Cisco-managed cloud service are reportedly already covered. Everyone else is working against attackers who are already exploiting the flaw.