CVE-2026-76504 and Cisco's October 2026 Fixes: SD-WAN Manager, NX-OS, APIC and License On-Prem

11 October 2026 CiscoSDWANSecurityCVENX-OS

Two Cisco disclosures landed a week apart, and they are easy to blur together. On 30 September, Cisco confirmed that a Catalyst SD-WAN Manager authentication bypass is being exploited in the wild, and CISA put it on the Known Exploited Vulnerabilities catalog the same day. On 7 October, Cisco published a batch of 14 advisories covering 35 CVEs across NX-OS, APIC, License On-Prem, Meraki and Finesse. The batch contains the CVSS 10.0 score that most of the headlines led with. That score does not belong to the SD-WAN Manager bug, and the SD-WAN Manager bug is the only one in either disclosure with confirmed exploitation.

This post separates the two, covers what each one means for the gear most of us actually run, and ends with an order of work.

What is what

CVEProductCVSS 3.1ClassExploited?
CVE-2026-76504Catalyst SD-WAN Manager9.8CWE-177, URL encoding handlingYes, on CISA KEV
CVE-2026-76471NX-OS NX-API (Nexus 3000/9000)9.8Unauthenticated RCE as rootNo known exploitation
CVE-2026-76485, -76486, -76501Nexus 3000/9000 NGOAM9.8RCENo known exploitation
CVE-2026-76465Nexus 3000/9000 MPLS OAM9.8RCENo known exploitation
CVE-2026-76498, -76499, -76500APIC hardening release9.8 eachCWE-284, CWE-707, CWE-664No known exploitation
CVE-2026-76480, -76482, -76483, -76484License (Smart Software Manager) On-Prem9.8, 10.0, 9.1, 8.8CWE-306, CWE-347, CWE-522, CWE-94No known exploitation

CVE-2026-76482 is the CVSS 10.0. It is an improper cryptographic signature verification bug in License On-Prem, and Cisco’s advisory says its PSIRT is not aware of any malicious use. CVE-2026-76504 is a 9.8. Both are critical, but only one has attackers behind it today.

CVE-2026-76504: the exploited one

Cisco’s advisory describes a flaw in the API session-based authentication handling of Catalyst SD-WAN Manager. The product mishandles URL encoding in HTTP requests, which lets an unauthenticated remote attacker bypass an authentication rule that is meant to restrict access to a specific API endpoint. The result is access with the admin user’s privileges. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and Cisco says it applies regardless of configuration.

Cisco PSIRT became aware of active exploitation in September 2026. Cisco has not said who is exploiting it or how many systems were hit. CISA added the CVE to KEV on 30 September with a federal remediation deadline of 3 October, and that deadline has already passed. Decipher reports the flaw was found during a support case, which is a different origin from the internally discovered bugs in the 7 October batch.

There is no workaround. Cisco’s temporary guidance is to block access from unsecured networks, restrict any internet-facing access to known trusted hosts, and put control components behind a filtering device. Cisco is explicit that you should still patch.

Release trainFirst fixed release
Earlier than 20.9Migrate to a fixed release
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

Cisco SD-WAN Cloud (Cisco Managed) is already fixed in 20.15.605, with no customer action required.

Checking whether you were hit

Cisco published two log locations to search on the Manager. Both can match normal operations, so compare against your own baseline before drawing conclusions.

  • /var/log/nms/containers/service-proxy/serviceproxy-access.log: requests where the j_security_check path contains a percent-encoded character. Cisco notes that any single encoded character works, so do not search for one specific byte.
  • /var/log/nms/vmanage-server.log: requests to j_security_check tied to usernames starting with viptela-reserved-.

If either looks wrong, Cisco’s route is a Severity 3 TAC case with the CVE in the title and an admin-tech file from request admin-tech. If you want a quick sweep first, this runs against the access log path above:

grep -E 'POST /[^ ]*%[0-9A-Fa-f]{2}[^ ]*j_security_check|POST /%[0-9A-Fa-f]{2}[^ ]*_security_check' /var/log/nms/containers/service-proxy/serviceproxy-access.log

That pattern is mine, not Cisco’s, and it will miss variants. Treat a clean result as weak evidence.

How this fits the earlier SD-WAN Manager bugs

This is the fourth SD-WAN Manager advisory I have written up since August, and it is not the same bug as any of the others. Rapid7 makes the same point: CVE-2026-20127 and CVE-2026-20182 were peering authentication flaws in the vdaemon service, while CVE-2026-76504 sits on a separate API authentication path. The planes differ too. The peering bugs I covered in Declare Yourself Trusted were control plane. CVE-2026-20245 needed an authenticated CLI user. This one is the management plane web API, reachable by anyone who can send HTTP to the Manager. That is the argument in the three planes post: the management plane is where a failure gives away everything else.

I am not attributing this to the threat actor behind the earlier campaign. Cisco has not named anyone for CVE-2026-76504, and the earlier Mandiant reporting I relied on was careful about linking separate intrusions. I will not make a tighter claim than the vendor does.

There is also a patching detail worth checking against your own records. In Marking Its Own Homework I tabulated the fixed releases from Cisco’s August hardening advisory: 20.9.10, 20.12.8.1, 20.15.6, 20.18.4 and 26.1.2. Every one of those trains has now moved by one more rebuild, to 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1 and 26.1.2.1. If your Manager was patched to the August fixed release and nothing since, it is affected by CVE-2026-76504.

The 7 October batch

Cisco’s advance notice listed 14 advisories and 35 CVEs for 7 October. None of the critical ones below is known to be exploited, and Cisco says all were found in internal testing.

NX-OS: NX-API, NGOAM and MPLS OAM

Four critical advisories cover Nexus 3000 and 9000 switches in standalone NX-OS mode, with the vulnerable code gated behind a feature that has to be turned on.

  • CVE-2026-76471, NX-API. A crafted HTTP request to the NX-API can run arbitrary code as root, and the same defect can crash processes and reload the device. NX-API is disabled by default on Nexus 3000 and 9000. A related issue affects UCS 6300 Fabric Interconnects, where the UCS Manager XML API is on by default, but there exploitation needs valid low-privileged credentials. Cisco states there is no workaround. A Live Protect shield is available as a stopgap, and Cisco says the October hardening release does not replace the targeted upgrade for this CVE.
  • CVE-2026-76485, -76486, -76501, NGOAM. RCE in the NGOAM feature. CVE-2026-76501 applies only with SRv6 enabled, and CVE-2026-76486 also requires SRv6 or NV Overlay.
  • CVE-2026-76465, MPLS OAM. Does not affect Nexus 9000 models with Silicon One ASICs, which do not support MPLS OAM.

Nexus 7000 and Nexus 9000 switches in ACI mode are not affected by these four. Cisco does not name fixed releases in the advisory text I could read, so use the Cisco Software Checker for your platform. For the features that can be switched off, Cisco’s mitigation is to disable NGOAM, NX-API or MPLS OAM if you do not use them.

The first thing to find out is which of these features your switches have enabled:

show running-config | include ^feature
show feature | include nxapi
show feature | include ngoam

These are standard NX-OS commands, but I have not run them against the affected releases, so check the output on one switch before scripting it across a fleet. Automation is the usual reason NX-API is on. If a Nexus fabric is driven by Ansible or a vendor controller, expect to find it enabled on exactly the boxes you most care about.

NX-OS also gets a separate Security Hardening Release (cisco-sa-hardening-nxosw1-cWzSbtR) with six CVEs, including improper neutralization (CWE-707), improper access control (CWE-284, 9.8) and out-of-bounds read (CWE-125, 8.6). It affects NX-OS, NX-OS in ACI mode, and UCS Managed.

This is the second time this autumn that Nexus has been in the news. CVE-2026-20212 in September was an unrestricted bind on Silicon One Nexus 9000 models that exposed two TCP ports to unauthenticated root RCE. Different bug, same shape: management and automation surfaces on a data center switch being reachable by the wrong people.

APIC

The APIC Security Hardening Release (cisco-sa-hardening-apic-UOXWtfh) covers three CVEs, each scored 9.8 with AV:N/AC:L/PR:N/UI:N: CVE-2026-76498 (CWE-284, improper access control), CVE-2026-76499 (CWE-707, improper neutralization, the command and argument injection class) and CVE-2026-76500 (CWE-664, improper control of a resource through its lifetime). The vector means network reachable, no privileges, no user interaction. Cisco does not describe the specific impact of each bug, only the CWE class and the score, so any claim about exactly what an attacker gets is inference.

Cisco says it affects APIC regardless of configuration and offers no workarounds.

APIC releaseFirst fixed release
5.3 and earlierMigrate to a fixed release
6.06.0(9h)
6.16.1(6g)
6.26.2(3g)

Two lower-severity APIC advisories were published the same day: an API command injection (CVE-2026-20321, 6.5) and an unauthorized file access bug (CVE-2026-76488, 6.5).

License On-Prem

The License (Smart Software Manager) On-Prem hardening release (cisco-sa-hardening-ssm-Ph77wdhf) carries four CVEs: CVE-2026-76480 (CWE-306, missing authentication for a critical function, 9.8), CVE-2026-76482 (CWE-347, improper verification of a cryptographic signature, 10.0), CVE-2026-76483 (CWE-522, insufficiently protected credentials, 9.1) and CVE-2026-76484 (CWE-94, code injection, 8.8). The advisory-level score is 10.0 with scope changed (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).

Fix: 10-202609. Releases 10-202608 and earlier move to 10-202609, and 9-202601 and earlier, which is the old SSM On-Prem name, need to migrate to a fixed release. There is no workaround. Cisco Smart Licensing Utility is not vulnerable. A second License On-Prem advisory the same day lists four more CVEs, also critical, which I have not read in full.

A licensing server rarely gets the attention a firewall or a controller does. A missing-authentication bug and a signature-verification bug on the same box that holds your entitlement data and sits inside your management network deserves a patch window, even with no exploitation reported.

The AI line in the Source section

The APIC and License On-Prem advisories both say the bugs were found “during internal security testing using existing testing processes as well as frontier AI models”. It is the same wording I picked up in the Catalyst SD-WAN hardening advisory in August and the IOS XE one, so it now looks like a standing template rather than a one-off. The pattern across this week is worth stating plainly: the large batch of internally found bugs came out of a testing process that includes AI, and none is known to be exploited. The one bug with attackers on it was found in a support case.

That does not show AI-assisted discovery is finding the wrong bugs. It shows that finding bugs and fixing them at your site are two different queues, and the second queue is the one customers own. It is also the same point I made in The Judgment Gap Just Got Numbers, from the other direction: tools generate findings faster than teams can validate them, and a vendor hardening release is a findings backlog delivered to you in a single day. The AI Pentest Agents series covers the offensive side of the same problem.

What I would do, in order

  1. Patch the SD-WAN Manager first. It is exploited, there is no workaround, and the federal deadline passed on 3 October. Check which train you are on against the table above, and remember an August-level fixed release is no longer enough. Search the two logs for signs of prior abuse once it is patched, not before, so you are not investigating on a box that is still exposed.
  2. Take the Manager off any network that does not need to reach it. Cisco’s interim guidance is a firewall in front and a short allow list. That is worth doing permanently.
  3. Inventory NX-API, NGOAM and MPLS OAM on every Nexus 3000 and 9000. Turn off whatever is unused today. Plan upgrades for what must stay on, and use the Live Protect shield for NX-API if the window is far away.
  4. Schedule APIC to the fixed trains. No workaround exists, so a management-network ACL is your only compensating control while you wait.
  5. Patch License On-Prem to 10-202609, and if you are still on the 9-series, add a migration to the plan, because Cisco is not patching it.
  6. Re-read your patch baseline. If your standard says “latest fixed release from the last advisory”, this week showed that standard is already a rebuild behind on SD-WAN Manager.

Sources

Related Posts