Cisco SD-WAN Zero-Day Attack: Why “Moderate” Vulnerabilities Are a Bigger Risk Than You Think

When a CVSS 10.0 zero-day attack hits, most teams react the same way: Where are we exposed, and how fast can we patch it?

But the recent Cisco Catalyst SD-WAN attack (CVE-2026-20127) exposed something critical. 

The most dangerous vulnerability in your system isn’t always the newest one. It’s often the one you’ve already deprioritized.

The Part You Can’t Afford to Overlook

This attack was a sequence, not a single exploit.

Attackers first used a zero-day to bypass authentication. Once inside, they deliberately downgraded the system’s software, reintroducing an older vulnerability (CVE-2022-20775) that had already been patched. 

That flaw (previously considered moderate risk) became the exact mechanism they needed to gain root access. Then, just as deliberately, they upgraded the system again to hide their tracks.

It’s an example of attackers moving beyond exploitation to manipulation of a software state over time.

Why Severity Scores are Incomplete

Severity scores are inherently limited – they reflect isolated conditions, not real-world attack paths.

In CISCO’s case, the older vulnerability was originally rated as “moderate” because it required authentication. Under normal assumptions, it wasn’t considered directly exploitable.

But those assumptions didn’t hold.

Once authentication was bypassed, the “moderate” vulnerability became critical. It’s a gap we see many teams still operating in:

• Severity reflects isolated conditions.
• Attackers exploit real-world combinations.

The real problem? Prioritizing the wrong thing.

Most software vulnerability management still follows a simple model: High severity gets attention. Everything else waits.

But attackers don’t think in terms of severity. They think in terms of paths.

They look for what can be chained, what can be reintroduced, and what becomes exploitable once one boundary fails. In that context, your backlog of “moderate” vulnerabilities isn’t noise, it’s opportunity.

Downgrade Attacks Change the Rules

The most sophisticated part of this breach was the decision to roll the system backward.

Security processes typically assume software only moves forward: patches are applied, vulnerabilities are removed, risk decreases over time.

This attack completely challenges that assumption.

By reverting to an older version, attackers effectively resurrected a vulnerability teams thought was no longer relevant. Then they erased the evidence.

It’s a reminder that security is as much about how deployment state can change and who controls those changes, as it is about what’s deployed.

Why “Shift-Left” Alone won’t Protect You

Most organizations rely on Software Composition Analysis (SCA) during development. This scans vulnerabilities CI/CD, flags issues, and blocks builds when necessary.

But this attack didn’t happen during development. It happened in production.

If your visibility stops at release, you won’t detect:

• Components being downgraded
• New attack paths emerging
• Previously “safe” vulnerabilities becoming exploitable

In other words, you’re securing a version of your system that no longer exists. The solution is to adopt an SCA tool that doesn’t just flag vulnerabilities, but helps you prioritize and understand the costs and effort to fix them. 

Zero-Days are Just the Entry Point

When a zero-day emerges, it dominates attention. Teams rush to identify exposure and prioritise fixes.

But in this case, the zero-day was simply the way in. The real damage came from what was already inside the system. 

The known vulnerability. The overlooked dependency. The assumption that something patched stays patched.

What Needs to Change

This incident highlights a broader shift in how software security needs to work.

It’s no longer enough to track vulnerabilities in isolation or prioritize them purely by severity. What matters is context – how components interact, how systems evolve, and how attackers move through them.

That requires:

• Continuous visibility into what’s actually running in production
• Awareness of version changes, including unexpected rollbacks
• Prioritization based on exploitability in context, not just CVSS scores

This is where modern SCA needs to evolve, from a static checkpoint into a continuous source of truth for your software environment. It’s why we’ve built Code Insights, a powerful SCA platform that gives engineering leaders visibility on vulnerabilities and risk hierarchy to help prioritize tasks. 

It delivers peace of mind that files in the codebase are continuously scanned – even after development and production – as new vulnerabilities constantly emerge.

How to Stay Secure

The Cisco SD-WAN attack is a demonstration of how attackers really operate.

They weaponize the vulnerabilities you already know about, combining them in ways your current processes aren’t designed to detect.

The risk? What you’ve already decided doesn’t matter.

To stay secure, you need full visibility over all vulnerabilities, not just “Critical” issues, with timely flagging so you can respond quickly. 

Code Insights gives you a clear view of your software dependencies.

See how continuous visibility into your code estate helps identify hidden vulnerabilities, version drift, and exploitable attack paths – before attackers do.

‍