A flaw in Arista’s Extensible Operating System (EOS) lets a remote, unauthenticated attacker smuggle traffic straight through the perimeter of affected data-center switches, and the only fix is one you configure yourself. CVE-2026-7473 has been exploited in the wild as a zero-day, sits on CISA’s Known Exploited Vulnerabilities catalog with a federal remediation deadline of today, June 23, and Arista has stated plainly that no software patch will be released.

If you terminate VXLAN, GRE, or IP-in-IP tunnels on Arista hardware, this is a configuration emergency, not a routine patch cycle.

What happened

EOS is Arista’s Linux-based network OS, deployed on the high-performance switches that sit at the core of countless data-center, cloud, and enterprise fabrics. The bug (CVSS 6.9, CWE-1023 “Incomplete Comparison with Missing Factors”) lives in the forwarding pipeline’s tunnel-decapsulation logic.

When you configure a switch as a tunnel endpoint — via a decap-group, a GRE tunnel interface, or VXLAN — EOS programs the hardware to strip the outer header off any packet destined for the configured decapsulation IP. The problem: that decision is made on the destination IP alone. EOS never checks that the packet’s encapsulation protocol matches what you configured. In Arista’s own words, “a device configured to decapsulate one tunnel type will also incorrectly accept and decapsulate other tunnel protocols destined to the same IP address, even if those protocols were not explicitly configured.”

A switch set up only for VXLAN will happily decapsulate GRE or IP-in-IP packets aimed at the same address, and inject the inner payload directly into the routing or bridging plane.

Why it matters

This breaks the trust boundary operators assume when they restrict which tunnel types terminate on a switch. Exploitation needs no authentication and no user interaction: an attacker who can route packets toward the termination IP crafts an unexpected tunnel type, and the inner packet emerges inside the trust zone the switch serves. That means reaching internal hosts, sidestepping perimeter ACLs, and pivoting across VRFs and overlay segments — segmentation bypass against the exact gear meant to enforce it.

Arista lists the 7020R, 7280R/R2, and 7500R/R2 series as affected. Certain IP-in-IPv6 and GUE-over-IPv6 decap-group scenarios also reach the 7280R3, 7500R3, and 7800R3 platforms. Arista’s May advisory notes the issue “has been reported as being exploited in the wild,” and CISA added it to KEV on June 9 alongside the Chrome V8 (CVE-2026-11645) and Cisco SD-WAN (CVE-2026-20245) zero-days from the same batch.

No patch — by design

Unusually, Arista says it will not ship a fix: “No software upgrade path is planned to address this issue due to the risk of breaking existing configuration on deployments.” The vendor’s position is that enforcing protocol-type validation could disrupt working tunnel setups, so remediation is left entirely to the operator. (Note: an AI-generated third-party vulnerability page claims fixed releases exist — that contradicts Arista’s primary advisory, so treat the vendor statement as authoritative.)

What to do right now

Inventory every switch carrying decap-group, GRE tunnel, or vxlan configuration, and prioritize anything reachable from untrusted or partner networks. Then apply Arista’s mitigations:

  • Lock down the decap IP with ingress ACLs. Permit only the expected tunnel protocol (e.g. UDP/4789 for VXLAN) from known peer routers toward the termination IP, and explicitly deny GRE, IP-in-IP, and any other tunnel protocols to that address.
  • Constrain reachability of the termination IP to documented tunnel peers using infrastructure ACLs and uRPF where supported.
  • Terminate tunnels on a loopback that is not routable from untrusted networks, and limit advertisement of that prefix.

For detection, capture traffic at tunnel termination IPs and correlate the outer protocol against the configured type; alert on GRE/IP-in-IP counters incrementing on switches that should only see VXLAN, and on inner traffic appearing in VLANs or VRFs with no matching authorized outer flow.

Federal agencies are required to remediate by today. Everyone else should treat that deadline as the floor, not the target.

References: Arista Security Advisory 24005 (0137) · CISA KEV entry · SecurityWeek coverage