Arista EOS CVE-2026-7473 added to CISA KEV — vendor says no patch coming

CISA added CVE-2026-7473 to the Known Exploited Vulnerabilities catalog on June 9, 2026, giving FCEB agencies until June 23 to apply mitigations. The flaw is a tunnel-decapsulation logic error in Arista EOS that lets a remote attacker push arbitrary tunneled traffic at a switch configured to terminate one tunnel type — and have it accept and decapsulate the wrong one. Arista's Security Advisory 0137 confirms in-the-wild exploitation and states that no software fix is planned: the only remediation is ACL-based traffic filtering.

What the bug does

Per Advisory 0137, on platforms where any tunnel-decapsulation configuration is present — VXLAN, decap-group, or a GRE tunnel interface — the switch does not verify the tunnel protocol type before decapsulating. Any packet whose destination IP matches the configured decap address is decapsulated and forwarded, regardless of whether its outer encapsulation matches what the operator provisioned. Classification is CWE-1023 (Incomplete Comparison with Missing Factors). CVSS v3.1 is 5.8, CVSS v4.0 is 6.9.

The practical impact: an attacker reachable to a decap IP can inject traffic that bypasses the segmentation the tunnel was supposed to enforce. On a VXLAN fabric that's a route into a tenant network you don't belong on. On a decap-group used for service insertion, it's an opaque path past whichever device the group was meant to feed.

Affected products

Arista names the impacted hardware families in the advisory:

• 7020R series
• 7280R / 7280R2 series
• 7500R / 7500R2 series

Exposure is configuration-gated. A switch in this hardware family with no vxlan, decap-group, or gre tunnel-interface stanza in its running config is not in the exposed population.

Exploitation status

CISA's KEV addition is the authoritative "exploited in the wild" attribution. CISA does not publish the underlying telemetry source publicly for this entry. Arista's advisory acknowledges Scott Christiansen, Lukas Peitz, Rich Compton, and Jonathan Davis at Comcast for the report. No actor attribution is in either source — treat anything more specific as speculation.

Secondary coverage at SecurityWeek, The Hacker News, and SecurityAffairs repeats the KEV-sourced framing without adding telemetry beyond it.

Action checklist

1. Inventory. Pull every 7020R, 7280R/R2, 7500R/R2 from your CMDB. Grep their running configs for vxlan, decap-group, and any interface Tunnel with tunnel mode gre. Anything matching is in scope.
2. Apply ACLs at the decap IP. Arista's advisory documents two patterns — filter on the upstream device or on the decap switch itself. The intent is the same: pass only the tunnel protocol you actually configured, drop everything else destined to that decap IP. MAC ACLs work for cases where L3 filtering can't be expressed cleanly. Pull the exact ACL templates from Advisory 0137 — they are protocol- and platform-specific and we will not paraphrase them here.
3. Do not wait for a patch. Arista has stated in the advisory that no fix is planned because the corrected behaviour would break existing deployments. The mitigations are the remediation. CISA's June 23 due date applies to federal agencies; for everyone else, treat it as the operational floor.
4. Hunt. For any decap IP that is reachable from a network you don't fully control, pull NetFlow/sFlow for the period since the configuration was deployed. Tunneled traffic with an outer encapsulation that doesn't match the configured tunnel type is the indicator — same destination IP, wrong protocol header.
5. Re-segment if you can. Any decap IP that ends up reachable from a tenant or partner network is now a one-hop pivot into whatever sits behind the tunnel. The structural fix is not exposing the decap IP at all.

Context

CVE-2026-7473 fits a pattern that's become routine on enterprise switching gear in 2026: a logic flaw in a feature that predates the current threat model, exploited at the edge, and remediated only by configuration. Cisco's Catalyst SD-WAN Manager zero-day CVE-2026-20245 — also added to KEV in the same June 9 batch — followed the same disclosure cadence: vendor advisory, KEV addition, exploitation predating the public write-up. The difference here is that Arista won't fix it. That's a defensible engineering call when a patch would break deployed configs, but it transfers the remediation cost wholesale to operators, who now own ACL maintenance for the lifetime of every affected box. Anyone running EOS-based VXLAN fabrics should expect the next decap-class CVE on this platform to look the same: mitigation, not fix.