CVE-2026-7473: Arista EOS Tunnel Decapsulation Protocol-Confusion Bypass — No Vendor Patch, Actively Exploited — Threadlinqs Intelligence
As of 2026-07-18, CVE-2026-7473: Arista EOS Tunnel Decapsulation Protocol-Confusion Bypass — No Vendor Patch, Actively Exploited is a critical-severity vulnerability threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 18 indicators of compromise.
Threat ID: TL-2026-1493 · Severity: CRITICAL · CVSS: 6.9 · Status: ACTIVE · Category: VULNERABILITY
Arista EOS R-series switches configured as tunnel endpoints (VXLAN, GRE, IP-in-IP, GUE) fail to validate the encapsulation protocol type of packets sent to their configured decapsulation IP, allowing
CVE-2026-7473 is a network-segmentation-bypass vulnerability (CWE-1023: Incomplete Comparison with Missing Factors) in Arista Extensible Operating System (EOS) affecting devices configured as tunnel decapsulation endpoints. When a switch is configured with a decapsulation IP for one tunnel protocol — for example a VXLAN VTEP, a GRE tunnel interface, or an `ip decap-group` for GUE/IP-in-IP — the switch checks only that the destination IP of an incoming encapsulated packet matches the configured decapsulation address. It does not verify that the outer packet's encapsulation protocol matches the protocol that was actually configured. As a result, a device configured only for VXLAN will also decapsulate and forward GRE and IP-in-IP traffic sent to the same address, and vice versa; GUE decap-groups accept GRE and IP-in-IP; IP-in-IPv6 decap-groups on R3-class hardware accept GREv6 and GUEv6.
An unauthenticated, network-adjacent or remote attacker exploits this by crafting a two-layer packet: an outer wrapper in ANY tunnel format supported by the platform's cross-decapsulation matrix, addressed to the switch's known decapsulation IP, wrapping an inner packet addressed to a protected internal host. The switch strips the outer wrapper without validating its protocol type and forwards the inner packet onto the internal network segment as if it were legitimately-tunneled traffic, using the switch itself as an unwitting relay that bypasses upstream firewalls, ACLs, and network segmentation that assume only the configured tunnel protocol can reach that endpoint.
The flaw is configuration-based rather than version-based: essentially all EOS releases from before 4.30.x through 4.36.x (and versions outside that range) are affected wherever tunnel decapsulation is configured on R-series hardware (7020R, 7280R/R2, 7500R/R2), with limited IP-in-IPv6/GUEv6 exposure on 7280R3, 7500R3, and 7800R3. This makes traditional version-based vulnerability scanning ineffective — detection requires auditing running configuration for decap-groups, VXLAN VTEP, and tunnel interfaces plus verifying upstream ACL coverage, which most commercial scanners cannot do.
Arista published Security Advisory 0137 on 2026-05-05 (last revised 2026-05-20) and explicitly stated no software fix is planned: changing decapsulation validation behavior risks breaking production deployments that implicitly rely on the current permissive behavior. CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog on 2026-06-09 based on confirmed in-the-wild exploitation, giving FCEB agencies until 2026-06-23 to mitigate under Binding Operational Directive 22-01/26-04. A public proof-of-concept, `arista_tunnel_bypass.py`, was published to GitHub by researcher fevar54, using Python/Scapy to craft cross-protocol tunnel packets and test/exploit the decapsulation matrix; Eclypsium's write-up notes the PoC was not independently validated by them but is publicly available and lowers the bar for exploitation.
Because there is no patch path, the only mitigations are network-layer: applying ingress ACLs on upstream devices permitting only the legitimate tunnel protocol/port to the decap IP (e.g., UDP/4789 for VXLAN, IP protocol 47 for GRE), or — on the decapsulating device itself — MAC ACLs with User-Defined Fields (requiring TCAM profile changes) on 7020R/7280R/7500R, or IPv6 PACLs on 7280R3/7500R3/7800R3. Organizations must first verify the decap IP carries no BGP, SSH, or management traffic before applying deny rules, and should enable per-entry ACL counters to monitor for exploitation attempts. This is a durable, patch-nonexistent exposure in data-center spine-leaf and financial-services network fabrics that will require permanent compensating controls.
Target sectors: finance, government administration, telecoms, data center cloud hosting, technology, critical infrastructure
Target regions: Global, North America
Detections & IOCs
As of 2026-07-28, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 18 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
VULNERABILITY, CRITICAL, threat intelligence, cybersecurity, CVE-2026-7473, T1595, T1590, T1587, T1190, T1562, T1599, T1036, T1572, T1046, T1040