Arista Won't Patch the Bug That Makes Your Perimeter ACLs Decorative. Your Log Pipeline Will Bill You to Watch.

On June 9, CISA added three vulnerabilities to the Known Exploited Vulnerabilities catalog in one shot: a Cisco Catalyst SD-WAN Manager flaw, a Google Chromium V8 memory bug, and CVE-2026-7473 in Arista EOS. Two of the three you can patch this week. The Arista one you cannot patch at all, because Arista says no patch is planned.

Read that again. A vulnerability that CISA confirms is being exploited in the wild, on the switches that carry the spine of enterprise and data-center networks, and the vendor's official position is that a fix would risk breaking existing deployments. So there will not be one. The remediation is a configuration change you have to make yourself, on the exact devices the bug turns against you.

What The Bug Actually Does

CVE-2026-7473 is a tunnel decapsulation flaw. On affected Arista EOS platforms configured as a tunnel endpoint — a decap-group, a GRE tunnel interface, or a VXLAN endpoint with a decapsulation IP — the switch does not verify the tunnel protocol type before decapsulating. It was told to accept one kind of tunnel to that IP. It accepts all of them.

That single missing check collapses a security boundary. An attacker sends crafted tunneled packets across the network toward the switch's decapsulation IP. Because the protocol type is never checked, the inner packet emerges inside the trust zone the switch serves. The attacker reaches internal hosts that were supposed to be unreachable. Perimeter access-control lists that were carefully written to keep tunnel traffic out are bypassed, because the packet is already inside by the time anything inspects it. Segmentation between VRFs and overlay segments — the thing you built the fabric to enforce — becomes suggestion instead of control.

CVSS 6.9. That number undersells it. The score is moderate because exploitation requires a specific configuration. But the configuration in question — decap-groups, GRE, VXLAN on 7020R, 7280R/R2, and 7500R/R2 series — is not exotic. It is how a large share of modern data-center and campus fabrics are built. A public proof-of-concept is already on GitHub.

This Is The Same Story As FortiBleed. Nothing To Patch.

Ten days ago we wrote that FortiBleed was not a campaign, it was an audit result — roughly half of every internet-facing FortiGate failing eight years of accumulated credential hygiene, with no single CVE and no patch that closes it. Arista 7473 is the same shape wearing different hardware. There is no emergency update to schedule. There is no reboot window that fixes it. The vendor has handed you a design decision and a note that says "you deal with it."

When the fix is a config change and not a patch, the entire security industry's muscle memory misfires. Your patch-management program does nothing, because there is nothing to patch. Your vulnerability scanner reports the device as green — Eclypsium said it plainly, scanners cannot see this one, because there is no version string to flag and no banner to grab. And the mitigation Arista recommends is to apply ACLs to selectively permit only legitimate tunnel traffic, either upstream or on the decap device. Which means the defense against a bug that bypasses perimeter ACLs is: write better perimeter ACLs. You have to get the exact thing right that the vulnerability exists to defeat.

Could We Have Caught This For You? Here Is The Honest Answer.

We are a threat-intelligence shop. Our reflex is to say yes, we would have flagged it, here are the indicators. On this one, the honest answer is more useful than the flattering one.

No feed protects you from CVE-2026-7473. There is no malicious IP to block, no domain to sinkhole, no file hash to deny. It is a protocol-confusion bug on your own switch. We publish a STIX feed that a Cloudflare Worker and a dozen SIEMs pull to block real attacker infrastructure at the edge, and it is genuinely good at that — but it would not have saved a single VXLAN endpoint here, and we are not going to pretend it would. A feed catches things that travel. This bug is a door someone opens from the hallway you already trust.

What intelligence is actually for, on a bug like this, is the part no automated pipeline does. Reading the advisory the day it lands. Recognizing that "no patch planned" plus "exploited in the wild" plus "scanners can't see it" is a specific, dangerous combination and not just another moderate CVSS number in the weekly stack. Telling you where the door is, that your scanner and your patch tooling will both lie to you about it, and that the only real control is source-restricted ACLs on both the upstream path and the decap device — allow tunnel traffic from the handful of endpoints that are supposed to send it, and drop everything else destined to the decapsulation IP.

That is a person deciding what matters. It is not a product that moves data.

Which Brings Us To The Pipeline Vendors

There is a category of company whose entire pitch is that they will take your telemetry and move it around efficiently. Cribl is the loudest of them. Point your Arista syslog at it and it will happily route, reduce, reshape, and reprice ten thousand switch log lines a second on their way to the SIEM you are already overpaying for. Charged, in many shapes, by the gigabyte of hay it shovels.

Here is what that gigabyte of Arista syslog will never contain: a line that says your switch is decapsulating an attacker's tunnel inside your trust zone, that there is no patch coming, and that your ACLs are now decorative. The device is behaving exactly as configured. There is no error to log. A pipeline optimizes the transport of data that, in this case, does not know it is describing a breach. You can move it faster, dedupe it, and drop half of it to save money, and you will have spent that money making the silence more efficient.

A pipe is not a lens. Moving data is not understanding it. Cribl will get your logs from A to B beautifully, and on the day CVE-2026-7473 is the thing that matters, it will have absolutely nothing to say about it, because saying something is not what it does. That gap — between transporting signal and recognizing it — is the whole job. It is the part that a human who read the advisory does and a routing engine, by design, cannot.

What To Actually Do

If you run Arista 7020R, 7280R, or 7500R series switches with any tunnel decapsulation configured, treat this as active. There is no patch, so the work is configuration, and it is worth doing this week rather than next.

Enumerate every device with a decap-group, GRE tunnel interface, or VXLAN termination and note the decapsulation IPs. On the upstream path, apply ACLs that permit tunneled traffic only from the specific, known-legitimate tunnel sources and drop all other tunnel protocols destined to those IPs. Apply the same restriction on the decap device itself, so the control does not depend on a single upstream chokepoint holding. Then check the assumption you are about to bet on: that you know every legitimate tunnel source, because the ACL is only as good as that list.

We will not promise this closes the risk to zero. Nothing does, and anyone who tells you otherwise is selling. Roughly five percent of the time something you did not account for is going to be wrong — a tunnel source you forgot, an overlay you inherited, a lab config that outlived its purpose. Budget for that. But source-restricted ACLs on both ends are the difference between a perimeter that means something and one that is drawn on for decoration.

The vendor is not going to patch this. Your scanner is not going to see it. Your pipeline is not going to mention it. That leaves you, the advisory, and whoever is willing to read it and tell you the truth about what it says.

---

The threat feed this post is built on

1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.

Get your free key → analytics.dugganusa.com/stix/register