Quick answer
Direct answer
What is Catalyst SD-WAN Manager?
Cisco Catalyst SD WAN Manager is the management product for a Cisco software defined wide area networking environment. It is relevant to the network administrators and security teams responsible for that environment. When you assess its exposure, think of it as a management system, not simply another web application.
The distinction matters because this vulnerability concerns access to the management API with admin privileges. Your assessment should therefore consider both the affected software and who can reach that API. An authentication boundary on a management system deserves particular attention because it separates ordinary network access from privileged interaction.
For your CTEM program, the immediate questions are practical: Do you operate this product, which releases are deployed, and what systems can connect to its management interface? Establish those answers before assuming that a familiar product name in an inventory tells you enough about the exposure.
CVE-2026-76504 at a glance
| Field | Detail |
|---|---|
| CVE ID | CVE-2026-76504 |
| Product | Cisco Catalyst SD-WAN Manager |
| Severity | CRITICAL |
| CVSS base score | 9.8 |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS probability | Not yet scored |
| CISA KEV | Yes, added 2026-09-30 |
| Weakness | CWE-177 |
| Affected versions | Catalyst Sd-Wan Manager before 20.9.10.1; Catalyst Sd-Wan Manager from 20.12 before 20.12.8.2; Catalyst Sd-Wan Manager from 20.15 before 20.15.6.1; Catalyst Sd-Wan Manager from 20.18 before 20.18.4.1; Catalyst Sd-Wan Manager from 26.1 before 26.1.2.1; Catalyst Sd-Wan Manager 26.2 |
| Published | September 30, 2026 |
CISA required action
What the flaw is
CVE-2026-76504 affects API session based authentication management. The supplied record identifies incorrect processing of URI encoding in an HTTP request as the cause. A specially constructed request can evade an authentication rule associated with a particular API endpoint. Successful exploitation gives the requester access to the API as the admin user.
Conceptually, URI encoding changes how characters in a request address are represented. The security problem is not encoding itself. It is the failure to enforce the intended authentication restriction when processing an encoded request. You should not infer the endpoint name, accepted encoding pattern, or internal processing sequence from this description. Those details are not supplied.
The assigned weakness category is CWE-177, which concerns improper handling of URL encoding. That classification helps explain the failure mode, but it is not a detection signature. Searching for encoded characters alone would not establish exploitation. You need context about the request, authentication processing, and any resulting privileged activity.
The record rates the vulnerability critical, with CVSS 9.8. Its vector describes network access, low attack complexity, no required privileges, and no required user interaction, with high potential impact on confidentiality, integrity, and availability. Those characteristics explain the urgency, but they do not prove that every deployment is reachable or that every affected system has already been compromised.
How an attack could happen
The following scenario illustrates the documented access path without providing a payload or exploitation procedure. Its essential condition is that an attacker can send requests to the API of an affected system.
- 1An attacker has network access to an affected Manager API. This does not have to mean public internet exposure. Your assessment should also consider access from internal networks, remote access environments, and other permitted sources.
- 2The attacker sends an HTTP request whose URI encoding causes the intended authentication restriction to be bypassed. The documented attack does not require a valid account or a user to approve an action.
- 3If exploitation succeeds, the attacker obtains API access with the privileges of the admin user. The important change is the transition from an unauthenticated requester to privileged access.
- 4Any subsequent activity depends on the available API capabilities and the environment. Investigators should examine what actually happened rather than assume particular configuration changes, stolen information, or broader network compromise.
Impact
The directly supported consequence is admin level access to the affected system through its API. That is an authentication boundary failure, not merely information exposure or a login inconvenience. Treat a suspected successful bypass as a potential privileged access incident.
The CVSS assessment indicates high potential consequences across confidentiality, integrity, and availability. For your organization, investigate which information and administrative operations were accessible. Do not turn those potential consequences into claims that data theft, configuration tampering, or service disruption occurred without supporting evidence.
CISA lists this vulnerability in its Known Exploited Vulnerabilities catalog, confirming exploitation in the wild. The catalog addition date supplied here is September 30, 2026. Ransomware involvement is marked unknown. That means you should prioritize an exploited vulnerability without claiming a ransomware campaign, a named threat actor, or a particular victim population.
Who is affected
The supplied affected release entries identify Cisco Catalyst SD WAN Manager before 20.9.10.1; releases starting at 20.12 and before 20.12.8.2; releases starting at 20.15 and before 20.15.6.1; releases starting at 20.18 and before 20.18.4.1; and releases starting at 26.1 and before 26.1.2.1. Version 26.2 is also explicitly listed as affected.
Use these entries as your initial comparison points, not as a substitute for Cisco release guidance. Preserve the distinction between the listed release ranges when assessing assets. Do not turn the entries into a blanket statement that every numerically later release is safe.
The supplied information does not identify a corrected release for the 26.2 entry. Check the Cisco advisory for the appropriate remediation path. Likewise, confirm supported upgrade destinations and any required prerequisites before scheduling a change for another release family.
Record the exact installed version, deployment owner, management addresses, and observed API reachability for each instance. A product entry without version evidence is unresolved, not cleared. A confirmed affected release with restricted access still needs remediation; the restriction changes exposure rather than correcting the authentication defect.
How to detect it
- Begin with deployment discovery. Reconcile software inventories with records held by network administrators and directly verified version information. Where inventories disagree, retain the asset as an open investigation until you can establish its actual release and owner.
- Assess internet exposure separately from internal reachability. Document which sources can connect to the API and which controls enforce that boundary. Do not assume a system is private merely because administrators usually access it through a private route.
- Review available HTTP and API records for unusual URI encoding associated with unexpected successful access. Treat this as an investigative lead, not a definitive signature. Ordinary requests can contain encoding, and the supplied facts do not provide a reliable matching pattern.
- Where logging permits, correlate requests with session creation, authentication decisions, admin activity, and source addresses. Look for privileged activity that you cannot explain through approved administration. Missing authentication records alone are not proof of bypass, especially when collection is incomplete.
- Preserve relevant logs and configuration evidence when you suspect compromise. The supplied record provides no endpoint specific indicators, forensic artifacts, or validated detection query. Consult the Cisco advisory and CISA forensic guidance, and do not interpret the absence of a simple alert as evidence of safety.
How to fix and reduce risk
Do this now
- Assign an accountable owner and confirm every potentially affected instance. Because exploitation is known, handle reachable affected systems as urgent work. Prioritize using verified exposure and operational importance rather than waiting for a predictive score.
- Consult Cisco's advisory for the supported remediation path for each release. The supplied affected ranges help identify candidates, but they do not provide a complete upgrade procedure or a corrected release for every listed entry.
- Follow applicable CISA requirements. The supplied KEV action calls for vendor directed mitigation, adherence to BOD 26-04 risk based update guidance, attention to forensic triage requirements, and an evaluation of each asset's internet exposure. Verify the applicable instructions rather than inventing a deadline.
- If compromise is suspected, coordinate remediation with incident response and evidence preservation. Repairing the vulnerable software does not, by itself, establish that earlier unauthorized access did not occur or that its consequences have been addressed.
If you cannot patch yet
- As an interim exposure reduction measure, consider restricting management API access to explicitly approved administrative sources. Test the restriction from relevant network locations and document exceptions. This is a defensive recommendation, not a verified Cisco workaround or a substitute for remediation.
- Do not assume stronger passwords or normal login controls block an authentication bypass. Evaluate controls that limit whether an attacker can reach the vulnerable interface, while checking the advisory for any vendor supported mitigation.
- If vendor mitigations are unavailable, the supplied CISA action includes discontinuing product use and following applicable cloud service guidance. Coordinate any isolation or service withdrawal with operational owners so the security response accounts for continuity requirements.
Longer term hardening
- Maintain an authoritative inventory of management systems, exact releases, owners, and permitted access paths. Review exceptions regularly so temporary connectivity does not silently become permanent exposure.
- Improve collection and retention of management API, authentication, and administrative activity records where supported. Define what evidence responders need before an incident, and test whether the available records can answer those questions.
- Require closure evidence that distinguishes software remediation, access restriction, and incident investigation. These are related activities, but completion of one should not automatically close the others.
The CTEM view
| CTEM stage | What to do for this CVE |
|---|---|
| Scope | Define the assessment around Cisco Catalyst SD WAN Manager deployments and their management access paths. Include the teams responsible for networking, security monitoring, change management, and incident response. Your scope should cover both internet exposure and other routes to the API, because network reachability is the relevant condition. |
| Discover | Find the systems, establish their exact versions, and compare them with the supplied affected entries. Record uncertainty explicitly. Ask administrators to reconcile missing or stale inventory data, and collect evidence of access controls rather than relying only on diagrams or intended network design. |
| Prioritize | Use known exploitation, unauthenticated access, and potential admin privileges as the main urgency signals. Then differentiate assets by observed reachability and business importance. No EPSS value or percentile is supplied, so do not report one or treat its absence as a reason to defer action. |
| Validate | Validate exposure and remediation through approved, non destructive checks. Confirm the installed release, review the vendor's guidance, and test whether intended access restrictions actually hold. Keep reachability testing separate from exploitation testing. You do not need to send an attack request merely to demonstrate that an affected API is accessible. |
| Mobilize | Translate findings into owned changes with documented dependencies, operational coordination, and completion evidence. Track vendor remediation, temporary restrictions, and forensic review separately. Close the exposure only when you have verified the applicable correction and resolved outstanding questions about access, exceptions, and suspected unauthorized activity. |
Key takeaways
- CVE-2026-76504 allows an unauthenticated remote attacker to gain admin access to the affected API by exploiting improper URI encoding handling.
- CISA KEV inclusion confirms exploitation in the wild. The supplied record does not establish ransomware involvement or identify a particular threat actor.
- Compare exact installed releases with the affected entries, and check Cisco guidance before declaring any upgrade destination suitable.
- Restricting API reachability can reduce exposure, but it does not fix the vulnerable authentication logic or replace vendor directed remediation.
- Use CTEM to connect discovery, exposure assessment, urgent remediation, and evidence based closure instead of stopping at a vulnerability alert.
Frequently asked questions
Related pages
CTEM Prioritization Signals
CTEM Prioritization: KEV, EPSS, CVSS, Business Impact
How to combine CVSS, CISA KEV, EPSS, reachability and business impact into a CTEM prioritization model your engineering teams will actually accept.
Zero Day CTEM Workflow
Zero Day Response Workflow with CTEM
A practical zero day response workflow built on CTEM: confirm the advisory, query the inventory, triage by exposure, mitigate, validate and verify closure.
Compensating Controls in CTEM
Compensating Controls in CTEM: When You Cannot Patch
How to use compensating controls in CTEM: five options when patching is impossible, validating that a control blocks the technique, and writing a defensible exception.
Vulnerability Management Learning Path
Free Vulnerability Management Training Path | LearnCTEM
Follow a free vulnerability management learning path covering CVSS, KEV, EPSS, prioritization, remediation, practical labs and CTEM certification.
Earn your free CTEM certification.
Learn to scope, prioritize, validate and mobilize fixes for CVEs like this one.
Beginner / Practitioner / Program Leader
Explore certificationsAuthor
LearnCTEM Editorial Team
Practitioners and educators writing plain-English guides on Continuous Threat Exposure Management.
Reviewed by
Senior CTEM Practitioner Panel
Reviewed for accuracy against public CTEM guidance and real-world program experience.

