Cisco dates the SD-WAN Manager attacks only as 'September', and omits five trains its May table listed

One month with no date, then three days with one

Cisco's advisory for CVE-2026-76504, a flaw that lets an unauthenticated attacker reach the Catalyst SD-WAN Manager API as the admin user, dates the attacks with one word: September. Cisco says its product security team "became aware of active exploitation" in September 2026, and it published the advisory on Wednesday 30 September at 13:00 GMT, which is 14:00 in the UK. Read literally, the gap between Cisco learning of the attacks and telling customers could be anywhere from 0 to 29 days. The attacks themselves could be older than Cisco's awareness.

The dated part is short. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalogue the same day with a due date of Saturday 3 October: three calendar days for US federal agencies, with forensic triage required. Cisco names six first-fixed releases, for the 20.9, 20.12, 20.15, 20.18, 26.1 and 26.2 trains, and scores the flaw 9.8 out of 10.

What that does not establish. It does not say when the attacks began, how many Managers were reached, who is behind them, or what anyone did with the admin access. It does not show that a fix exists for every release train in service: five trains that Cisco's May table listed are missing from this one, and Cisco's machine-readable record lists none of the six fixed trains as affected. And it does not say whether installing a fix removes an attacker who is already inside. Cisco's May and June advisories for related flaws said an update alone would not resolve a confirmed compromise. This one is silent either way.

This briefing reads Cisco's advisory and its machine-readable version, the CVE and NVD records, CISA's KEV record, Cisco's hardening guide and three earlier Cisco SD-WAN advisories, plus the two UK sources that matter. It stays at defender level: no request strings, no payloads, no exploitation steps. For the wider pattern it leans on three earlier briefings rather than restating them: Cisco's compromise hunting command that arrived 47 days before the exploitation statement, the three-day federal clock and what forensic triage requires, and Citrix NetScaler exploited before the patch.

What Cisco states, and what it does not

Cisco's advisory is short and specific about the flaw and the fixes. It is silent on almost everything a risk decision needs about the attacks. The table sets each statement against the gap beside it.

Stated and not stated in Cisco's advisory cisco-sa-sdwan-webauth-xr8beuuU, version 1.0, read in full on 30 September 2026. Quotations are from the advisory.

Topic	Stated by Cisco	Not stated
Exploitation	In September 2026 the PSIRT "became aware of active exploitation".	The day. When the attacks began. How many customers. Who. What the attackers did next.
How it was found	"During the resolution of a Cisco Technical Assistance Center (TAC) support case".	When that case opened, or whether the customer in it was a victim.
Who is exposed	Every Manager, "regardless of system configuration". Internet-exposed systems with exposed ports are at risk.	Which ports. Whether a Manager reachable only from inside is being attacked.
What the attacker gets	Access to the API "as the admin user".	Root on the host. Which API calls. Whether any edge device was changed.
Fixes	Six first-fixed releases, plus Cisco-managed cloud release 20.15.605, where no action is needed.	Any fix or path for trains 20.10, 20.11, 20.13, 20.14 and 20.16. Anything on Cloud-Pro or Government (FedRAMP).
Stopgap	No workaround. On premises, keep the Manager away from the internet and allow only known hosts. For Cloud Hosted the mitigation is "already deployed".	Whether Cloud Hosted Managers are also fixed, or only shielded.
Checking for compromise	Search two log files for the login path called from unknown addresses. Open a Severity 3 TAC case with the CVE ID in the title, after running request admin-tech.	A detection rule. Whether absence of the entries means clean. Whether an upgrade removes an intruder.
The example log lines	Two lines timestamped 29 September, about 23:11 US Central.	That they are real events. They use an example.com host name and private addresses, and Cisco calls them examples.

Cisco holds the compromise check. The advisory publishes two log searches and no detection rule, and routes everything else through a support case. Cisco makes the product and sells the support contract. That is no reason to doubt the advisory. It is a reason to know that the test beyond two log searches is one Cisco performs. Customers without a service contract are told to contact TAC with the product serial number and the advisory address as evidence of entitlement to a free upgrade.

The word zero-day is ours, not Cisco's. The advisory never uses it, and neither does CISA's record. Version 1.0 of the advisory carries the exploitation statement and the fixes together, and we found no earlier public report and no earlier fix. That is what the press means by zero-day. It is a statement about the order of public events, not about how long anyone was exposed or whether Cisco had a fix sooner.

The dates, to scale, with the arithmetic

Every date below comes from a page read in full. Times are UTC unless a source says otherwise. The diagram draws them to scale, which is the point: the window Cisco leaves undated is nearly ten times wider than the window anyone has been given to act.

The arithmetic, derived by us from the dated records. Calendar days unless stated.

Interval	Length	What it measures
1 Sep to 30 Sep	29 days	The widest gap Cisco's wording allows between learning of the attacks and publishing (to 13:00 on the 30th is 29 days 13 hours).
30 Sep to 30 Sep	0 days	The narrowest: Cisco learned of the attacks on the day it published.
19 Aug to 30 Sep	42 days	CVE ID reserved to publication. A batch reservation, not evidence of knowledge (see below).
13:00 to 13:17 UTC, 30 Sep	17 minutes	Advisory to the NVD record appearing. The CVE record followed at 13:04.
30 Sep to 3 Oct	3 days	KEV listing to the federal due date, which is a Saturday.

The 19 August date is a batch date. CVE.org shows CVE-2026-76504 reserved at 12:02:03 UTC on 19 August, the same second as CVE-2026-76460 and CVE-2026-76461, which are Cisco's Identity Services Engine and Secure Email Gateway flaws. Ids reserved in one second are bookkeeping. They do not show that Cisco knew of this flaw on 19 August.

The advisory's timing tells us about Cisco's process, not about the attacks. Cisco says it now publishes advisories on the first and third Wednesday of the month at 16:00 UTC, with exceptions for exigent circumstances such as observed exploitation. The 30th was the fifth Wednesday of September and the advisory went out at 13:00 GMT, so it was an exception on both counts. That is consistent with an out-of-cycle release for active exploitation. It says nothing about when that exploitation began.

Six trains fixed, five missing, and a machine record that lists none

Cisco gives a first fixed release for six on-premises trains. Set against what Cisco published before, two things stand out. First, every release that fixed June's flaw sits below this advisory's first fixed release in the same train, so a Manager upgraded in June to the latest fix is still affected. Second, five trains that May's table listed have no row at all.

First fixed releases by train. Sources: Cisco advisories of 4 June (CVE-2026-20245, revision 1.10), 14 May (CVE-2026-20182, version 2.0) and 30 September (this one). Not listed means the advisory has no row for that train.

Release train	Last fix Cisco listed before today	First fix in today's advisory
Earlier than 20.9	Migrate (May table)	Migrate to a fixed release
20.9	20.9.9.2 (June)	20.9.10.1
20.10	May table: move to 20.12.7.1	Not listed
20.11	May table: move to 20.12.7.1	Not listed
20.12	20.12.7.2 (June)	20.12.8.2
20.13	May table: move to 20.15.5.2	Not listed
20.14	May table: move to 20.15.5.2	Not listed
20.15	20.15.5.3 (June)	20.15.6.1
20.16	May table: move to 20.18.2.2	Not listed
20.18	20.18.3.1 (June)	20.18.4.1
26.1	26.1.1.2 (June)	26.1.2.1
26.2	In neither table	26.2.1

Four of the five missing trains carried an End of Software Maintenance footnote in May (20.11, 20.13, 20.14 and 20.16). 20.10 did not. That probably explains the absence, but the advisory does not say so. A Manager still on one of those trains is told nothing specific here beyond the general line to upgrade to the latest release, and Cisco states that its PSIRT "validates only the affected and fixed release information" in the advisory. NHS England Digital says deployments earlier than 20.9 are end-of-support. It does not address the five.

The machine-readable record points the other way. Cisco's CSAF file, and the CVE and NVD records built from it, list 23 affected versions of the Manager, from 17.2.4 to 18.4.3. All 23 fall under the "earlier than 20.9" row, where the human table says to migrate. None sits in any of the six trains that have a fix. NVD's default status for every other version is "unknown", and NVD was still analysing the record when read. A tool that matches installed versions against that list alone would be silent about a Manager on 20.12.7, which the human table says is affected. That last step is our inference about tools, not something Cisco states. Read the advisory's table, not the feed.

Cloud deployments are the other gap. Cisco's May and June advisories named four deployment types. This one names fewer, and treats them differently.

Deployment types as named in Cisco's May and June advisories and in this one.

Deployment	May and June advisories	This advisory
On premises	Named.	Fixed-release table, plus the stopgap of restricting access.
Cisco SD-WAN Cloud (Cisco Managed)	Named.	Fixed in 20.15.605. "No user action is required."
Catalyst SD-WAN Cloud Hosted	Term not used.	Stopgap "already deployed". No fixed release stated.
Cisco SD-WAN Cloud-Pro	Named.	Not named.
Cisco SD-WAN for Government (FedRAMP)	Named.	Not named.

The advisory does not say whether Cloud Hosted covers Cloud-Pro. Cisco's hardening guide describes a Cisco-hosted fabric on which the customer adds allow-list rules in a portal, which makes "already deployed" harder to read as a blanket guarantee. That is our reading of two documents, not a Cisco statement. If a provider runs your SD-WAN, ask in writing which deployment you are on, which release it runs and the date it was fixed.

Four names for one flaw, and none says what the account can do

A comforting label is not a control, and an alarming one is not a measurement. This flaw has been given four labels in a day.

Names used for CVE-2026-76504 and what each leaves out. Sources: Cisco advisory and CSAF file, CVE.org, CISA KEV, BleepingComputer.

The name	Used by	What it leaves out
API Authentication Bypass	Cisco's advisory title	A login rule is skipped. Not what the admin API can reach.
System Account Authorization Bypass	Cisco's own title in the CVE record and the CSAF file	A different word (authorization) and subject (system account) from the advisory's own prose, which says the admin user.
Hex Encoding Vulnerability	CISA's KEV entry, from CWE-177	Names the trick, not the consequence.
Escalate to admin privileges	BleepingComputer's description	Escalation implies the attacker already holds an account. Cisco says none is needed.

The admin user matters because of what Cisco says about its role elsewhere. The hardening guide says the netadmin role includes the admin user by default and its users are "permitted to perform all operations on the device". The advisory for this flaw says only "privileges of the admin user".

An earlier advisory shows what that role has been used for. Cisco's June advisory for CVE-2026-20245, a flaw that gives root commands on the Manager, says an attacker needs the netadmin role, which "would require valid credentials or exploitation of" two earlier unauthenticated flaws. It adds that Cisco "has observed limited cases where the exploitation of this bug resulted in a configuration change pushed to edge devices". The NCSC's alert of 25 February, issued with a hunt guide co-sealed by agencies in five countries, described actors adding a rogue peer to an SD-WAN, then working towards root access and persistence.

Inference, not stated by Cisco. An unauthenticated route to the admin API is a third way to meet the netadmin precondition that June's advisory names. Cisco has not said that anyone has chained CVE-2026-76504 to another flaw, or pushed anything to an edge device. The diagram shows what the same role was used for before, and nothing more.

One detail in the indicators deserves a second look. Cisco's log check for the second file looks for the login path being called "for users that include names starting with viptela-reserved-". The advisory points to Cisco's configuration guide for those "viptela-reserved system service accounts". Whether the exploit runs as such an account, or merely leaves that mark in the log, the advisory does not say. We suspect that is why the CSAF title says system account, but that is a guess and Cisco does not say.

A Manager is not a web application with a weak door. It is where the fabric is managed. The word bypass describes how an attacker gets in. It does not size what is inside.

9.8 from Cisco, and no second scorer yet

The only CVSS score in circulation is the one Cisco assigned. NVD lists it as a secondary source, and NVD has assigned nothing of its own.

Who has rated CVE-2026-76504, and what the rating is. Read from the NVD record, the CVE.org record, the advisory and NHS England Digital's alert on 30 September 2026.

Who	Rating	What it is, and is not
Cisco, as CVE numbering authority	CVSS 3.1 base score 9.8. Network, low complexity, no privileges, no user interaction, high impact on confidentiality, integrity and availability.	Base only. The advisory's vector leaves exploit maturity, remediation level and report confidence unset, although the same page says exploitation is active.
NVD	None yet. Status "Undergoing Analysis" from 19:02 UTC, having been "Received".	NVD had added no score of its own at 19:15 UTC.
CISA, in its Vulnrichment record (SSVC)	Exploitation active, automatable yes, technical impact total, stamped 17:40 UTC.	Not a CVSS score. These are three of the inputs to BOD 26-04's clock. The fourth, internet exposure of your asset, is yours to answer.
NHS England Digital	"Threat Severity: Medium" on alert CC-4861, 3:07 PM.	Its own scale, not explained on the page. It sits beside an assessment that further exploitation is "highly likely".

Do not let the gap between 9.8 and 10.0 set the order of work. Cisco scored its two earlier unauthenticated SD-WAN flaws, CVE-2026-20127 in February and CVE-2026-20182 in May, at 10.0. It scored CVE-2026-20245, the June flaw that needs netadmin first, at 7.8. That 7.8 was exploited, and Cisco saw it used to push configuration to edge devices. A score describes one flaw in isolation. It cannot see the chain it completes.

What the UK record says

Two UK sources matter, and they sit at different points in time.

NHS England Digital published cyber alert CC-4861 on 30 September at 3:07 PM, with no time zone stated. It lists the six affected trains and says its National Cyber Security Operations Centre assesses further exploitation as "highly likely". It tells organisations to complete the compromise assessment first, or to collect all relevant artefacts including a snapshot of the device and all logs, because patching first "may delete critical evidence". It asks for evidence of compromise to be reported to that centre immediately.

The NCSC had published nothing on CVE-2026-76504 in its news feed when read at about 20:15 BST. The newest item was the 28 September Citrix alert. Its standing alert on Cisco Catalyst SD-WAN, published on 25 February 2026, says management interfaces "must never be exposed to the internet" and asks UK organisations that believe they are compromised to collect artefacts and report to the NCSC. That alert concerns the February activity, not this flaw, and the hunt guide it links was written for that activity.

No source gives a UK count. Nobody has said how many UK organisations run an internet-exposed Manager, or how many have been attacked, and Cisco's advisory does not mention the UK. Cisco's own note is narrower: Managers with ports exposed to the internet are the ones it says are at risk.

Patched is not clean, and this advisory is quiet about it

Cisco's advisory asks customers to run request admin-tech before opening a TAC case. It does not say to run it before upgrading. Its May and June advisories for related flaws did say exactly that: collect admin-tech from each control component before upgrading, retain logs, and understand that if compromise is confirmed, an update alone will not resolve the problem. This advisory is silent on both.

Read the silence as a gap, not as a clearance. CISA's KEV record for this flaw requires forensic triage under BOD 26-04, whose guidance puts evidence collection ahead of patching, and NHS England says the same in its own words. The earlier briefing on the three-day clock sets out what triage means in practice, and the Citrix briefing shows why an appliance that has been patched is not proof of a clean one. The logs Cisco asks you to read are on the very host you are about to upgrade.

Cisco's habits differ by product. In the Firewall Management Center case (briefing 123) it shipped hunting indicators weeks before saying the flaw was exploited. Here the exploitation statement, the indicators and the fixes arrive together, in version 1.0. The gaps are elsewhere: dates, scope of the fixes, and what an upgrade does to an intruder.

What to do, in order

What we could not verify

The question this leaves

Cisco can name six releases that fix the flaw. It has not said which day it learned of the attacks, and the TAC case that exposed the flaw came before the advisory by a length of time nobody has stated. If an intruder reached your Manager before Cisco knew, which of your logs still reach back far enough to show it, and did anyone copy them off the host before last night?