CVE-2026-7473: Arista EOS Tunnel Decapsulation Bypass — How to Find Affected Switches on Your Network

Arista EOS switches with VXLAN, GRE, or decap-group configurations will incorrectly accept and forward tunneled traffic they were never configured to process. Actively exploited in the wild, added to the CISA KEV catalog, and Arista says no software patch is planned — the only fix is ACLs. Here's how to identify affected switches on your network.

The Vulnerability

CVE-2026-7473 (CWE-1023) is an incomplete comparison vulnerability in Arista EOS tunnel decapsulation logic. When a switch is configured as a tunnel endpoint — whether for VXLAN (UDP port 4789), GRE (IP protocol 47), or using ip decap-group — it checks the destination IP of incoming packets but fails to verify the tunnel protocol type. A switch configured only for VXLAN decapsulation will also decapsulate GRE, IP-in-IP, and other tunneled traffic destined to the same IP address.

The impact is subtle but serious: an attacker can bypass network segmentation by injecting traffic through an unexpected tunnel protocol. A VXLAN-only fabric could unknowingly forward GRE-encapsulated packets, allowing lateral movement across segments that should be isolated. The moderate CVSS score reflects that integrity is impacted without direct confidentiality loss — but in practice, bypassing segmentation is often the first step in a much larger attack chain.

Why No Patch?

Arista's advisory states that no software fix is currently planned because correcting the protocol validation behavior would break existing tunnel configurations in production networks. This makes CVE-2026-7473 unusual: a CISA KEV vulnerability with no vendor patch path. Remediation requires applying ACLs to filter tunnel traffic, or disabling unused tunnel decapsulation features where possible.

Who's Affected

Not all Arista switches are vulnerable. The device must be configured as a tunnel endpoint with a decapsulation IP — meaning VXLAN VTEPs, GRE tunnel interfaces, or ip decap-group configurations.

• • Fully affected: 7020R, 7280R/R2, 7500R/R2 series
• • Limited exposure (IP-in-IPv6 and GUEv6 only): 7280R3, 7500R3, 7800R3 series
• • Not affected: 7050X/X2/X3/X4, 7060X series, 7280E/R4, 7300X/X3, 7800R4, CloudEOS, and all software platforms

Investigation Workflow

Arista switches run in data centers and campus networks worldwide. If your organization uses Arista, identifying which switches have tunnel decapsulation configured is critical. Here's how to find and audit Arista EOS devices on your network.

1. Port Scan: Find Arista Management Interfaces

Arista EOS exposes its management interface via HTTPS on port 443 (eAPI) and SSH on port 22. Some deployments also enable HTTP on port 80. Scan your management VLANs and out-of-band management subnets for these ports to build an inventory of Arista devices.

Additionally, scan for UDP port 4789 (VXLAN). Switches with this port open are likely configured as VXLAN tunnel endpoints (VTEPs) and may be affected by CVE-2026-7473. For a complete inventory, cross-reference with your network management platform — Arista CloudVision or tools like NetBox can identify GRE and decap-group configurations that aren't detectable via port scanning alone.

2. TLS Inspect: Identify Arista eAPI Certificates

Arista EOS generates a self-signed certificate for its eAPI HTTPS interface by default. Pull the certificate chain on port 443 of suspected Arista management IPs. Look for:

• • Self-signed certificates on management interfaces — common in Arista deployments
• • Organization or issuer fields referencing Arista or Arista Networks
• • Subject CN matching the switch hostname or management IP

Many enterprises replace default certificates with their own CA-issued certs. If the TLS certificate doesn't immediately identify Arista, use HTTP fingerprinting as a secondary confirmation.

3. HTTP Headers: Fingerprint the eAPI

Arista's eAPI is a RESTful JSON-RPC interface over HTTPS. When you send an HTTP request to the management interface, the response headers and behavior can identify the platform. Look for:

• • Server header or response patterns unique to Arista EOS
• • JSON-RPC endpoints at /command-api — the standard eAPI path
• • Authentication prompts (HTTP 401) with WWW-Authenticate: Basic on the management port

The eAPI endpoint /command-api accepts POST requests with JSON-RPC payloads. Even without valid credentials, an HTTP 401 response at this path strongly indicates an Arista EOS device.

4. DNS: Discover Arista Infrastructure

Query internal DNS for common Arista naming patterns: spine-*, leaf-*, sw-*, arista-*, vtep-*. In VXLAN fabrics, Arista switches often follow leaf-spine naming conventions. Reverse DNS on management subnets can reveal switches deployed outside your asset inventory.

5. CVE Lookup: Confirm the Advisory

Pull the full NVD entry for CVE-2026-7473. Cross-reference the affected platform list against your discovered Arista inventory to determine which switches need ACL mitigation.

Cross-Reference with External Data

Remediation

Arista's advisory confirms no software patch is currently planned for this EOS vulnerability. Remediation requires applying access control lists to restrict which tunnel protocols are accepted, or disabling unused tunnel features. Two ACL approaches:

1. Apply upstream ACLs. On routers or firewalls upstream of the affected switch, filter tunnel traffic to only permit the configured protocol. For VXLAN-only deployments, permit UDP destination port 4789 to the decap IP and deny all other tunnel traffic to that IP.
2. Apply MAC/IP ACLs on the switch itself. For 7020R/7280R/7500R series, use MAC ACLs with User-Defined Fields (requires TCAM profile changes). For R3 platforms, use IPv6 PACLs. See Arista's advisory for exact configurations.
3. Disable unused tunnel features. If a switch has VXLAN, GRE, or decap-group configurations that are no longer in use, remove them to eliminate the attack surface entirely.
4. Audit your tunnel configurations. Identify every switch with VXLAN VTEPs, GRE tunnels, or ip decap-group configurations using CloudVision or config backups. Prioritize the Arista 7020R, 7280R, 7280R2, 7500R, and 7500R2 platforms.
5. Verify ACL effectiveness. After applying ACLs, test that non-configured tunnel protocols are properly blocked. Use packet counters on the ACL entries to confirm the deny rules are matching.
6. Monitor for exploitation. Watch for unexpected tunnel traffic reaching your switches — particularly GRE or IP-in-IP packets arriving at VXLAN-only endpoints. Anomalous decapsulated traffic on segments where it shouldn't appear may indicate active exploitation.

Sources

• → Arista Security Advisory 0137: CVE-2026-7473
• → NVD: CVE-2026-7473
• → CISA Known Exploited Vulnerabilities Catalog