Is our network affected if our SD-WAN system is hosted in Cisco's cloud?

Cisco's advisory says the flaw affects SD-WAN Manager regardless of configuration, and it describes two cloud cases. In Cisco Catalyst SD-WAN Cloud Hosted environments, the access-restriction mitigation is already deployed, but an upgrade to a fixed release is still needed. In Cisco SD-WAN Cloud (Cisco Managed), release 20.15.605 addresses the flaw with no user action required, and the version shows under Help in the service interface. Ask first which of the two you are on, then get written confirmation and a review of the logs covering the earlier period, because exploitation began before the fix was published.

We cannot upgrade tonight. What do we do in the meantime?

There is no workaround that fixes the flaw itself. For on-premises deployments, the mitigation Cisco describes is restricting access to the system from unsecured networks such as the internet, and protecting the SD-WAN control components behind a filtering device such as a firewall. That narrows who can reach it, but it does not replace the upgrade.

How do we know whether someone exploited the flaw on our network before we upgraded?

Cisco published indicators for your IT team to look for in serviceproxy-access.log and vmanage-server.log: requests to j_security_check from unknown addresses; any URI-encoded character in the request, such as %6a for the letter j, since Cisco says encoding any single character can be used; and, in vmanage-server.log, requests from unknown addresses for usernames beginning with viptela-reserved-, which are built-in service accounts, so the source matters, not the name. Keep a copy of the logs before upgrading, because, as CISA warned in a similar case this week, updates may erase some of the evidence.

We are not a government entity. Do the Essential Cybersecurity Controls apply to us?

They are binding on government entities and their affiliated companies, and on private sector entities that own, operate or host Critical National Infrastructure, and the NCA strongly encourages every other organisation to use them. Even if you are not bound, their clauses on third-party and managed service contracts are a practical checklist for your provider: incident notification procedures, a risk assessment before signing, and an obligation to follow your security policies.

Cisco SD-WAN Manager Is Under Active Attack: Who Patches Yours, You or Your Provider?

On 30 September 2026, at 4pm Riyadh time, Cisco published a security advisory for CVE-2026-76504 in Cisco Catalyst SD-WAN Manager, the system multi-branch companies use to run their whole branch network from a single screen. The severity score is 9.8 out of 10, exploitation needs no account and no password, Cisco says it became aware of active exploitation during September, and there is no workaround. The same day, Saudi Arabia's National Cybersecurity Authority (NCA) issued alert 2026-7889 at Critical severity, asking organisations to review the advisory and apply the update.

Two weeks ago we wrote about an exploited flaw in another Cisco appliance, the one that governs identity and access, and covered the basics of vulnerability management there. This time the most important question is not technical. You may not run your branch network at all: a telecom operator or IT firm may run it for you under a managed service contract. If so, who upgrades the system tonight, who checks whether anyone got in before the upgrade, and what does your contract say if neither happens?

What Cisco actually published

The news is hours old, so these facts come from Cisco's advisory and the NCA alert themselves, not from press write-ups:

Product: Cisco Catalyst SD-WAN Manager, formerly known as vManage. The advisory states it is affected regardless of how it is configured.
Cause: improper handling of URI encoding in HTTP requests lets a crafted request bypass an authentication rule meant to protect a specific API endpoint, so the attacker reaches the API with the privileges of the admin user.
Prerequisite: none. A remote, unauthenticated attacker, and a CVSS base score of 9.8.
Status: actively exploited. Cisco PSIRT says it became aware of exploitation in September 2026, and that the flaw was found while resolving a Cisco Technical Assistance Center support case.
Workaround: none. The fix is upgrading to a fixed release.
Local alert: NCA alert 2026-7889, dated 30 September 2026. It lists 14 target sectors, effectively all of them, from commerce and investment, finance and economy and healthcare to education, transportation and manufacturing.

The fixed releases, according to the advisory:

Current 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

Note the first row. Anyone on a release older than 20.9 is not looking at a small update but at a move to another release train. That takes planning, and it cannot wait.

Why this system in particular

An SD-WAN network links branches, warehouses and head office over whatever connections are available, and all of it is managed from one central system. That is where the policies are written: which traffic goes over which link, which branch can reach which system, and which settings are pushed to the router at every site. One change at the centre reaches every branch. That is the whole point.

The same feature is the danger. Whoever reaches this system's API with admin privileges is not facing one device but the console that manages the configuration of the entire network. The point of sale in a branch, the link to the warehouse and access to the accounting system from outside head office may all run over a network this system controls. It belongs at the top of the critical asset list, however far it seems from day-to-day management.

Cisco's cloud or your data centre? That decides who moves

The advisory distinguishes two ways of running the system, and the difference is very practical:

In Cisco's cloud: the advisory says the flaw affects SD-WAN Manager regardless of configuration, and it describes two cloud cases. In Cisco Catalyst SD-WAN Cloud Hosted environments, Cisco has already deployed the access-restriction mitigation, but a mitigation is not a fix, so the upgrade to a fixed release from the table above is still needed, and you should ask who carries it out. In Cisco SD-WAN Cloud (Cisco Managed), release 20.15.605 addresses the flaw, Cisco says no user action is required, and the version can be checked through the Help function in the service interface. Only in that last case is the upgrade on the vendor's side. Your job is still to get written confirmation and to ask for the logs to be reviewed for the period before it.
On premises, at your site or your provider's data centre: here nobody will upgrade the system for you unless the contract says so. Until the upgrade, the mitigation Cisco describes is restricting access to the system from unsecured networks such as the internet, and protecting the SD-WAN control components behind a filtering device such as a firewall.

So the first question is not whether you use Cisco. It is where your network management system runs and who owns upgrading it. If only the provider knows the answer, that is the first gap to close, and it is not a technical one.

An upgrade does not tell you whether someone got in first

Cisco learned of the exploitation during September and published the fix on the last day of the month. In other words, the flaw was being exploited before there was any update to apply. Upgrading tonight closes the door. It does not tell you whether someone already walked through it and left behind an account or a configuration change.

That is why Cisco published indicators for your IT team or provider to look for in two specific logs on the system, serviceproxy-access.log and vmanage-server.log:

Requests to j_security_check from unknown or unauthorised IP addresses.
Any URI-encoded character in the request path, such as %6a_security_check, where %6a is the letter j encoded. That is how the exploit slips past the authentication rule. Cisco stresses that %6a is only an example: encoding any single character in the request can be used, so the team should search for every encoded variant of j_security_check, not just %6a.
In vmanage-server.log specifically: j_security_check requests from unknown addresses made for usernames beginning with viptela-reserved-. These are built-in system service accounts, so the name appearing in the log is not in itself a sign of compromise. What matters is the unknown source.

Cisco also warns that these indicators can sometimes appear during normal operations, so they need to be compared against the network's usual activity before drawing conclusions.

The same lesson surfaced this week with two critical Citrix NetScaler flaws that the US Cybersecurity and Infrastructure Security Agency (CISA) added to its Known Exploited Vulnerabilities catalogue on 27 September. CISA said threat actors are actively exploiting them globally, encouraged organisations to check for signs of compromise before patching where possible, and said that any organisation suspecting compromise should preserve forensic evidence before applying updates, because updates may erase the traces of what happened. The rule applies here too: check, keep a copy of the logs, then upgrade, without letting the check become a reason to delay the upgrade for days.

If your network is a managed service: what does your contract say?

The NCA's Essential Cybersecurity Controls, 2024 edition, are binding on government entities and their affiliated companies, and on private sector entities that own, operate or host Critical National Infrastructure. The NCA strongly encourages every other organisation in the Kingdom to use them. Even if your company is not bound by them, they are the clearest local reference for what belongs in the contract of any provider who runs part of your technology:

In contracts with third parties that, if impaired, could affect your data or services, including service level agreements: non-disclosure and secure removal of your data at the end of the service, communication procedures when a cybersecurity incident occurs, and an obligation on the third party to apply your cybersecurity requirements and policies (control 4-1-2).
In contracts with IT outsourcing and managed service providers specifically: a cybersecurity risk assessment, with mitigation controls confirmed, before signing, and cybersecurity managed service centres for monitoring and operations that use remote access must be located entirely inside the Kingdom (control 4-1-3).
In vulnerability management: classifying vulnerabilities by severity and remediating according to that classification, subscribing to trusted sources for news of new vulnerabilities, and verifying updates in a non-production environment before applying them (control 2-10-3).

Notice what the vulnerability management controls do not say: they set no deadline for applying a critical update. That number has to be written into your own contract. Otherwise the provider patches when it can, not when you need it.

A message to send your provider today

You do not need to be technical to ask these questions, and you do not need to wait for a meeting. Ask for the answers in writing:

Does our network run on Cisco Catalyst SD-WAN Manager? And where does it run: in Cisco's cloud, at our site, or in your data centre?
Which release is it on, and when will it be upgraded to the fixed release, by date and hour?
Is the management interface reachable from the internet right now? If so, have you restricted access until the upgrade?
Have you checked the two logs Cisco named for the published indicators, and kept a copy before upgrading? What did you find?
Who told us about this alert first: you, or a news item we read? And what is the agreed procedure for notifying us next time?

The last question matters most. If you heard about the alert from an article rather than from your provider, the problem is bigger than this one flaw.

The Origami view

We build business systems. We do not sell or run network equipment. But every system we build for a multi-branch client runs on top of a network we did not design: the branch point of sale sends to the server, the warehouse updates stock, the e-invoice goes out to the platform. And the usual answer to the question of who patches the network is: the provider takes care of everything. It is a reassuring answer, and it is not an answer.

For a Saudi business owner, we read this flaw as a reminder that outsourcing moves the work but not the responsibility. A managed service is the right call for many companies, provided the contract contains three measurable things: a stated deadline for applying critical updates, written notice of every alert that affects your systems, and a report after every incident saying what was checked and what was found. Those clauses cost a good provider nothing, and they expose a weak provider before a vulnerability does.

Bottom line

If you run Cisco Catalyst SD-WAN Manager at your site or at your provider's, upgrading to the fixed release is urgent, not scheduled work, and releases older than 20.9 need a move to a fixed train.
Until the upgrade: block access to the system from the internet and put the control components behind a firewall, as the advisory describes.
Check both logs and keep a copy before upgrading, because exploitation began before the fix was published.
If the network is a managed service, send the questions above today, then add a critical-update deadline and a notification procedure to the contract at the next renewal.

Cisco SD-WAN Manager Is Under Active Attack: Who Patches Yours, You or Your Provider?