Cisco SD-WAN vEdge Software Access Control List Bypass Vulnerability
TL;DR 📌
- A vulnerability in the access control list (ACL) processing of IPv4 packets of Cisco SD-WAN vEdge Software could allow an unauthenticated, remote attacker to bypass a configured ACL. This vulnerability is due to the improper enforcement of the implicit deny all at the end of a configured ACL. An attacker could exploit this vulnerability by…
- Highest CVSS: 5.8 (Medium).
- Fix available — see the first fixed release below.
- CVEs: CVE-2025-20339.
What it is
CVE-2025-20339 sits in how Cisco SD-WAN vEdge Software processes IPv4 packets against configured access control lists. The flaw is in the enforcement of the implicit deny-all rule that should sit at the end of every ACL. Because that final deny isn’t properly enforced, traffic that should be dropped can instead pass through.
An attacker doesn’t need any credentials or prior access. They simply send unauthorised IPv4 traffic to an interface on an affected vEdge router; if that interface has an ACL configured, the traffic that should be blocked by the implicit deny gets through instead. This is a network-based, unauthenticated attack path (CVSS vector confirms AV:N, AC:L, PR:N, UI:N).
The outcome is an ACL bypass — the attacker doesn’t gain a foothold or execute code, but they can reach resources or services that the ACL was meant to protect. Cisco notes the real-world impact depends entirely on what that ACL was protecting in a given deployment, since the vulnerability affects Cisco SD-WAN vEdge Routers running the affected software regardless of how the device is otherwise configured.
Cisco has confirmed that Catalyst SD-WAN Manager (formerly vManage), IOS XE Software, IOS XE SD-WAN Software, and NX-OS Software are not affected. This is specific to vEdge Software running on vEdge Routers.
What to do
- Upgrade to the fixed release: 20.9.7 for the 20.9 train. Releases 20.8 and earlier, and 20.10 and later, are not vulnerable — only the 20.9 line before 20.9.7 is exposed.
- If you can’t patch immediately, apply Cisco’s workaround: determine which single ACL type best fits your requirements and configure only that one on the interface. Cisco states this was tested successfully in a lab environment, but you should validate it against your own configuration before deploying, as it can affect network functionality.
- Review what each ACL on your vEdge routers is actually protecting. Since the bypass impact is deployment-specific, prioritise patching or mitigating on interfaces where the ACL is your primary or only control.
- Treat the workaround as temporary. Cisco recommends upgrading to fixed software as the permanent fix rather than relying on the single-ACL-type workaround long-term.
Fixed releases
| Affected release | First fixed release |
|---|---|
| 20.9 | 20.9.7 |
For leadership ðŸ§
Executive summary. Any Cisco SD-WAN vEdge router running the affected 20.9 software before 20.9.7 can have its interface ACLs bypassed by unauthenticated network traffic, letting through whatever those ACLs were meant to block. There’s no known exploitation yet, but the fix and workaround are already published, so this should move into your next patch cycle rather than sit on a backlog.
Why it matters:
- The bypass requires no credentials and no user interaction — an attacker only needs network reach to an interface on an affected vEdge router.
- Impact depends entirely on what the ACL was protecting; if it’s your only control on a sensitive interface, the exposure could be significant.
- Only the 20.9 train before 20.9.7 is affected — 20.8 and earlier, and 20.10 and later, are not vulnerable, so scope is narrow but specific.
- Catalyst SD-WAN Manager, IOS XE, IOS XE SD-WAN and NX-OS are confirmed unaffected, so this is purely a vEdge router issue.
Now / Next / Later:
- Now: Identify which vEdge routers are running 20.9.x software and check whether their interface ACLs are the primary control protecting anything sensitive.
- Next: Upgrade affected vEdge routers to 20.9.7; where patching must wait, configure a single ACL type per interface as Cisco’s tested workaround, after validating it doesn’t break required traffic.
- Later: Once patched, drop the single-ACL-type workaround and build a standard check into vEdge upgrade planning so devices don’t linger on pre-fix 20.9 releases.