CVE-2026-7473: Arista EOS Tunnel Bypass Flaw Exploited in the Wild, No Patch Planned

Attackers are actively exploiting a design-level flaw in Arista's EOS network operating system that allows them to punch through network segmentation boundaries without authentication, credentials, or any user interaction — and Arista Networks has told its customers that no software patch will ever be released to fix it. The vulnerability, tracked as CVE-2026-7473, was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-7473) on June 9, 2026, confirming active in-the-wild exploitation. For enterprise network operators running Arista switches as tunnel endpoints — a common configuration in data centers and carrier networks — this is an urgent problem that demands immediate attention.

What Happened

On May 5, 2026, Arista Networks publicly disclosed Security Advisory 0137, detailing a vulnerability in how its EOS (Extensible Operating System) software handles tunnel decapsulation. The flaw was discovered by researchers Scott Christiansen, Lukas Peitz, Rich Compton, and Jonathan Davis at Comcast, and was reported to Arista through external disclosure. Arista tracks this internally as bugs BUG1086442 and BUG1519884.

The core problem is deceptively simple: Arista EOS switches that are configured to act as tunnel endpoints — meaning they unwrap or "decapsulate" encapsulated network traffic — fail to verify that incoming tunneled packets actually use the tunnel protocol they were configured for. A switch told to expect VXLAN traffic will happily unwrap GRE traffic, IP-in-IP traffic, or other tunnel types as well, as long as the destination IP address on the outer packet matches the switch's configured decapsulation IP. Think of it like a mail room that's been told to open packages addressed to "Suite 100" — but instead of checking whether the package is from an expected courier, it opens every package addressed to that suite regardless of who sent it or what delivery method was used.

What makes this particularly serious is Arista's extraordinary remediation stance: the company has explicitly stated that no software upgrade path is planned to fix this issue. The reason given is that a code-level fix carries too high a risk of breaking existing customer configurations. This means the vulnerability is, for all practical purposes, permanent in the affected hardware and software combinations, and the entire burden of mitigation falls on network administrators.

CISA's SSVC (Stakeholder-Specific Vulnerability Categorization) assessment of CVE-2026-7473 rates it with active exploitation, automatable attack delivery, and total technical impact — a combination that represents the agency's highest urgency tier for remediation, even though the raw CVSS score of 5.8 (Medium) might suggest otherwise to those who rely on scores alone.

Understanding the Vulnerability

The Technical Flaw: Incomplete Protocol Comparison (CWE-1023)

CVE-2026-7473 is classified under CWE-1023: Incomplete Comparison with Missing Factors, and its CAPEC category is CAPEC-272: Protocol Abuse. To understand why it matters, it's helpful to understand how network tunneling works.

In modern data center and carrier networks, operators use tunnel encapsulation to carry traffic across network boundaries. When a packet needs to travel from one virtualized environment to another, the original packet (the "inner" packet) is wrapped inside a new outer packet using a tunneling protocol. Common protocols include:

• VXLAN (Virtual Extensible LAN): Widely used in data center overlays, runs over UDP port 4789
• GRE (Generic Routing Encapsulation): A general-purpose tunneling protocol using IP protocol number 47
• IP-in-IP (IPoIP): Simple IP encapsulation using IP protocol numbers 4 (IPv4) or 41 (IPv6)
• GUE (Generic UDP Encapsulation): UDP-based encapsulation with configurable destination ports
• NVGRE: Network Virtualization using Generic Routing Encapsulation, used in some Microsoft environments

When a switch is configured as a tunnel endpoint, it receives these outer packets, strips off the encapsulation header, and forwards the inner packet to its destination — a process called decapsulation. A switch acting as a VXLAN Virtual Tunnel Endpoint (VTEP) should only accept and decapsulate VXLAN-encapsulated packets. A switch acting as a GRE endpoint should only decapsulate GRE packets.

In Arista EOS, the switch correctly identifies its configured decapsulation IP address but fails to verify that the tunnel protocol type of the arriving packet matches the protocol it was configured for. The hardware decapsulation engine matches solely on the destination IP, not on the combination of destination IP plus expected protocol type. This means that any tunnel protocol — configured or not — that arrives addressed to the decapsulation IP will be silently unwrapped and its payload forwarded into the internal network.

The Cross-Protocol Decapsulation Matrix

Arista's advisory provides a detailed breakdown of which unexpected tunnel types will be accepted based on what is configured on the switch. The full cross-protocol decapsulation exposure matrix is as follows:

Platform note: All scenarios in the table above apply to 7020R Series, 7280R/R2 Series, and 7500R/R2 Series. Only the IP-in-IPv6 Decap Group and GUE IPv6 Decap Group scenarios apply to 7280R3 Series, 7500R3 Series, and 7800R3 Series.

The Attack Chain: Step by Step

Exploiting CVE-2026-7473 requires no special tools, no credentials, and no prior access to the target network beyond the ability to route packets to the target decapsulation IP. The attack proceeds as follows:

Step 1: Identify a target Arista device acting as a tunnel endpoint. VXLAN VTEPs are extremely common in modern data center environments. The decapsulation IP is often associated with a loopback interface and may be discoverable through network reconnaissance, BGP route table inspection, or leaked configuration data.

Step 2: Determine the decapsulation IP address configured on the target device. This is the outer destination IP that the switch listens on for tunnel traffic.

Step 3: Construct malicious tunneled packets using a protocol different from the one the target is configured for. For example, if the target is a VXLAN VTEP (listening on UDP port 4789), the attacker crafts GRE or IP-in-IP encapsulated packets addressed to that same VTEP IP address.

Step 4: Transmit the crafted packets to the target decapsulation IP from any point on the network that can reach it.

Step 5: The Arista switch's hardware decapsulation engine receives the packets, matches on the destination IP, strips the outer tunnel header, and forwards the inner payload directly into the internal network segments — the same segments that are supposed to be accessible only to properly encapsulated, authorized traffic.

The result is that an attacker sitting outside the intended network boundary can inject arbitrary packets directly into internal network segments, bypassing the access controls that network segmentation was designed to enforce. The CVSS 3.1 score for this vulnerability is 5.8 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N. The CVSS 4.0 score is 6.9 (Medium) with 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. While neither score sits in the "Critical" range, the changed scope component (S:C in CVSS 3.1) reflects the reality that a successful attack reaches well beyond the initially compromised component — a hallmark of network segmentation bypass vulnerabilities whose real-world impact significantly exceeds what the base score implies.

Who Is Affected

Arista EOS is the operating system powering Arista's line of data center, campus, and service provider switches. The Arista 7000 series — particularly the 7280R and 7500R lines — is widely deployed in hyperscale data centers, financial institutions, telecommunications providers, cloud service providers, and large enterprise networks. These are not edge devices or home routers; they are core and aggregation switches that sit at the heart of some of the world's most sensitive network infrastructures.

Critically, a device is only vulnerable if it is configured as a tunnel endpoint. A device that does not perform tunnel decapsulation is not exposed. To confirm whether a device is vulnerable, administrators should run the following diagnostic commands:

Check for VXLAN VTEP configuration:

1switch>show interfaces vxlan 1
2 Vxlan1 is up, line protocol is up (connected)
3   Source interface is Loopback1 and is active with 10.0.0.1
4   Listening on UDP port 4789
5   ...

If the output contains Source interface is <interface> and is active with <IP>, the device is acting as a VXLAN VTEP with <IP> as the tunnel termination address, and is potentially impacted.

Check for GRE tunnel interface configuration:

1switch>show interfaces Tunnel0
2 Tunnel0 is up, line protocol is up
3   Hardware is Tunnel
4   Tunnel source 1.1.1.1, destination 1.1.1.2
5   Tunnel protocol/transport GRE/IP
6   ...

If the tunnel interface is up with a source and destination, the device is a GRE tunnel endpoint and is potentially impacted.

Check for decap-group configuration:

1switch>show ip decap-group

If none of the above commands show the presence of any tunnel endpoint configurations, the device does not perform tunnel decapsulation and is not exposed to this issue.

Real-World Risk

CISA confirmed active exploitation of CVE-2026-7473 on June 9, 2026, when it added the vulnerability to its KEV catalog. The identities of the threat actors and campaigns actively exploiting the vulnerability in the wild remain unknown at this time, as does the precise date exploitation began — Arista's advisory, published May 5, 2026, stated only that the issue "has been reported as being exploited in the wild." What is known is that exploitation was underway before public disclosure, meaning attackers had a window to operate without defenders being aware of the attack vector.

While the CVSS integrity impact is scored as "Low" — reflecting that a single exploit attempt injects traffic rather than directly exfiltrating data or crashing systems — the real-world consequences of successful exploitation can be severe and cascading:

Network Segmentation Bypass: The fundamental promise of network segmentation — that traffic between zones is controlled by firewalls, access control lists, and routing policy — is broken. An attacker who can route packets to a VTEP or GRE endpoint IP can inject traffic directly into internal VLANs, VRFs, or overlays that are supposed to be reachable only by authorized tunnel traffic. In a data center environment, this could mean reaching production databases, control plane systems, or internal management networks.

Lateral Movement Enablement: Once an attacker can inject traffic into an internal segment, they can probe and interact with hosts and services that were never intended to be reachable from the external network. Internal services that assume network-layer trust — services that lack strong application-layer authentication because they rely on "being inside the network" as a security control — become directly accessible.

Internal Network Reconnaissance: Even without exfiltrating data directly, the ability to inject traffic into internal segments allows attackers to map internal network topology, identify vulnerable or unpatched internal services, and establish a persistent foothold for follow-on attacks.

Infrastructure Targeting: The specific hardware affected — the Arista 7280R, 7500R, and 7800R series — is routinely deployed in carrier and service provider networks. Exploitation in those environments could affect network infrastructure that carries traffic for thousands of downstream customers.

The CISA SSVC assessment's designation of "total technical impact" reflects the breadth of what becomes possible once an attacker can bypass network segmentation, even if the direct vulnerability itself is rated moderate.

What You Should Do

Because Arista has explicitly stated that no software fix will be released, mitigation through access control lists (ACLs) is the only available remediation path. Arista has documented two broad approaches. Approach 1 (upstream ACLs) is strongly preferred and carries significantly lower operational risk.

Step 1: Identify All Vulnerable Devices

Before deploying any mitigations, conduct a full inventory of your Arista EOS environment to identify every device running in a tunnel endpoint role. Use the commands documented above (show interfaces vxlan 1, show interfaces Tunnel <id>, show ip decap-group) on every Arista device in your network. Prioritize devices reachable from untrusted or semi-trusted network segments.

Step 2 (Recommended): Apply ACLs on Upstream Switches — Approach 1

The safest and most operationally sound mitigation is to apply ACLs on the upstream devices that forward traffic toward the vulnerable Arista decapsulation endpoints. This approach whitelists only legitimate tunnel protocol traffic to the decapsulation IP and drops everything else, without touching the vulnerable switch itself.

Important caveat from Arista: These ACL recommendations assume that the tunnel IP is dedicated solely to receiving the configured tunnel protocol traffic. When adapting these rules for your environment, you must explicitly permit any additional protocol traffic — such as BGP or SSH — if that IP serves multiple functions. Ensure permit statements for those protocols are sequenced before any deny statements directed at the decapsulation IP.

The following are the complete, ready-to-deploy ACL configurations from Arista's official advisory for each tunnel type:

ACL to Permit VXLANv4 Only

This IPv4 ACL matches on VXLAN packets:

• (a) IP next protocol = UDP (17)
• (b) IP DIP = VXLAN VTEP IP
• (c) UDP destination port = VXLAN UDP Port (4789)

It allows VXLAN packets and drops all other packets to the VXLAN Decap IP.

1ip access-list foo
2   counters per-entry
3   1 permit udp any host <vxlan-decap-ip> eq 4789
4   2 deny ip any host <decap-ip>
5   3 permit ip any any

ACL to Permit GREv4 Only

This IPv4 ACL matches on GRE packets:

• (a) IP next protocol = GRE (47)
• (b) IP DIP = GRE Tunnel Destination IP

It allows GRE packets and drops all other packets to the GRE Decap IP.

1ip access-list foo
2   counters per-entry
3   1 permit gre any host <gre-decap-ip>
4   2 deny ip any host <gre-decap-ip>
5   3 permit any any

ACL to Permit IP-in-IPv4 Only

This IPv4 ACL matches on IP-in-IPv4 packets:

• (a) IP next protocol = IPv4 (4) or IPv6 (41)
• (b) IP DIP = IP-in-IP Decap IP

It allows IP-in-IPv4 packets and drops all other packets to the IP-in-IPv4 Decap IP.

1ip access-list foo
2   counters per-entry
3   1 permit 4 any host <ipip-decap-ip>
4   2 permit 41 any host <ipip-decap-ip>
5   3 deny ip any host <ipip-decap-ip>
6   4 permit any any

ACL to Permit IP-in-IPv6 Only

This IPv6 ACL matches on IP-in-IPv6 packets:

• (a) IP next protocol = IPv4 (4) or IPv6 (41)
• (b) IP DIP = IP-in-IP Decap IP

It allows IP-in-IPv6 packets and drops all other packets to the IP-in-IPv6 Decap IP.

1ipv6 access-list foo
2   counters per-entry
3   1 permit 4 any host <ipip-decap-ip>
4   2 permit 41 any host <ipip-decap-ip>
5   3 deny ipv6 any host <ipip-decap-ip>
6   4 permit ipv6 any any

ACL to Permit GUEv4 Only

This IPv4 ACL matches on GUE packets:

• (a) IP next protocol = UDP (17)
• (b) IP DIP = GUE Decap IP
• (c) UDP destination port = UDP port configured per payload (IP = Y or MPLS = Z)

It allows GUE packets and drops all other packets to the GUE Decap IP.

1ip access-list foo
2   counters per-entry
3   1 permit udp any host <decap-ip> eq Y
4   2 permit udp any host <decap-ip> eq Z
5   3 deny ip any host <decap-ip>
6   4 permit ip any any

ACL to Permit GUEv6 Only

This IPv6 ACL matches on GUEv6 packets:

• (a) IP next protocol = UDP (17)
• (b) IP DIP = GUE Decap IP
• (c) UDP destination port = UDP port configured per payload (IP = Y or MPLS = Z)

It allows GUE packets and drops all other packets to the GUE Decap IP.

1ipv6 access-list foo
2   counters per-entry
3   1 permit udp any host <decap-ip> eq Y
4   2 permit udp any host <decap-ip> eq Z
5   3 deny ipv6 any host <decap-ip>
6   4 permit ipv6 any any

Step 3 (Last Resort Only): Apply ACLs Directly on the Vulnerable Decapsulation Switches — Approach 2

This approach is highly disruptive and carries significant risk of permanently breaking existing network features. It should only be attempted if upstream ACL deployment is impossible, and only with direct involvement of Arista TAC. TCAM profile changes are disruptive operations that can impact live traffic forwarding.

Applying ACLs directly on the decapsulation device requires MAC ACLs with User Defined Fields (UDFs) on 7020R, 7280R/R2, and 7500R/R2 series, or IPv6 PACLs on 7280R3, 7500R3, and 7800R3 series. In both cases, a TCAM (Ternary Content-Addressable Memory) profile update is required.

The TCAM is the specialized hardware in these switches that enables line-rate packet forwarding and ACL matching. It has finite capacity, and adding new UDF qualifiers to support protocol-level matching requires removing other existing features from the profile. Depending on your configuration, the trade-offs may include losing support for MPLS forwarding, VXLAN routing, or Policy-Based Routing (PBR) — features that may be critical to your network operation.

TCAM Profile Changes for 7020R, 7280R/R2, 7500R/R2 Series

Option A — IPv4 tunnel UDF qualifiers, removes MPLS support:

1hardware tcam
2   profile test copy default
3      feature acl port mac
4         no key size limit 
5         key field udf-16b-1 udf-16b-2 udf-32b-1
6      no feature mpls
7      no feature mpls pop ingress
8      no feature pbr mpls

Option B — IPv4 tunnel UDF qualifiers, removes VXLAN support:

1hardware tcam
2   profile test copy default
3      feature acl port mac
4         no key field src-mac
5         key field udf-16b-1 udf-16b-2 udf-32b-1

Option C — IPv6 tunnel UDF qualifiers, removes VXLAN and PBR support:

1hardware tcam
2   profile test1 copy default
3      feature acl port mac
4         no key size limit
5         no key field src-mac dst-mac
6         key field udf-16b-1 udf-16b-2 udf-32b-1 udf-32b-2 udf-32b-3 udf-32b-4
7      no feature tunnel vxlan
8      no feature tunnel vxlan routing
9      no feature pbr ip
10      no feature pbr ipv6

MAC ACL Configurations for 7020R, 7280R/R2, 7500R/R2 Series (After TCAM Profile Update)

MAC ACL to Permit VXLAN v4 Decap Only: This MAC ACL uses UDF to match on VXLAN packets:

• (a) IP next protocol = UDP (0x11)
• (b) IP DIP = VXLAN VTEP IP (converted to hex as 0xXXXXXXXX)
• (c) UDP destination port = VXLAN UDP Port (0x12b5)

It allows VXLAN packets and drops all other packets to the VXLAN Decap IP.

1mac access-list payload alias ip-next-protocol-udp offset 2 pattern 0x00110000 mask 0xff00ffff
2 
3mac access-list payload alias ip-dip-decap-ip offset 4 pattern 0xXXXXXXXX mask 0x00000000
4    
5mac access-list payload alias udp-dport-vxlan offset 5 pattern 0x000012b5 mask 0xffff0000
6    
7mac access-list foo
8   counters per-entry
9   1 permit any any ip payload alias ip-next-protocol-udp alias ip-dip-decap-ip alias udp-dport-vxlan
10   2 deny any any ip payload alias ip-dip-decap-ip
11   3 permit any any

MAC ACL to Permit GREv4 Decap Only: This MAC ACL uses UDF to match on GRE packets:

• (a) IP next protocol = GRE (0x2f)
• (b) IP DIP = GRE Decap IP (converted to hex as 0xXXXXXXXX)

It allows GRE packets and drops all other packets to the GRE Decap IP.

1mac access-list payload alias ip-next-protocol-gre offset 2 pattern 0x002f0000 mask 0xff00ffff
2 
3mac access-list payload alias ip-dip-decap-ip offset 4 pattern 0xXXXXXXXX mask 0x00000000
4 
5mac access-list foo
6   counters per-entry
7   1 permit any any ip payload alias ip-next-protocol-gre alias ip-dip-decap-ip
8   2 deny any any ip payload alias ip-dip-decap-ip
9   3 permit any any

The GRE MAC ACL can optionally be extended to match on specific GRE payload types:

IPv4oGRE — ACL also matches on GRE next protocol = IPv4 (0x0800):

1mac access-list payload alias gre-protocol-ipv4 offset 5 pattern 0x00000800 mask 0xffff0000
2 
3mac access-list foo
4   counters per-entry
5   1 permit any any ip payload alias ip-next-protocol-gre alias ip-dip-decap-ip alias gre-protocol-ipv4
6   2 deny any any ip payload alias ip-dip-decap-ip
7   3 permit any any

IPv6oGRE — ACL also matches on GRE next protocol = IPv6 (0x86dd):

1mac access-list payload alias gre-protocol-ipv6 offset 5 pattern 0x000086dd mask 0xffff0000
2mac access-list foo
3   counters per-entry
4   1 permit any any ip payload alias ip-next-protocol-gre alias ip-dip-decap-ip alias gre-protocol-ipv6
5   2 deny any any ip payload alias ip-dip-decap-ip
6   3 permit any any

MPLSoGRE — ACL also matches on GRE next protocol = MPLS (0x8847):

1mac access-list payload alias gre-protocol-mpls offset 5 pattern 0x00008847 mask 0xffff0000
2 
3mac access-list foo
4   counters per-entry
5   1 permit any any ip payload alias ip-next-protocol-gre alias ip-dip-decap-ip alias gre-protocol-mpls
6   2 deny any any ip payload alias ip-dip-decap-ip
7   3 permit any any

MAC ACL to Permit IP-in-IPv4 Decap Only: This MAC ACL uses UDF to match on IP-in-IP packets:

• (a) IP next protocol = IPv4 (0x04) or IPv6 (0x29)
• (b) IP DIP = IP-in-IP Decap IP (converted to hex as 0xXXXXXXXX)

It allows IP-in-IP packets and drops all other packets to the IP-in-IP Decap IP.

1mac access-list payload alias ip-next-protocol-ipv4 offset 2 pattern 0x00040000 mask 0xff00ffff
2 
3mac access-list payload alias ip-next-protocol-ipv6 offset 2 pattern 0x00290000 mask 0xff00ffff
4 
5mac access-list payload alias ip-dip-decap-ip offset 4 pattern 0xXXXXXXXX mask 0x00000000
6mac access-list foo
7   counters per-entry
8   1 permit any any ip payload alias ip-next-protocol-ipv4 alias ip-dip-decap-ip 
9   2 permit any any ip payload alias ip-next-protocol-ipv6 alias ip-dip-decap-ip
10   3 deny any any ip payload alias ip-dip-decap-ip
11   4 permit any any

MAC ACL to Permit GUEv4 Decap Only: This MAC ACL uses UDF to match on GUE packets:

• (a) IP next protocol = UDP (0x11)
• (b) IP DIP = GUE Decap IP (converted to hex as 0xXXXXXXXX)
• (c) UDP destination port = UDP port configured per payload (UDP port for IP payload = 0xYYYY, UDP port for MPLS payload = 0xZZZZ)

It allows GUE packets and drops all other packets to the GUE Decap IP.

1mac access-list payload alias ip-next-protocol-udp offset 2 pattern 0x00110000 mask 0xff00ffff
2 
3mac access-list payload alias ip-dip-decap-ip offset 4 pattern 0xXXXXXXXX mask 0x00000000
4 
5mac access-list payload alias udp-dport-gue-ip offset 5 pattern 0x0000YYYY mask 0xffff0000
6 
7mac access-list payload alias udp-dport-gue-mpls offset 5 pattern 0x0000ZZZZ mask 0xffff0000
8 
9mac access-list foo
10   1 permit any any ip payload alias ip-next-protocol-udp alias ip-dip-decap-ip alias udp-dport-gue-mpls
11   2 permit any any ip payload alias ip-next-protocol-udp alias ip-dip-decap-ip alias udp-dport-gue-ip
12   3 deny any any ip payload alias ip-dip-decap-ip
13   4 permit any any

MAC ACL to Permit GUEv6 Decap Only: This MAC ACL uses UDF to match on GUEv6 packets:

• (a) IP next protocol = UDP (0x11)
• (b) IPv6 DIP = GUE Decap IP (converted to hex as 0xAAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD)
• (c) UDP destination port = UDP port configured per payload (IP = 0xYYYY or MPLS = 0xZZZZ)

It allows GUE packets and drops all other packets to the GUE Decap IP.

1mac access-list payload alias ipv6-next-protocol-udp offset 1 pattern 0x00001100 mask 0xffff00ff
2 
3mac access-list payload alias udp-dport-gue-ip offset 10 pattern 0x0000YYYY mask 0xffff0000
4 
5mac access-list payload alias udp-dport-gue-mpls offset 10 pattern 0x0000ZZZZ mask 0xffff0000
6 
7mac access-list payload alias ipv6-dip-decap-ip1 offset 6 pattern 0xAAAAAAAA mask 0
8 
9mac access-list payload alias ipv6-dip-decap-ip2 offset 7 pattern 0xBBBBBBBB mask 0
10 
11mac access-list payload alias ipv6-dip-decap-ip3 offset 8 pattern 0xCCCCCCCC mask 0
12 
13mac access-list payload alias ipv6-dip-decap-ip4 offset 9 pattern 0xDDDDDDDD mask 0
14 
15

MAC ACL to Permit IP-in-IPv6 Decap Only: The MAC ACL uses UDF to match on IP-in-IPv6 packets:

• (a) IP next protocol = IPv4 (4) or IPv6 (41)
• (b) IPv6 DIP = IP-in-IP Decap IP (converted to hex as 0xAAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD)

It allows IP-in-IP packets and drops all other packets to the IP-in-IP Decap IP.

1mac access-list payload alias ipv6-next-protocol-ipv4 offset 1 pattern 0x00000400 mask 0xffff00ff
2 
3mac access-list payload alias ipv6-next-protocol-ipv6 offset 1 pattern 0x00002900 mask 0xffff00ff
4 
5mac access-list payload alias ipv6-dip-decap-ip1 offset 6 pattern 0xAAAAAAAA mask 0
6 
7mac access-list payload alias ipv6-dip-decap-ip2 offset 7 pattern 0xBBBBBBBB mask 0
8 
9mac access-list payload alias ipv6-dip-decap-ip3 offset 8 pattern 0xCCCCCCCC mask 0
10 
11mac access-list payload alias ipv6-dip-decap-ip4 offset 9 pattern 0xDDDDDDDD mask 0
12 
13mac access-list foo
14   counters per-entry
15

TCAM Profile and ACL Configurations for 7280R3, 7500R3, and 7800R3 Series

For the R3 series, mitigation uses IPv6 PACLs instead of MAC ACLs with UDFs. The following TCAM profile update is required:

1hardware tcam
2   profile test
3      feature acl port ipv6
4         packet ipv6 ipv4 forwarding routed decap
5         packet ipv6 ipv6 forwarding routed decap
6         packet ipv6 gue ipv4 forwarding routed decap
7         packet ipv6 gue ipv6 forwarding routed decap
8         packet ipv6 gue mpls forwarding mpls decap

Introducing new packet types may also require specifying them under other features such as or . Contact Arista TAC if further assistance is needed with TCAM profile construction.

ACL to Permit GUEv6 Only (for 7280R3/7500R3/7800R3): This IPv6 ACL matches on GUE packets:

• (a) IP next protocol = UDP (0x11)
• (b) IP DIP = GUE Decap IP
• (c) UDP destination port = UDP port configured per payload (IP = Y or MPLS = Z)

It allows GUE packets and drops all other packets to the GUE Decap IP.

1ipv6 access-list foo
2   counters per-entry
3   1 permit udp any host <decap-ip> eq Y
4   2 permit udp any host <decap-ip> eq Z
5   3 deny ipv6 any host <decap-ip>
6   4 permit ipv6 any any

ACL to Permit IP-in-IPv6 Only (for 7280R3/7500R3/7800R3): This IPv6 ACL matches on IP-in-IPv6 packets:

• (a) IP next protocol = IPv4 (4) or IPv6 (41)
• (b) IP DIP = IP-in-IP Decap IP

It allows IP-in-IPv6 packets and drops all other packets to the IP-in-IPv6 Decap IP.

1ipv6 access-list foo
2   counters per-entry
3   1 permit 4 any host <decap-ip>
4   2 permit 41 any host <decap-ip>
5   3 deny ipv6 any host <decap-ip>
6   4 permit ipv6 any any

Step 4: Enable Detection and Monitoring

Even before mitigations are fully deployed, operators should enable detection capabilities to identify active exploitation:

• Enable per-entry ACL counters on all interfaces handling decapsulation traffic by including counters per-entry in ACL configurations. These counters will reveal if unexpected protocol traffic is being matched and dropped by deny rules.
• Monitor internal network segments for unexpected traffic appearing on subnets that should only be reachable via properly configured tunnels. Unexplained hosts or services appearing on internal VLANs that should be empty, or traffic sources that should not be able to reach those segments, are indicators of potential exploitation.
• Watch for unexpected tunneled protocol types arriving at decapsulation IP addresses — for example, GRE or IP-in-IP traffic appearing at a VXLAN VTEP IP.
• Review ACL hit counts using show mac access-lists <name> to identify traffic being blocked by deny rules targeting decapsulation IPs.

For CISA's federal mandate compliance: federal agencies subject to Binding Operational Directive (BOD) 22-01 must remediate CVE-2026-7473 in accordance with CISA KEV requirements. The KEV entry was added on June 9, 2026.

The Bigger Picture

CVE-2026-7473 represents something relatively uncommon in the vulnerability landscape: a vendor openly acknowledging that a security flaw is both actively exploited in the wild and permanently unpatched by design. Arista's decision to forgo a software fix — justified by the risk of breaking customer configurations — places this vulnerability in a difficult category for defenders. There is no patch to wait for. There is no upgrade path to plan around. There is only configuration-level mitigation, applied manually, to every affected device in the environment, for as long as those devices remain in service.

This situation highlights a broader trend in network infrastructure security: the security properties of hardware-accelerated forwarding engines are often deeply intertwined with the hardware's capabilities and limitations. The very TCAM that makes Arista switches fast enough to forward packets at line rate is also the hardware that makes it difficult to add the granular protocol-type checks needed to fix this vulnerability without sacrificing other capabilities. Security and performance exist in a constrained trade-space at the silicon level, and CVE-2026-7473 is a vivid illustration of what happens when security loses that trade-off.

The discovery of this flaw by researchers at Comcast — a major internet service provider with extensive Arista deployments — also suggests that this vulnerability may be particularly relevant in large-scale carrier and service provider environments, where Arista R-series hardware is deployed as backbone and peering infrastructure. The scale of those deployments, and the sensitivity of the traffic they carry, amplifies the stakes considerably.

Network operators should treat CVE-2026-7473 as a wake-up call to audit the security controls surrounding tunnel endpoints more broadly. Decapsulation endpoints — by their very nature — represent points where the network accepts and processes traffic that is deliberately disguised inside an outer wrapper. They are inherently high-value targets for protocol abuse attacks, and they deserve careful ACL controls even on hardware that does not have this specific vulnerability.

Finally, watch this space: the vendor advisory and CVE record do not disclose the full scope of what attackers have done with this capability in the wild. As incident response investigations into affected networks conclude and threat actor toolkits are analyzed, a clearer picture of how CVE-2026-7473 has been weaponized will likely emerge. Network operators who deploy the recommended upstream ACL mitigations now will be better positioned both to stop ongoing exploitation and to generate the visibility needed to detect whether their environments have already been compromised.

Disclosure credit: CVE-2026-7473 was discovered and reported to Arista Networks by Scott Christiansen, Lukas Peitz, Rich Compton, and Jonathan Davis at Comcast. Arista Security Advisory 0137 was publicly disclosed on May 5, 2026. CISA added CVE-2026-7473 to the Known Exploited Vulnerabilities catalog on June 9, 2026.