CISA Flags Cisco, Chrome, and Arista Bugs as Actively Exploited, and One Won't Get a Patch

The U.S. Cybersecurity and Infrastructure Security Agency added three vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog on Tuesday, and one of them stands out for a reason that should make every network operator pay attention: the vendor has decided not to release a patch at all.

The three flaws span Cisco's Catalyst SD-WAN Manager, Google Chrome's V8 engine, and Arista's Extensible Operating System (EOS). All three are confirmed as being exploited in the wild, and Federal Civilian Executive Branch agencies have until June 23, 2026 to apply fixes or mitigations. That deadline is binding for federal agencies, but the KEV catalog has become a de facto priority list for private-sector defenders too, so the timeline matters well beyond government networks.

What landed in the catalog

The Cisco entry, CVE-2026-20245 (CVSS 7.8), is an improper output encoding flaw in Catalyst SD-WAN Manager. An authenticated local attacker can supply a crafted file and execute arbitrary commands as root. The authentication and local-access requirements limit who can reach it, but root-level command execution on the management plane of an SD-WAN deployment is a serious foothold once an attacker has any access at all.

The Chrome flaw, CVE-2026-11645 (CVSS 8.8), is an out-of-bounds read and write in the V8 JavaScript engine. A crafted HTML page can trigger arbitrary code execution inside the browser sandbox, which is the classic starting point for a browser-based attack chain. Google has shipped a fix, and if your Chrome hasn't restarted in a while, this is the nudge to do it. The bug was reported separately as a zero-day exploited in the wild, so the window between disclosure and the KEV listing was short.

The third entry is the one worth slowing down for.

Arista's EOS flaw, and the decision not to patch it

CVE-2026-7473 (CVSS 6.9) is described as an incomplete comparison with missing factors. In plain terms, when an Arista switch is configured to decapsulate tunneled traffic, it fails to verify the tunnel protocol type before stripping the outer header and forwarding the inner packet.

Here is why that matters. Tunnel decapsulation is a normal part of modern data center networking. A switch acting as a VXLAN tunnel endpoint (VTEP), a GRE tunnel endpoint, or an IP decap-group is supposed to receive encapsulated packets destined for its decapsulation IP, peel off the wrapper, and forward what's inside. The intended behavior is narrow: decapsulate only the specific tunnel type you configured.

The flaw breaks that boundary. As Arista put it, on affected platforms with a decapsulation configuration present, "the switch will incorrectly decapsulate and forward other unexpected tunneled packets with a destination IP matching its configured decapsulation IP." Because the switch doesn't check the protocol type, an attacker who can send traffic to the decapsulation IP can smuggle packets through using a tunnel type the operator never intended to accept. That can let traffic bypass segmentation that the network design assumed was airtight.

The affected hardware is specific: the 7020R, 7280R/R2, and 7500R/R2 series. Exploitation also requires the device to actually be configured as a tunnel endpoint with a decapsulation IP, so a switch with no decap configuration isn't exposed. Arista credited Comcast's Scott Christiansen, Lukas Peitz, Rich Compton, and Jonathan Davis for the disclosure, and confirmed the issue has been reported as exploited in the wild.

Despite the active exploitation, Arista said no patch is planned. The reasoning is that changing the decapsulation behavior could break existing customer configurations that, intentionally or not, rely on the current handling. That trade-off is uncomfortable but not unusual for forwarding-plane behavior, where a "fix" can silently drop legitimate production traffic. The vendor's position is essentially that the safer remediation lives in configuration, not in firmware.

How to actually mitigate it

Arista outlined two approaches, and both come down to filtering tunnel traffic with access control lists.

The first is to apply ACLs on upstream devices, blocking unexpected tunnel traffic before it ever reaches the switch acting as the decapsulation endpoint. The second is to apply ACLs directly on the affected device where the unwanted decapsulation is happening. In either case the goal is the same: explicitly permit only the legitimate tunnel traffic you expect, or explicitly block the tunnel types and sources you don't.

For most environments, the cleanest version of this is an allow-list. Identify the legitimate remote tunnel endpoints and the specific protocol you're using, permit exactly that, and deny the rest to your decapsulation IP. An allow-list ages better than a block-list because it doesn't depend on you anticipating every malicious variation an attacker might try.

The broader pattern worth taking away

This batch is a reminder that "exploited in the wild" doesn't always come with a one-click update. The Cisco and Chrome flaws follow the familiar model: vendor ships a patch, you deploy it, you move on. The Arista case forces a different posture, where the durable fix is a deliberate configuration change that you own and maintain.

There's also a useful lesson in how narrow the Arista exposure is. It only affects specific hardware, only when a decapsulation IP is configured, and only on the tunnel-endpoint role. That kind of precise scoping is exactly what lets defenders triage quickly. If you don't run those series as VTEPs or GRE endpoints, you can confidently set this one aside and focus your June 23 effort on the Cisco and Chrome updates instead.

The practical takeaways are straightforward. Update Chrome now and confirm the restart actually took. Audit Catalyst SD-WAN Manager access and apply Cisco's fix, paying attention to who holds local authenticated access since that's the precondition for the root command execution. And for Arista shops, inventory your 7020R, 7280R/R2, and 7500R/R2 switches for decapsulation configurations, then build the ACLs to scope tunnel traffic tightly. Treat the configuration change as the permanent fix, because in this case there isn't a patch coming behind it.