~/f4n6 $ grep -r "Cisco Warns of Attackers Exploiting Critical Authentication Bypass in SD-WAN Manager" ./investigations/ --include="*.md"

Cisco Warns of Attackers Exploiting Critical Authentication Bypass in SD-WAN Manager

Jeff Davies 30 Sep 2026 9 min read

1. Executive summary

Cisco published an advisory on 30 September 2026 for CVE-2026-76504, an authentication bypass in Cisco Catalyst SD-WAN Manager that lets an unauthenticated, remote attacker reach the Manager API with the privileges of the admin user. The verified reference data records CVSS 9.8 (CRITICAL), CWE-177, and CISA KEV status with an addition date of 2026-09-30. Cisco PSIRT states the flaw is being actively exploited and became aware of the activity in September 2026; the flaw was found while Cisco TAC handled a support case. The vulnerability affects the product regardless of configuration, there is no workaround, and fixed releases exist. EMEA financial services running internet-facing Catalyst SD-WAN Manager should treat this as an emergency patch: the Manager is the management plane for the SD-WAN overlay, and admin-level API access is a path to the network fabric, not just to one appliance.

2. Regulatory framing

Article Trigger (the fact in this item) Practical impact
DORA Art. 17: ICT-related incident management process CVE-2026-76504 is in CISA KEV and Cisco states active exploitation; affected firms must determine whether their own Manager was accessed, not merely whether it was patched The incident management process has to run for exposure confirmation and any confirmed compromise, with the detection steps in §6 feeding it
DORA Art. 19: reporting of major ICT-related incidents to competent authorities A confirmed compromise of an internet-facing SD-WAN Manager grants admin-level API access to the management plane of the network If the incident meets the major-incident classification, the reporting clock runs from detection; log review in §6 is what establishes the detection point
NIS2 Art. 23: incident reporting obligations Same trigger: confirmed unauthorised admin access to a network management component Entities in scope must meet the NIS2 reporting timeline for a significant incident; the evidence needed is the same log set

DORA Art. 18 classification is engaged only once a firm has a confirmed incident to classify; it is not triggered by the existence of the CVE. No third-party or concentration article is engaged by this item on the facts available.

3. Technical analysis & attack chain

Confirmed steps, from Cisco's advisory as reported by Rapid7 and The Hacker News:

  1. The attacker sends a crafted HTTP request to the Catalyst SD-WAN Manager API. No credentials are required.
  2. The request encodes a single character in the request path. Cisco's example is POST /%6a_security_check HTTP/1.1, where %6a URI-encodes the letter j. Any single character in the path can be encoded, so %6a is one instance of the technique, not the technique itself.
  3. The Manager mishandles the URI encoding and the authentication rule that restricts access to that specific API endpoint is bypassed.
  4. The attacker reaches the API with the privileges of the admin user. By default the admin user holds the netadmin role, which is permitted to perform all operations on the device.

The affected component is the part of the Manager API that handles login sessions, specifically the j_security_check path. The verified reference data classifies the flaw as CWE-177 (improper handling of URL encoding); Rapid7's write-up describes the same root cause as improper handling of URL encoding, so the two classifications agree. The vulnerability affects the product regardless of system configuration. Cisco has not published a workaround.

Impact is bounded by what the admin API can do. Cisco's advisory does not state how many customers were attacked, when the attacks began, who carried them out, or what the attackers did with the access. Those four gaps are unresolved in the source material and should not be filled by inference.

Context that matters for prioritisation: this is the third authentication bypass in Cisco Catalyst SD-WAN control components in 2026. CVE-2026-20182 (May 2026, CVSS 10.0, CWE-287) and CVE-2026-20127 were both in the vdaemon service, reachable over DTLS on UDP port 12346, and Rapid7 found CVE-2026-20182 while researching CVE-2026-20127. CVE-2026-76504 is a separate issue on a separate API authentication path, not a patch bypass of either. The practical consequence is version arithmetic: the fixed releases for the May and June flaws are all older than the fixed releases for this one, so a Manager last upgraded for the May or June fixes still needs this update. The June flaws named in the source are CVE-2026-20245 and CVE-2026-20262.

Fixed releases for CVE-2026-76504:

Cisco Catalyst SD-WAN Software release 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

Cisco SD-WAN Cloud (Cisco Managed) is fixed in release 20.15.605 and Cisco states no customer action is required for that service. The advisory does not list the 20.10, 20.11, 20.13, 20.14 or 20.16 release trains, and does not name Cisco SD-WAN Cloud-Pro or Cisco SD-WAN for Government (FedRAMP), both of which appeared in the May and June advisories. Firms on those trains or deployments have no stated fixed release and should raise it with Cisco TAC rather than assume coverage.

Single-source caveat: the fixed-release table, the j_security_check log guidance and the CISA KEV entry are corroborated across the Cisco-derived reporting and the verified reference data. The exploitation timeline ("September 2026"), the TAC support-case origin, and the absence of any victim count or actor attribution rest on Cisco's advisory as relayed by Rapid7 and The Hacker News. No actor is named in any source and the verified reference data contains no MITRE ATT&CK profile for this activity, so attribution is unconfirmed. Do not attribute this to a named group on the material available.

4. Mitigation & containment

P1, within 24 hours:

  • Upgrade every internet-facing Catalyst SD-WAN Manager to the first fixed release for its train from the table in §3. Rapid7 recommends doing this outside the normal patch cycle. There is no workaround, so the upgrade is the remediation.
  • Until the upgrade completes, block access to the Manager from unsecured networks. Where internet access is genuinely required, restrict it to known, trusted hosts and place the control components behind a filtering device. Cisco states this mitigation is already in place in Catalyst SD-WAN Cloud Hosted environments and that it worked in a test environment; Cisco advises assessing its impact on your own network before applying it.
  • Pull the two log files named in §5 and search for j_security_check requests from unknown or unauthorised IP addresses. Treat any hit as a lead requiring correlation, not as proof: the same entries can appear during normal operation.
  • Confirm whether the Manager is reachable from the internet at all. Cisco's SD-WAN hardening guide states administrative interfaces, including ports 443, 22 and 830, should not be exposed directly to the internet, and that HTTPS access to the Manager should come only from a jump host or a management subnet.

P2, within 72 hours:

  • For any Manager with a confirmed or suspected bypass, open a Severity 3 TAC case with CVE-2026-76504 in the title and attach an admin-tech file generated with the request admin-tech command.
  • Rotate credentials and SSH authorised keys for the vmanage-admin account and any account with the netadmin role on affected Managers. Admin API access is sufficient to change device configuration, so treat credentials as exposed until the log review says otherwise.
  • Review configuration changes made on affected Managers over the exposure window, with attention to changes the operations team cannot account for.

P3, within 7 days:

  • Inventory every Catalyst SD-WAN Manager instance and record its release train against the fixed-release table. Flag any instance on 20.10, 20.11, 20.13, 20.14 or 20.16, or on Cloud-Pro or FedRAMP, as having no stated fixed release and escalate to Cisco.
  • Reconcile against the May and June 2026 fixes (CVE-2026-20182, CVE-2026-20127, CVE-2026-20245, CVE-2026-20262). A Manager patched for those is not patched for this.
  • Add the log paths in §5 to centralised collection if they are not already ingested, so the next authentication bypass in this product family is detectable without a manual pull.

5. Indicators of compromise

No atomic indicators (hashes, domains, IPs, file names) are present in the source material. The sources describe observable behaviours and log artefacts only.

type value confidence source
log path /var/log/nms/containers/service-proxy/serviceproxy-access.log high Cisco via Rapid7, The Hacker News
log path /var/log/nms/vmanage-server.log high Cisco via Rapid7, The Hacker News
http request pattern POST /%6a_security_check HTTP/1.1 high Cisco via Rapid7, The Hacker News
username prefix viptela-reserved- high Cisco via Rapid7, The Hacker News

Behavioural indicators:

behaviour where to observe confidence
Request to j_security_check with any single character URI-encoded in the path /var/log/nms/containers/service-proxy/serviceproxy-access.log high; %6a is Cisco's example, any single character can be encoded
Request to j_security_check associated with a username beginning viptela-reserved- /var/log/nms/vmanage-server.log high; these names belong to reserved system service accounts
Either of the above originating from an unknown or unauthorised IP address both log files high; Cisco states the same entries can occur during normal operation, so each match needs correlation against expected activity
logpath  /var/log/nms/containers/service-proxy/serviceproxy-access.log
logpath  /var/log/nms/vmanage-server.log
http_request  POST /%6a_security_check HTTP/1.1
username_prefix  viptela-reserved-

6. Detection

The source material gives log and request artefacts rather than file artefacts, so the Sigma rule below is the primary detection. A YARA rule is not appropriate here: there is no file, no hash and no distinctive in-file string to match on, and a rule keyed to the CVE identifier or the product name would detect reporting about the flaw rather than the flaw.

title: Cisco Catalyst SD-WAN Manager j_security_check Authentication Bypass Attempt
id: 8f4c1a92-3d7e-4b21-9c05-6a1e2f7b0d44
status: experimental
description: Detects HTTP requests to the Cisco Catalyst SD-WAN Manager j_security_check login path with a URI-encoded character, the technique used in CVE-2026-76504 to bypass the endpoint authentication rule. Also flags j_security_check requests tied to reserved viptela-reserved- service accounts.
author: Adverse Trace
date: 2026-09-30
references:

  - https://www.rapid7.com/blog/post/etr-critical-cisco-catalyst-sd-wan-manager-api-authentication-bypass-exploited-in-the-wild-cve-2026-76504
  - https://thehackernews.com/2026/09/cisco-warns-of-attackers-exploiting.html
logsource:
  category: webserver
detection:
  selection_encoded_path:
    cs-uri-stem|re: '(?i)/%[0-9a-f]{2}_security_check'
  selection_plain_path:
    cs-uri-stem|endswith: '/j_security_check'
  selection_reserved_user:
    cs-username|startswith: 'viptela-reserved-'
  condition: selection_encoded_path or (selection_plain_path and selection_reserved_user)
falsepositives:

  - Legitimate clients that percent-encode characters in the login path; Cisco states these entries can also appear during normal operation, so correlate each match against expected source IPs and usernames
level: high

For environments that ingest the Manager's own log files rather than a web server feed, the same logic applies to /var/log/nms/containers/service-proxy/serviceproxy-access.log and /var/log/nms/vmanage-server.log: alert on any j_security_check request with an encoded character in the path, and on any j_security_check entry for a viptela-reserved- account, then filter by source IP against the known management subnet or jump host.

CVE assessment

1 referenced CVE — 1 actively exploited (CISA KEV), 1 critical (CVSS ≥ 9.0)

CVE CVSS Exploited EPSS Summary
CVE-2026-76504 9.8 Critical ⚠ KEV 2026-09-30 — A vulnerability in the API session-based authentication management of Cisco Catalyst SD-WAN Manager could allow an unauthentica…

7. Sources

  • Cisco, security advisory for CVE-2026-76504, referenced via Rapid7 and The Hacker News (30 September 2026). The vendor advisory URL is not present in the supplied material.
  • Rapid7, "Critical Cisco Catalyst SD-WAN Manager API authentication bypass exploited in the wild (CVE-2026-76504)", https://www.rapid7.com/blog/post/etr-critical-cisco-catalyst-sd-wan-manager-api-authentication-bypass-exploited-in-the-wild-cve-2026-76504
  • The Hacker News, "Cisco Warns of Attackers Exploiting Critical Authentication Bypass in SD-WAN Manager", https://thehackernews.com/2026/09/cisco-warns-of-attackers-exploiting.html, 30 September 2026
  • Rapid7, "CVE-2026-20182: Critical authentication bypass in Cisco Catalyst SD-WAN Controller (FIXED)", https://www.rapid7.com/blog/post/ve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed
  • The Hacker News, "Cisco Catalyst SD-WAN Controller Auth Bypass Actively Exploited to Gain Admin Access", https://thehackernews.com/2026/05/cisco-catalyst-sd-wan-controller-auth.html
  • Cybersecurity Dive, "Attackers exploit critical flaw in Cisco Catalyst SD-WAN Controller", https://www.cybersecuritydive.com/news/attackers-exploit-critical-flaw-in-cisco-catalyst-sd-wan-controller/820368/
  • NVD / CISA Known Exploited Vulnerabilities, CVE-2026-20182, https://nvd.nist.gov/vuln/detail/CVE-2026-20182

8. Adverse Trace position

Adverse Trace assesses CVE-2026-76504 as CVSS 9.8 CRITICAL, CWE-177, and in CISA KEV as of 2026-09-30, with active exploitation stated by Cisco and no workaround available. The exposure is not confined to the Manager appliance: admin-level API access to the management plane is a route into the SD-WAN overlay, and this is the third authentication bypass in these control components this year, which tells us the product family is being worked on deliberately. Attribution is unconfirmed; no source names an actor and the verified reference data holds no MITRE ATT&CK profile for this activity, so we will not attribute it. The fixed-release table and the log guidance are corroborated across sources; the exploitation timeline and the absence of victim detail rest on Cisco's advisory as relayed by two outlets, and we flag that as single-sourced. Clients running internet-facing Catalyst SD-WAN Manager should upgrade to the fixed release for their train within 24 hours and run the j_security_check log review in parallel, because patching closes the door but does not tell you whether anyone came through it. We will track Cisco's advisory for a workaround, for fixed releases covering the 20.10, 20.11, 20.13, 20.14 and 20.16 trains and the Cloud-Pro and FedRAMP deployments, and for any victim or actor detail, and will reissue this note if that changes the assessment.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies