CVE-2026-7473 allows an attacker to sneak traffic into your network; there is no fix planned, and because the flaw lives in configuration rather than in a version number, your scanner will likely miss it.
Vulnerability Details – The Package You Weren’t Expecting
An actively exploited vulnerability (CVE-2026-7473) in some Arista EOS switches with a tunnel decapsulation configuration interface causes the switch to forward unexpected, improperly decapsulated traffic. Vulnerability scanners won’t catch this, since it depends on a misconfiguration.
Some background understanding is important to recognize why this category of vulnerability is so dangerous and so hard to detect. A high percentage of network traffic does not travel directly across the network. It is first wrapped inside another packet. I will use the mailroom analogy: tunneling protocols are like sealing a letter in a shipping box to ensure it survives the trip. Wrapping traffic like this is what people mean by “tunneling.” There are several different tunneling protocols, such as VXLAN, GRE, and IP-in-IP. The names matter less than the basic idea: the switch’s job is to receive these wrapped packets, unwrap them (a process called decapsulation), and forward their contents to the right place on the network. When tunneling is set up, you give the mailroom two pieces of information: the address to which wrapped packets should be sent and the wrapping format those packets should use. From then on, you assume the mailroom opens packages only if they arrive at that address in the format you specified. That assumption is the entire basis on which you reason about what traffic can reach the inside of your network.
CVE-2026-7473 breaks that assumption because affected Arista EOS switches check the address on the outside of the package but never check what kind of wrapping it is, so they will open and forward the contents of any wrapped packet sent to that address, including formats you never set them up to handle. A switch you configured only for VXLAN will just as happily unwrap GRE, IP-in-IP, or NVGRE, and a switch you configured only for GRE will unwrap VXLAN, GUE, or IP-in-IP, as long as the outer address matches. It sees a package addressed to it, opens it, and forwards its contents, and at no point does it stop to ask whether this is even the kind of package you asked it to accept.
That sounds like a small oversight, but it is not, because the contents that get forwarded land on an internal part of your network that your firewall and segmentation rules assume nothing on the outside can reach. An attacker who knows that address can take their own traffic, wrap it in a format the switch wasn’t expecting, send it in, and let the switch carry it straight into a segment that was supposed to be walled off. Arista files this under CWE-1023, Incomplete Comparison with Missing Factors, which is a formal way of saying the device checks one thing, the address, and forgets to check the other thing that matters just as much, the wrapping format, and that one missing check is the whole bug.
Here is what that looks like as an attack. The attacker’s goal is to reach a part of your network that your firewall and segmentation rules are supposed to keep off-limits. This flaw lets the attacker use the switch itself as the delivery vehicle. The attacker finds an Arista switch acting as a tunnel endpoint with a decapsulation address they can reach, then builds a packet in two layers:
- An outer wrapper in any tunnel format the switch will accept, even one you never configured, addressed to that decapsulation address.
- An inner packet addressed to a system on the protected side that they should never be able to touch.
The switch receives it, strips the outer wrapper without ever checking whether the format is one you actually asked for, and forwards the inner packet to wherever the attacker pointed it. No firewall was breached, and no host along the way was compromised. The attacker addressed an envelope to the switch, slipped a second envelope inside aimed at an internal target, and let the switch deliver it, which is how one missing validation check turns into an open route into the segments you assumed were sealed off.
The Story Behind the Story: A Month of Invisibility
Here is the part that should bother you more than the bug itself. Arista published this advisory on May 5, 2026, and in that advisory, they assigned and referenced CVE-2026-7473. Arista stated in plain language that the issue had been reported as exploited in the wild, so as of May 5, a vendor advisory, a CVE identifier, and an exploitation claim were all publicly available. And for roughly a month after that, if you queried the public CVE databases and asked them to show you every Arista CVE, this one did not come back. Arista had published the advisory on their own site, including the CVE, but that record had not propagated to the public databases that the rest of us build our tooling and prioritization on.
Think about what that gap means in practice. For about a month, the only way you found out about an actively exploited, no-patch vulnerability in your border switches was if you were personally subscribed to and reading Arista security advisories, because every automated workflow that keys off the public CVE feeds was blind to it. You can solve that, in theory, by building a system that crawls every vendor’s advisory page and indexes it for you.
I can assure you that this is no small task and is probably one of the hardest technical problems to solve. The data is fragmented across vendor sites, very few vendors expose an API for their advisories, and the one standardization effort that was supposed to fix this, CSAF, never achieved the adoption it needed to make a dent.
The KEV timing tells the same story from the other direction. Arista flagged in-the-wild exploitation on May 5, but the CVE did not land on the CISA KEV until June 9. That delay is not CISA being slow; it is structural. CISA does not add to the KEV because a vendor wrote “exploited in the wild” in an advisory. CISA needs a report from one of its trusted sources, validates that report, and only then issues the KEV entry. A vendor discovering exploitation during a customer support engagement, which is a common way these things surface, does not by itself trip the KEV machinery. The end result is a five-week window during which this vulnerability was real, exploited, public on the vendor site, missing from the CVE databases, and not yet on the KEV. Any defender relying on the KEV as their trigger was working from incomplete information the entire time.
This is also the practical argument for what CISA is now pushing with Binding Operational Directive 26-04, which moves agencies away from the patch-every-KEV-by-the-deadline mindset toward prioritizing on asset exposure, real-world exploitability, and impact, because a vulnerability like this one does not fit the old model at all. In this case, there is no patch to deploy by a deadline (there is no patch at all, more on that later), and the KEV listing trailed the real exploitation by five weeks. The thing that actually determines your risk is whether the affected box is exposed and how it is configured, which is exactly the kind of context the old deadline-driven approach never captured.
Why Your Vulnerability Scanner Will Miss This
Set aside the data gap for a second, because even after the CVE shows up everywhere it should, your vulnerability scanner will likely still struggle with this one. A traditional scanner answers the question “What version is this device running?” and then looks up whether that version is affected. That model works fine when the vulnerability is purely a function of the software version (though it breaks down when we backport security fixes). It falls apart here because the affected version list covers essentially every release. Version alone tells you almost nothing, and the thing that actually determines whether a given switch is vulnerable is its configuration, specifically whether it has a tunnel decapsulation IP configured and whether that decap IP is reachable by an attacker.
That means both the vulnerability and the fix live in configuration, not in a version string. To accurately report on this, a scanner cannot just fingerprint the EOS release; it has to ingest and reason about the device’s running configuration, confirm whether decapsulation is configured, and then evaluate whether the mitigating ACLs are present and correct. Fortunately, we observed this vulnerability when Arista issued the vendor advisory, and the team built a detection that inspects the configuration, examples below:
If your tooling uses version-based detection, the best-case scenario is that it flags every R-series switch on a covered EOS version as vulnerable, even if decap is not configured, which buries you in false positives. The worst-case scenario is that it misreports or simply misses the box entirely. Either way, you cannot trust a green checkmark here.
This is solvable, and it is not even new, because configuration auditing has been a feature in serious vulnerability management products for well over a decade. But configuration auditing only works if someone has done the hard part of defining what a good configuration looks like versus a bad one, and, more specifically for a case like this, what a vulnerable configuration looks like versus a configuration that is technically on an affected version but has the mitigations in place and is therefore not vulnerable. That distinction, good versus bad versus vulnerable versus not-vulnerable, is the entire game with a configuration-driven flaw, and it is work that has to be done per vulnerability, which is precisely why so many scanners will quietly get this one wrong.
The last twist is that there is no software fix, and there is not going to be one. Arista states directly in the advisory that no software upgrade path is planned, citing the risk that changing the decapsulation behavior would break existing deployments that depend on it, so unlike the usual story where you have a patched version to chase, here the resolution is entirely configuration-based, and the burden is entirely on you. The mitigations come down to wrapping access control around the decapsulation process, and Arista offers two broad approaches in the original advisory.
Detection and Mitigation Guidance
If you run Arista R-series switches in any role that involves tunnel termination, consider the following:
- Inventory your tunnel endpoints, not your versions. Run show interfaces vxlan 1, show interfaces Tunnel0, and show ip decap-group across your 7020R, 7280R/R2, and 7500R/R2 fleet to find every device with a decapsulation IP configured. Those are your exposed devices. Version alone does not scope this.
- Map reachability to each decap IP. A configured decap IP is only a problem if an attacker can get a crafted packet to it. Identify which decapsulation addresses are reachable from untrusted or semi-trusted networks and prioritize those first.
- Apply the upstream ACL approach where you can. Permit only the tunnel protocol you actually use to the decap IP and deny all other protocols to that address. Turn on counters per-entry, so you have visibility into blocked attempts.
- Confirm the decap IP is dedicated. Before you tighten anything, verify the tunnel IP is not also carrying BGP, SSH, or other management or control-plane traffic, or your mitigation will cause an outage.
- Watch the ACL counters and your internal segments. Per-entry counters incrementing on the deny rule mean someone is sending non-configured tunnel protocols at your decap IP. Unexpected traffic appearing on internal segments via a tunnel type you never configured is the other indicator of compromise.
- Do not rely on a version-based scan result. If your vulnerability management tooling cannot evaluate device configuration, do not treat its output as authoritative for this CVE. Validate against the actual running config.
- Fix the configuration on both ends of the problem. The vulnerability and the fix both reside in configuration, so remediation is confirmed by the presence and correctness of your ACLs, not by a version bump that will never come.
Frequently Asked Questions
Yes, fevvar54 published a PoC exploit (Note: we have not tested and/or validated this exploit; use with caution).
It is a flaw in which Arista EOS switches decapsulate tunnel traffic without checking the protocol type, so a box configured for one tunnel type will strip and forward traffic from others.
No. Arista says no software fix is planned. Configuration is the only fix.
Because it is not a version bug. Almost every EOS release is affected. The vulnerability lives in your configuration, and most scanners only check versions.
Check for a configured decapsulation IP. Run show ip decap-group, show interfaces vxlan 1, and show interfaces Tunnel0. No decap IP, no exposure.
Yes. Arista flagged exploitation in the wild on May 5. CISA put it on the KEV on June 9. Treat it as live.
Arista published the CVE to their own advisory first. It did not propagate to the public CVE feeds for weeks. If you only watch the feeds, you missed it.
Find every R-series switch with a decap IP. Wrap an ACL around that IP that permits only the tunnel protocol you use. Make sure the IP is not also carrying BGP or SSH first.
Sources
- Arista Security Advisory 0137 (CVE-2026-7473)
- NVD: CVE-2026-7473
- CISA: CISA Adds Three Known Exploited Vulnerabilities to Catalog (June 9, 2026)
- CISA Known Exploited Vulnerabilities Catalog
- SecurityWeek: No Patch Planned for Exploited Arista EOS Vulnerability
- The Hacker News: CISA Adds Cisco, Chrome, and Arista Flaws to KEV Catalog Amid Active Exploitation
- Security Affairs: U.S. CISA adds Cisco SD-WAN, Arista EOS, and Google Chromium V8 flaws to its KEV catalog
- CWE-1023: Incomplete Comparison with Missing Factors
- Paul’s Security Weekly #930: “Trolling Microsoft With Vulnerabilities”
