CVE-2026-7473

What it actually does

Affected Arista EOS switches with tunnel decapsulation configured can accept, decapsulate, and forward tunneled packets using an unexpected tunnel protocol when the outer destination IP matches a configured decapsulation IP. The root issue is incomplete validation of tunnel protocol type before decapsulation. A remote unauthenticated attacker who can send crafted encapsulated traffic to the switch’s decapsulation address may cause traffic to be processed as if it belonged to an intended VXLAN, GRE, or decap-group path, potentially enabling unauthorized packet injection or policy bypass across network segments. The impact is primarily integrity-related: packets may be forwarded where they should have been dropped.

Why it matters to the business

This can undermine network segmentation and routing controls in environments using Arista EOS tunnel features, especially data center fabrics, overlay networks, and interconnect designs that rely on VXLAN, GRE, or decapsulation groups. Because exploitation has been reported in the wild and the issue is listed in CISA KEV with a remediation due date of 2026-06-23, exposed configurations should be treated as urgent even though the CVSS score is moderate. Successful exploitation could allow unauthorized traffic to reach sensitive network zones, disrupt trust boundaries between tenants or services, and create incident response costs tied to traffic injection or lateral movement investigations.

How an attack unfolds

An attacker first identifies an Arista EOS device or fabric endpoint that has a reachable decapsulation IP used for VXLAN, GRE, or a decap-group. The attacker then sends encapsulated packets to that destination IP using a tunnel protocol that is not expected or not configured for that decapsulation context. Due to insufficient protocol-type validation, the switch may decapsulate the packet anyway and forward the inner packet into the associated forwarding path. If the attacker crafts the inner packet with useful source, destination, VLAN, VRF, or overlay addressing, the traffic may enter a network segment that would normally be protected by routing, tunneling, or segmentation policy. Public reporting indicates active exploitation in the wild, so defenders should assume adversaries may be testing exposed tunnel endpoints for this behavior.

How to fix it

Upgrade affected Arista EOS platforms to a vendor-fixed EOS release as identified in the relevant Arista security advisory for the deployed hardware and software train. No exact fixed versions were provided in the input, so operators should verify the corrected release directly from Arista and prioritize devices with VXLAN, GRE tunnel interfaces, or decap-groups enabled. Until patched, restrict access to decapsulation IPs so they only accept expected tunnel traffic from explicitly authorized peers. For VXLAN, permit UDP/4789 only from approved VTEPs and block other encapsulation protocols to the decapsulation IP. For GRE, permit IP protocol 47 only from approved tunnel peers and block unexpected UDP tunneling or IP-in-IP traffic. Remove unused tunnel or decapsulation configuration, disable stale tunnel endpoints, and apply infrastructure ACLs or upstream filtering as close to the source as possible. Review overlay and underlay segmentation policies to ensure unexpected decapsulated traffic cannot reach sensitive destinations.

How to confirm the fix worked

Confirm whether devices are exposed by checking EOS version, platform model, and configuration for VXLAN, GRE tunnel interfaces, or decap-groups. Useful administrative checks include reviewing running configuration for tunnel-related features and identifying all configured decapsulation, VTEP, loopback, and tunnel destination addresses. Validate remediation by confirming the switch is running a vendor-fixed EOS release or has compensating filters that block unexpected tunnel protocols to each decapsulation IP. Network validation should include packet captures or ACL counter checks showing that only approved tunnel protocols and approved peers can reach decapsulation IPs. In a controlled lab or maintenance window, send benign unexpected encapsulated test traffic toward a decapsulation IP and confirm it is dropped and no inner packet is forwarded. After upgrading, re-check configuration and traffic counters to ensure filtering remains in place and no unexpected decapsulation behavior is observed.

Typical attack path

1. Identify Arista EOS switches or tunnel endpoints with reachable decapsulation IP addresses.
2. Determine or infer whether VXLAN, GRE, tunnel interfaces, or decap-groups are configured.
3. Craft tunneled packets whose outer destination IP matches the configured decapsulation IP but whose tunnel protocol is unexpected for that configuration.
4. Send the crafted packets from a network location that can reach the decapsulation address.
5. Rely on the switch incorrectly decapsulating and forwarding the inner packet.
6. Use the forwarded inner traffic to bypass intended segmentation, inject packets into an overlay or internal segment, or support follow-on movement.

How to detect it

Look for evidence of unexpected encapsulated traffic sent to configured decapsulation IPs, especially from sources that are not approved VTEPs or GRE peers. Relevant telemetry includes NetFlow/sFlow/IPFIX, firewall or router ACL logs, packet captures on underlay links, EOS interface counters, and any centralized network detection logs that parse encapsulation protocols. Focus on outer packets whose destination is a VXLAN source interface, tunnel endpoint, loopback used for decapsulation, or decap-group address, but whose protocol does not match the configured tunnel type. For VXLAN environments, investigate GRE, IP-in-IP, or non-UDP/4789 traffic to VTEP or decapsulation addresses. For GRE environments, investigate UDP/4789 or other tunneling traffic to GRE endpoint addresses. Also look for inner packets that appear in overlay VLANs, VRFs, or segments from unexpected source addresses or without a matching authorized tunnel peer. Because exploitation has been reported in the wild, unexplained denied ACL counters or successful flows involving unapproved tunnel sources should be preserved for incident response, including packet samples, timestamps, source IPs, destination decapsulation IPs, outer protocol, inner source/destination, and affected interface or VRF.

• IP protocol 47 traffic to a VXLAN VTEP or decapsulation IP
• UDP/4789 traffic to a GRE tunnel endpoint or non-VXLAN decapsulation IP
• IP protocol 4 traffic to an Arista EOS decapsulation IP
• Outer destination IP equals configured decapsulation IP with unexpected tunnel protocol
• VXLAN traffic from a source IP not in the approved VTEP list
• GRE traffic from a source IP not in the approved tunnel peer list
• Packets to UDP/4789 from unauthorized underlay sources
• Packets using GRE/IP protocol 47 from unauthorized underlay sources
• Packets using IP-in-IP/IP protocol 4 from unauthorized underlay sources
• show running-config | include interface Vxlan
• show running-config | include decap-group
• show running-config | include interface Tunnel
• show running-config | include tunnel mode gre

What your security team should do

• Treat this as urgent for any Arista EOS device with VXLAN, GRE, tunnel interface, or decap-group configuration because exploitation has been reported in the wild and the KEV remediation date has passed.
• Inventory all Arista EOS devices and identify configured decapsulation IPs, VTEPs, GRE peers, tunnel interfaces, and decap-groups.
• Upgrade affected devices to the Arista-recommended fixed EOS release for the deployed platform and software train.
• Implement infrastructure ACLs that allow only expected tunnel protocols from approved peers to decapsulation IP addresses.
• Block unexpected encapsulation protocols, including GRE, VXLAN/UDP, IP-in-IP, and other tunneling traffic, where they are not explicitly required.
• Review NetFlow, sFlow, packet captures, firewall logs, and switch telemetry for unexpected tunnel traffic destined to EOS decapsulation addresses.
• Investigate any evidence of non-approved tunnel sources, unusual inner packet destinations, or traffic appearing inside overlay segments without a legitimate tunnel peer.
• Document compensating controls and retest after upgrades or configuration changes to confirm unexpected tunneled traffic is dropped.