Pulp-style illustration of a rocket-age network switch with an unlocked hatch, a stray tunnel of light slipping past a sleeping robot guard

Arista EOS CVE-2026-7473: still unfixed, and no fix is coming

ALERT · Actively exploited. Last updated 24 October 2026. See the Alert Tracker

If your Arista switches terminate tunnels, the access lists are the fix, permanently. Arista says no software fix is planned for CVE-2026-7473, which CISA has listed as exploited since 9 June. Arista first published its advisory on 5 May and last revised it on 10 August.

What it is

Arista’s Security Advisory 0137 covers a flaw in how some EOS platforms handle tunnel decapsulation. A switch that acts as a tunnel endpoint also decapsulates tunnelled packets of types it was never configured for. The inner traffic then lands on internal segments, bypassing a boundary you thought was enforced.

Arista says the issue “has been reported as being exploited in the wild”. Nobody has said who is exploiting it, so treat any switch that meets the conditions below as exposed.

The advisory’s resolution section says: “No software upgrade path is planned to address this issue due to the risk of breaking existing configuration on deployments.” No hotfix is available either, so this flaw will not drop off the KEV list by itself.

Scores

  • CVSS 3.1: 5.8 (Medium), the same from Arista and NVD.
  • CVSS 4.0: Arista’s advisory gives 6.8; the same vector computes to 6.9, which is what NVD shows. Medium either way.
  • CISA SSVC: exploitation active, automatable, technical impact total.

Do not let the Medium rating set your priority: this is exploited network infrastructure that will never be patched.

Who is affected

  • Software: every EOS release. Upgrading does not help.
  • Fully affected: 7020R, 7280R and 7280R2, and 7500R and 7500R2 series.
  • Limited exposure: 7280R3, 7500R3 and 7800R3 series, for IP-in-IPv6 and GUE over IPv6 only.
  • Not affected: many other series, including CloudEOS, cEOS-lab and vEOS-lab.
  • Required configuration: the switch must be a tunnel endpoint with a decapsulation IP address: a VXLAN VTEP, a GRE tunnel endpoint or an ip decap-group. An affected platform that terminates no tunnels is not exposed.

How to find it in your estate

This is an inventory and configuration job. Do not test production switches with crafted tunnel traffic.

  • List the hardware. Pull Arista devices from your inventory, or run show version, and keep the affected models.
  • Check whether each one terminates tunnels. Arista gives three commands: show interfaces vxlan 1, show interfaces Tunnel0 (or whichever tunnel interfaces you use) and show ip decap-group. Record every decapsulation IP address.
  • Work out who can reach those addresses. Check routing and ACLs on every path, including the internet edge, WAN, partner links and internal zones. Can anyone other than your tunnel peers route a packet there?
  • Check your own public ranges. Internet-scan indexes rarely record GRE or IP-in-IP endpoints, so rely on your edge ACLs and flow data.
  • Write down what each tunnel should carry: the one tunnel type it should terminate (for example, VXLAN on UDP 4789) and its peer addresses.

Compensating controls and what to do next

Arista’s mitigation is to make sure only the configured tunnel type can reach the decapsulation address. It describes two approaches, both aligned with its EOS Hardening Guide.

  • Approach 1: filter upstream, and start here. On the routers or firewalls in front of the switch, permit only the tunnel protocol that endpoint should terminate. For a VXLAN VTEP that means UDP to port 4789 on the decapsulation IP. For a GRE endpoint it means GRE (IP protocol 47). Deny every other tunnel protocol to that address: IPv4-in-IP (IP protocol 4), IPv6-in-IPv4 (IP protocol 41), GRE where VXLAN is expected, and GUE. Where possible, allow only known tunnel peers.
  • Approach 2: filter on the switch, only if upstream filtering cannot cover every path. Arista describes MAC ACLs with user-defined fields, or IPv6 port ACLs on the R3 series. Both need a change to the TCAM (the switch’s hardware lookup table) profile. That change is disruptive and may mean removing MPLS, VXLAN or policy-based routing features. Plan a maintenance window and follow the advisory exactly.
  • Do not lock yourself out. Before the deny entries, explicitly permit BGP, SSH and anything else that legitimately goes to the decapsulation IP.
  • Turn on per-entry counters. Arista lists denied packets on the counters as a sign of attempted abuse.
  • Make it stick. Add the ACLs to configuration templates and compliance checks so rebuilds do not reopen the gap.
  • Give it an owner. Record a named risk owner and a review date. Without a software fix, the long-term choice is permanent fencing or a platform refresh.

To hunt, look in upstream flow data for tunnel protocols reaching a decapsulation address that should not carry them, or arriving from sources that are not your tunnel peers. Our Hunt Lab folder for CVE-2026-7473 sets out the hypotheses and data sources. No indicators of compromise have been published.

For the wider problem of flaws that will not be patched, see our guide, When there’s no patch: how to find and fence unfixed flaws.

Sources