If your organisation uses Cisco SD-WAN to connect its offices, branches, or sites, the system that controls all of that connectivity can currently be taken over by someone with no password at all, and Cisco has confirmed that attackers are already doing it. Whoever holds the controls of that system can change how traffic moves between every location it manages, create accounts, and push configuration changes across the whole network from a single screen. There is no setting to switch off and no workaround; the only fix is an upgrade. If the system has been reachable from the internet, that upgrade should come right after a check for whether someone already got in.
The flaw, tracked as CVE-2026-76504 with a CVSS score of 9.8 out of 10, affects Cisco Catalyst SD-WAN Manager, the central console for Cisco's software-defined wide area networks. Cisco disclosed it on September 30, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog the same day, and federal agencies have been ordered to fix it by Saturday, October 3. It is the fifth actively exploited Cisco SD-WAN zero-day of 2026, and organisations that upgraded for the May and June flaws are still exposed to this one. The sections below cover what the flaw does, how to tell whether you were hit, and what to do in what order.
Why this one matters
SD-WAN Manager, formerly known as vManage, is the single pane of glass from which an organisation runs its wide area network; one instance can monitor and manage up to 6,000 SD-WAN devices. It decides how traffic flows between headquarters, branch offices, data centres, and cloud services, and it pushes policy and configuration out to every router it controls. Compromising it is less like breaking into one office and more like getting hold of the master switchboard for all of them.
CVE-2026-76504 hands an attacker that switchboard. A successful exploit grants access to the Manager's API as the admin user, and by default that account holds the netadmin role, which is permitted to perform every operation the system supports. Jason Soroko of Sectigo pointed out that this kind of access creates a risk of unauthorised configuration changes across every branch the Manager oversees, which is precisely the kind of change that can redirect traffic, weaken security policy, or quietly open new paths into the network.
The timing compounds the risk. Cisco learned of attacks in September, before a fix existed, so patching today protects against the next attempt but says nothing about earlier ones. Roman Sannikov of iCounter summarised the right posture well: teams should assume someone may already have used the flaw before they upgraded. That turns a patching task into a question for the business: was our network control plane accessed, and if so, what did the intruder change?
How this came to light
Cisco says the vulnerability was found while its Technical Assistance Center (TAC) was working through a customer support case, and that its Product Security Incident Response Team (PSIRT) became aware of active exploitation in September 2026. The advisory, cisco-sa-sdwan-webauth-xr8beuuU (bug ID CSCww79570), was published on September 30 at 13:00 GMT with fixed releases already available.
CISA moved quickly. It added the flaw to the KEV catalog on September 30 under the name "Cisco Catalyst SD-WAN Manager Hex Encoding Vulnerability" and gave Federal Civilian Executive Branch agencies three days, until October 3, to remediate under Binding Operational Directive 22-01. A three-day window is short even by KEV standards and reflects how seriously the agency views exposed SD-WAN management systems after a year of repeated attacks on them.
What has not been disclosed is just as important. Neither Cisco nor CISA has said who is behind the attacks, how many organisations have been compromised, when exploitation began, or what the attackers did after gaining access. In the absence of that information, every organisation with an internet-reachable Manager should treat itself as a potential victim until its logs say otherwise.
How the flaw works
The vulnerability sits in the API session-based authentication management of SD-WAN Manager and is classified as CWE-177, improper handling of URL encoding. Session-based logins to the Manager go through a request path called j_security_check. The system has an authentication rule intended to restrict access to a specific API endpoint, but that rule does not correctly account for URI encoding.
In practice, an attacker replaces one character of the request path with its percent-encoded equivalent. Cisco's example uses %6a, the encoded form of the letter j, producing a request to /%6a_security_check. The rule that should block the request does not recognise the encoded path as the one it is meant to protect, yet the request is still processed as a login. The result is an authenticated session with admin privileges, obtained without credentials.
Cisco has not published the full mechanics, but its indicators of compromise point to the reserved system service accounts, whose usernames begin with viptela-reserved-, as the path being abused. These are internal accounts documented in Cisco's configuration guide and not meant to be reachable by outside requests; the CVE record itself describes the issue as a system account authorization bypass.
Two details matter for defenders. First, the vulnerability affects SD-WAN Manager regardless of configuration, so there is no feature to disable. Second, %6a is only an example: Cisco states that any one character in the path can be encoded to trigger the flaw, so detection that looks only for %6a will miss variants.
Who is affected
Every on-premises Cisco Catalyst SD-WAN Manager running a release below the fixed version for its train is vulnerable. Managers exposed to the internet are at the greatest risk.
| Release train | First fixed release |
|---|---|
| Earlier than 20.9 | Migrate to a fixed release |
| 20.9 | 20.9.10.1 |
| 20.12 | 20.12.8.2 |
| 20.15 | 20.15.6.1 |
| 20.18 | 20.18.4.1 |
| 26.1 | 26.1.2.1 |
| 26.2 | 26.2.1 |
A few points deserve attention:
- Earlier fixes do not cover this. The fixed releases for the May and June SD-WAN flaws (CVE-2026-20182, CVE-2026-20245, and CVE-2026-20262) are all older than the releases above. A Manager last upgraded for those still needs this update.
- Some release trains are missing from the table. The 20.10, 20.11, 20.13, 20.14, and 20.16 trains appeared in Cisco's May advisory but are not listed here. If you run one of them, plan a migration to a listed fixed release and confirm the path with Cisco TAC using the Catalyst SD-WAN Upgrade Matrix.
- Cisco-managed cloud is already fixed. Cisco SD-WAN Cloud (Cisco Managed) was remediated in release 20.15.605 and needs no customer action. Cisco Catalyst SD-WAN Cloud Hosted environments already have the network access mitigation in place.
- Some deployment types are not named. Unlike the May and June advisories, this one does not mention Cisco SD-WAN Cloud-Pro or Cisco SD-WAN for Government (FedRAMP). Customers on those platforms should confirm their status with Cisco directly rather than assume they are covered.
What you should do
1. Check for compromise before you upgrade
Because exploitation began before the patch, upgrading closes the door but does not tell you whether someone already walked through it, and it may disturb evidence you need. Cisco's advisories for the May flaw and the first June flaw both stated that an update alone would not resolve a confirmed compromise and told customers to collect diagnostic data before upgrading. This advisory is silent on the point, so the cautious course is the same.
Start with the two log files Cisco identifies:
/var/log/nms/containers/service-proxy/serviceproxy-access.log: look for POST requests to any URL-encoded variant ofj_security_checkfrom unknown or unauthorised IP addresses. Cisco's example entry is a request to/%6a_security_checkreturning HTTP 200./var/log/nms/vmanage-server.log: look forj_security_checkentries, particularly those tied to usernames beginning withviptela-reserved-, from unknown or unauthorised sources.
Search for every encoded variant, not only %6a; a regular expression that matches a percent-encoded character anywhere in the j_security_check path is a better starting point. Cisco notes that some matching entries can occur during normal operations, so compare hits against your normal baseline before drawing conclusions.
Then run the request admin-tech command on the Manager to capture a diagnostic bundle before upgrading. If you need help interpreting the results, Cisco asks customers to open a Severity 3 TAC case with CVE-2026-76504 in the title and attach the admin-tech file.
2. Upgrade to a fixed release immediately
Move to the fixed release for your train from the table above, or migrate to a supported train if you are on something older or unlisted. Treat this as an emergency change, not routine maintenance; the federal deadline of October 3 is a useful benchmark for everyone else too.
3. Get the Manager off the internet, whether or not you have patched
Cisco's interim mitigation for on-premises deployments is to restrict access from untrusted networks. If internet access is genuinely required, allow only known, trusted hosts on the ports and protocols in Cisco's user guides, and place the SD-WAN control components behind a firewall. Cisco's SD-WAN hardening guide goes further: administrative interfaces such as ports 443, 22, and 830 should not be exposed directly to the internet, and HTTPS access to the Manager should come only from a jump host or a dedicated management subnet. Cisco cautions that this mitigation should be tested in your environment before deployment, since filtering can affect legitimate traffic.
4. If you find evidence of compromise, look beyond the Manager
Admin access to SD-WAN Manager is a means to an end; the real targets are the routers and networks it controls. If your logs show suspicious access, review recent configuration and template changes pushed to edge devices, look for new or modified user accounts, and audit any policy changes affecting routing or traffic inspection. Rotate the Manager's administrative credentials and any secrets stored on it, and confirm that the earlier 2026 SD-WAN flaws are also patched, since several of those gave attackers root-level access and an intruder with admin rights would be well placed to chain them.
5. Strengthen monitoring for the next one
Send Manager logs to an external server and keep them long enough to support a real investigation; local logs on a compromised system are only as trustworthy as the attacker allows. Cisco has published Snort rule 67179 for this flaw, and major vulnerability scanners have added checks. Cisco's general hardening advice also applies: change the default administrator password, restrict use of the admin account, and give each administrator their own named account.
A note on the pattern
CVE-2026-76504 is not an isolated incident. It is the fifth Cisco SD-WAN zero-day exploited in the wild in 2026, and watchTowr counts eight Cisco SD-WAN CVEs added to CISA's KEV catalog this year alone.
| CVE | When flagged | What it allowed |
|---|---|---|
| CVE-2026-20127 | February 2026 | SD-WAN Manager information disclosure, exploited since at least 2023 |
| CVE-2026-20182 | May 2026 | Maximum-severity Controller authentication bypass to admin |
| CVE-2026-20245 | June 2026 | Root privileges on vulnerable systems |
| CVE-2026-20262 | June 2026 | Root privileges on vulnerable systems |
| CVE-2026-76504 | September 2026 | Unauthenticated admin access to the Manager API |
Jake Knott of watchTowr described the platform as a natural target given its role as the single console enterprises use to manage, configure, and monitor large networks, and predicted the run of attacks is unlikely to slow down. The lesson is not specific to Cisco: any system that centrally controls network infrastructure should be treated as a crown jewel. That means keeping its management interfaces off the public internet as a matter of course, logging it to somewhere an attacker cannot reach, and planning for the next emergency upgrade rather than reacting to it. Organisations that had already followed Cisco's hardening guidance this year were in a far better position on September 30 than those that had not.
Summary
| CVE | CVE-2026-76504 |
| Component | Cisco Catalyst SD-WAN Manager (formerly vManage), API session-based authentication |
| Type | Authentication bypass via improper handling of URL encoding (CWE-177) |
| CVSS | 9.8 (Critical) |
| Impact | Unauthenticated remote access to the Manager API as the admin user |
| Affected | All on-premises SD-WAN Manager releases below the fixed versions, regardless of configuration |
| Not affected / already fixed | Cisco SD-WAN Cloud (Cisco Managed) 20.15.605; Cloud Hosted environments have the mitigation deployed |
| Disclosed | September 30, 2026 (cisco-sa-sdwan-webauth-xr8beuuU) |
| Exploited in the wild? | Yes; Cisco became aware of active exploitation in September 2026 |
| Attribution | Not disclosed |
| CISA KEV? | Yes; added September 30, federal deadline October 3, 2026 |
| Workaround | None; interim mitigation is restricting network access to trusted hosts |
| Detection | j_security_check requests with encoded characters in service-proxy and vmanage-server logs; viptela-reserved- user activity; Snort rule 67179 |
| Full fix | Upgrade to 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1, 26.2.1, or later |
With confirmed exploitation, no workaround, and a federal deadline that lands tomorrow, this belongs at the top of the queue. Check the logs, capture diagnostics, upgrade, and pull the Manager off the internet; if anything in the logs looks wrong, assume the investigation extends to every device the Manager controls.
If you need help reviewing your SD-WAN Manager logs for signs of exploitation, assessing whether configuration changes were pushed to your edge devices, or locking down management access across your network, get in touch. The system that runs your whole network deserves more than a routine patch cycle.