Arista EOS decapsulates tunnel traffic it was never configured for. No patch is planned.

What changed

Arista published Security Advisory 0137 on May 5 disclosing CVE-2026-7473, a tunnel decapsulation flaw in EOS running on the 7020R, 7280R/R2/R3, 7500R/R2/R3, and 7800R3 series. CISA added it to the Known Exploited Vulnerabilities catalog on June 9 with a federal remediation deadline of June 23. Active exploitation confirmed as a zero-day before the advisory published.

There will be no software fix. Arista has explicitly stated no software upgrade path is planned, because patching the protocol validation logic would break existing deployments that depend on the current decapsulation behavior. The remediation is ACLs.

What it means for your environment

The flaw lives in how EOS handles tunnel decapsulation. When a switch is configured as a decapsulation endpoint for VXLAN, GRE, or IP-in-IP tunnels, EOS validates whether the outer packet’s destination IP matches the configured decapsulation IP. It does not validate whether the tunnel protocol type matches what was actually configured.

An attacker who can reach the switch’s decapsulation IP can send a packet with any tunnel wrapper, destined to that IP, containing inner traffic targeting protected segments. The switch strips the outer wrapper and forwards the inner packet. That packet lands inside the trust zone: internal hosts, VRFs, overlay segments the segmentation architecture was supposed to make unreachable from the outside.

This is not one compromised host. The switch becomes the delivery mechanism for traffic that network segmentation was supposed to block. The CVSS score of 5.8 in v3.1 reflects low confidentiality impact on the vulnerable component in isolation. It does not reflect what happens when an attacker can inject arbitrary traffic into a spine-leaf fabric. The v3.1 vector includes Scope:Changed, which captures that the impact crosses the network boundary. The number still undersells it.

Arista 7280R and 7500R switches running VXLAN are a common backbone for large enterprise networks, financial services, and service providers. If your data center runs VXLAN-based overlay networking on affected hardware, you are in scope.

One more complication: most vulnerability scanners will miss this entirely. The vulnerability is not version-specific. Every EOS release on affected platforms is vulnerable. A scanner that checks EOS version and returns no findings has told you nothing useful here. The risk is configuration-dependent, and detection requires auditing the running configuration, not reading a version string.

What you need to do

Step 1: identify your exposed hardware. Affected series are 7020R, 7280R/R2, 7280R3, 7500R/R2, 7500R3, and 7800R3. The 7020R4, 7700R4, 7800R4, and cloud variants are not affected.

Step 2: find which devices are configured as tunnel endpoints. A device is in scope only if it has decapsulation configured. On each affected-series switch, run:

show vxlan vtep
show interfaces tunnel
show ip decap-group

If none of those return active configurations, the device is not exposed regardless of hardware series. EOS version is irrelevant to this determination.

Step 3: implement upstream ACLs. The cleanest mitigation is filtering at the upstream device feeding traffic toward the decapsulation endpoint. The ACL should permit only the specific tunnel protocol types actually configured on the downstream Arista switch, and deny everything else destined to the decapsulation IP.

For a VXLAN VTEP at the standard UDP port 4789: permit UDP to the VTEP IP on port 4789, deny all other IP traffic to that IP. Extend the permit list only for protocols you have explicitly configured. If you have both VXLAN and GRE configured, permit both. If you only configured VXLAN, permit only VXLAN.

Step 4: be cautious about applying mitigations directly on the Arista device. The alternative approach, MAC ACLs with User-Defined Fields on the affected switch itself, requires TCAM profile changes. Those changes are disruptive and the Arista advisory lists several caveats. Upstream ACLs are the right first choice for most environments.

Step 5: check your monitoring assumptions. If your segmentation monitoring assumes a given overlay segment is unreachable from external sources, verify that assumption. The indicator of compromise Arista identifies: unexpected traffic appearing on internal network segments that should only be reachable via configured tunnel types.

The window

Federal agencies have until June 23. That deadline reflects that exploitable configurations have been under active attack since before Arista’s May 5 advisory. The exploitation window was already open before operators knew the vulnerability existed.

For commercial environments: the practical question is which Arista 7000R deployments are running decapsulation, and whether upstream filtering restricts by protocol type, not just destination IP. Many VXLAN deployments are configured with ACLs that gate on VTEP IP without pinning the protocol. That gap is exactly what this vulnerability exploits.

Upgrading EOS will not help. There is no version to upgrade to. Every EOS release on affected platforms is vulnerable, and Arista has decided that remains the case permanently. The patching motion here is ACLs, not a software update, and your patch-management tooling probably doesn’t have a workflow for that. Build one.

This was discovered by Scott Christiansen, Lukas Peitz, Rich Compton, and Jonathan Davis at Comcast. It came from a team operating large-scale Arista infrastructure in production, which is consistent with how the zero-day exploitation materialized before Arista’s advisory.

This is exactly the kind of vulnerability that gets missed in a weekly patch review cycle: no software update to track, a scanner that returns clean, and a federal deadline that landed before most teams were looking. PatchDayAlert covers the daily KEV additions so this kind of remediation-without-a-patch scenario doesn’t disappear into the noise.