On affected platforms running Arista EOS where a tunnel decapsulation configuration—such as VXLAN (Virtual Extensible LAN), decap-groups, or a GRE (Generic Routing Encapsulation) tunnel interface—is present, the switch will incorrectly decapsulate and forward other unexpected tunneled packet with a destination IP matching its configured decapsulation IP. This occurs because the switch does not verify the tunnel protocol type, potentially leading to the unexpected processing of non-configured tunnel traffic.



This issue has been reported as being exploited in the wild.

Project Subscriptions

No data.

Advisories

No advisories yet.

Fixes

Solution

No software upgrade path is planned to address this issue due to the risk of breaking existing configuration on deployments. The recommended resolution of this issue is to follow the appropriate mitigation instructions detailed in the workaround block.


Workaround

There are two broad approaches to mitigate this issue - (1) applying ACLs on upstream devices or (2) applying ACLs on the devices where the unexpected decapsulation is happening. In both cases, the idea is to either selectively allow only legitimate tunnel traffic or to selectively block malicious tunnel traffic. For example, if a network is configured to forward VXLAN traffic, but GRE traffic is being unexpectedly forwarded, then ACLs can be used to either selectively allow just VXLAN traffic or selectively block GRE traffic. More details about using the ACL feature can be found in the  Arista User Manual https://www.arista.com/en/um-eos/eos-acls-and-route-maps#xx1150869 . A note of caution, the following ACL-based mitigation recommendations assume that the tunnel IP is dedicated solely to receiving the configured tunnel protocol traffic. When adapting these rules for your environment, it is important to explicitly permit any additional protocol traffic—such as BGP or SSH—if that IP serves multiple functions. To maintain connectivity, ensure these permit statements are sequenced before any deny statements directed at the decapsulation IP. The following configurations align with the recommendations outlined in the  Arista EOS Hardening Guide https://arista.my.site.com/AristaCommunity/s/article/arista-eos-hardening-guide#Comm_Kna_ka0Uw00000097VJIAY_71 .

History

Fri, 05 Jun 2026 16:45:00 +0000

Type Values Removed Values Added
Description On affected platforms running Arista EOS where a tunnel decapsulation configuration—such as VXLAN (Virtual Extensible LAN), decap-groups, or a GRE (Generic Routing Encapsulation) tunnel interface—is present, the switch will incorrectly decapsulate and forward other unexpected tunneled packet with a destination IP matching its configured decapsulation IP. This occurs because the switch does not verify the tunnel protocol type, potentially leading to the unexpected processing of non-configured tunnel traffic. This issue has been reported as being exploited in the wild.
Title Arista EOS Unexpected Tunnel Protocol Decapsulation and Forwarding Bypass
Weaknesses CWE-1023
References
Metrics cvssV3_1

{'score': 5.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N'}

cvssV4_0

{'score': 6.9, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N'}


Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: Arista

Published:

Updated: 2026-06-05T16:22:47.989Z

Reserved: 2026-04-29T20:08:22.118Z

Link: CVE-2026-7473

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-06-05T17:17:02.850

Modified: 2026-06-05T19:03:48.933

Link: CVE-2026-7473

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-05T17:30:45Z

Weaknesses