CVE-2026-7473 — Arista EOS Tunnel Decapsulation Bypass

CVE-2026-7473 is an incomplete-comparison / missing-factor flaw (CWE-697) in Arista Extensible Operating System (EOS). On a switch configured as a tunnel endpoint, EOS does not verify the tunnel protocol type before decapsulating. Any packet whose destination IP matches the configured decapsulation IP is decapsulated and forwarded — even if it carries a tunnel protocol the device was never configured to terminate (e.g., a GRE or IP-in-IP packet hitting a VXLAN VTEP IP).

The defensive consequence is what matters: an attacker who can route a crafted outer packet to the decap IP can inject inner packets directly onto internal segments behind the switch, bypassing the segmentation/ACL boundary the tunnel endpoint was supposed to enforce. This turns a routing/edge device into an unintended ingress path into "unreachable" internal networks.

Arista confirms exploitation in the wild; CISA added it to the KEV catalog on 2026-06-09 with a two-week federal remediation deadline. No software patch is planned — fixing it risks breaking live tunnel deployments — so remediation is configuration-only (ACLs) or device retirement. Affected: 7020R, 7280R/R2, 7500R/R2 fully; 7280R3/7500R3/7800R3 for IP-in-IPv6 and GUEv6 decap-group cases.

Telemetry reality: This is a network-infrastructure flaw. CrowdStrike Falcon has no endpoint sensor on the switch itself. The hunt therefore targets consequences on managed hosts — inbound connections from sources that should have been segmented away, traffic to/from internal hosts behind the affected switch, lateral movement and recon originating from newly-reachable segments — plus Arista syslog (VXLAN/GRE/decap config + ACL-deny events) where Next-Gen SIEM ingests it.

Defender priority: Treat every device with an active VXLAN VTEP, GRE tunnel, or decap-group as an open segmentation hole until a protocol-pinning ACL is applied. Apply the upstream/decap ACLs (Section 12), then hunt for hosts behind those VTEPs receiving connections from sources that have no legitimate path to them (Section 8, Q1–Q4).

Intel gaps: No public IOCs, no named threat actor, no exploit PoC, and no discoverer attribution were published. There are no atomic indicators (hashes/domains/IPs) for this flaw — exploitation is a crafted packet, not a payload. The hunt is therefore behavioral / consequence-driven, and the IOC appendix uses config-state and behavioral signatures rather than file hashes.

Hunt hypotheses (high-fidelity first)

1. H1 — Newly-reachable internal hosts (high): Hosts on segments that sit behind an affected VTEP/decap IP begin receiving inbound connections from source IPs/zones that previously had no route to them. Falcon NetworkConnectIP4 on those hosts shows new remote peers crossing the segmentation boundary.
2. H2 — Recon from a newly-reachable segment (high): A host behind the switch is the target of port-scan / sweep behavior (many distinct destination ports or many internal hosts touched from one external/cross-segment source) shortly after the decap path opens.
3. H3 — Inbound admin/SMB/RDP from out-of-policy source (high): Listening services (SMB 445, RDP 3389, WinRM 5985/5986, SSH 22) on internal hosts accept inbound sessions from source addresses outside the expected management plane.
4. H4 — Lateral movement fan-out from a beachhead (medium): The first host reached via the decap path begins authenticating outward to multiple internal peers (T1021), indicating the injected access is being used to pivot.
5. H5 — Arista config-change / decap enablement (medium, NGSIEM): Syslog from EOS shows a new/changed interface Vxlan, interface Tunnel, or ip decap-group — a fresh decap endpoint is a fresh exposure that must be ACL-pinned immediately.
6. H6 — Mitigation-ACL deny hits (medium, NGSIEM): Once protocol-pinning ACLs are deployed (Section 12), counters per-entry deny-rule hits on the decap IP are direct evidence of attempted exploitation of the wrong-protocol path.

Attack chain

No atomic IOCs (hashes / domains / IPs) are published for CVE-2026-7473 — exploitation is a crafted packet, not malware. The "indicators" below are config-state and behavioral. Populate the host/segment placeholders from your own network inventory.

The single most valuable instrumentation step is ensuring EOS syslog ships to Next-Gen SIEM and that Falcon sensors are deployed on the hosts that live behind each VTEP/decap segment. Without one of those two, the switch-side exploit is invisible and only late-stage lateral movement remains detectable.

On the Arista switch (EOS CLI)

Run these to confirm whether a device is a vulnerable decap endpoint (per Advisory 0137):

! Is there an active VXLAN VTEP?
show interfaces vxlan 1            ! vulnerable if "active with <IP>"
! Active GRE tunnel?
show interfaces Tunnel0           ! vulnerable if active source & destination
! Decap groups (GUE / IP-in-IP / NVGRE)?
show ip decap-group
! After deploying mitigation ACLs, watch the deny counters:
show ip access-lists foo          ! non-zero deny-rule hits = attempted exploit

Firewall / netflow (upstream of the decap IP)

• Hunt for inbound packets to the decap IP carrying a tunnel protocol other than the one the device is configured to terminate (e.g., GRE/proto-47 or IP-in-IP/proto-4 to a VXLAN/UDP-4789 VTEP).
• Baseline expected source ranges for legitimate tunnel traffic; alert on decap-IP traffic from outside that set.

Arista syslog (if not yet in NGSIEM)

• Grep for config-session commits adding interface Vxlan, interface Tunnel, or ip decap-group.
• Grep for ACL log entries on the decap IP once logging is enabled on the deny rule.

These hunts run on downstream host telemetry and (Q6/Q7) on Arista syslog parsed into Next-Gen SIEM. Replace REPLACE_WITH_* placeholders with your VTEP/decap IPs, the CIDR(s) sitting behind each VTEP, and your legitimate management-source ranges. The switch itself has no Falcon sensor — see the Coverage Map (Section 15) for the honest gaps.

// HUNT: Inbound to behind-VTEP host from out-of-policy source
// MITRE: T1599, T1599.001
// CONF: medium  FP: medium  COST: medium | REQUIRES: NetworkConnectIP4 on downstream hosts
// FALSE POSITIVES: new legitimate peers, vuln scanners, backup/replication sources
// TUNING: keep REPLACE_WITH_SEGMENT_CIDR tight to the hosts behind the VTEP; widen the allow-list as legit sources are confirmed
#event_simpleName=NetworkConnectIP4
| ConnectionDirection=1
| in(field="LocalAddressIP4", values=[REPLACE_WITH_SEGMENT_CIDR])
| RemoteAddressIP4=* RemoteAddressIP4!=10.* RemoteAddressIP4!=192.168.*
| RemoteAddressIP4!=REPLACE_WITH_ALLOWED_SRC_CIDR
| groupBy([RemoteAddressIP4, LocalAddressIP4, RemotePort, aid, ComputerName], function=count(as=hits))
| sort(hits, order=desc, limit=200)
| table([RemoteAddressIP4, LocalAddressIP4, RemotePort, ComputerName, aid, hits], limit=200)

// HUNT: Recon sweep into a behind-VTEP segment
// MITRE: T1046
// CONF: high  FP: medium  COST: medium | REQUIRES: NetworkConnectIP4 on downstream hosts
// FALSE POSITIVES: authorized vuln scanners, NMS asset discovery
// TUNING: exclude scanner source IPs; raise distinct-port/host thresholds to fit baseline
#event_simpleName=NetworkConnectIP4
| ConnectionDirection=1
| in(field="LocalAddressIP4", values=[REPLACE_WITH_SEGMENT_CIDR])
| RemoteAddressIP4!=REPLACE_WITH_SCANNER_CIDR
| groupBy([RemoteAddressIP4], function=[count(LocalAddressIP4, as=distinct_hosts, distinct=true), count(RemotePort, as=distinct_ports, distinct=true), count(as=conns)])
| distinct_hosts >= 10 OR distinct_ports >= 20
| sort(distinct_hosts, order=desc, limit=100)
| table([RemoteAddressIP4, distinct_hosts, distinct_ports, conns], limit=200)

// HUNT: Inbound admin protocols from out-of-policy source
// MITRE: T1021
// CONF: high  FP: medium  COST: low | REQUIRES: NetworkConnectIP4 on downstream hosts
// FALSE POSITIVES: jump boxes, admin workstations, patch/management servers
// TUNING: maintain REPLACE_WITH_MGMT_CIDR as the only authorized admin-source set
#event_simpleName=NetworkConnectIP4
| ConnectionDirection=1
| in(field="LocalAddressIP4", values=[REPLACE_WITH_SEGMENT_CIDR])
| in(field="RemotePort", values=["445","3389","22","5985","5986"])
| RemoteAddressIP4!=REPLACE_WITH_MGMT_CIDR
| groupBy([RemoteAddressIP4, LocalAddressIP4, RemotePort, ComputerName, aid], function=count(as=hits))
| sort(hits, order=desc, limit=200)
| table([RemoteAddressIP4, LocalAddressIP4, RemotePort, ComputerName, aid, hits], limit=200)

// HUNT: Lateral fan-out from a behind-VTEP beachhead
// MITRE: T1021, T1210
// CONF: medium  FP: medium  COST: medium | REQUIRES: NetworkConnectIP4 on downstream hosts
// FALSE POSITIVES: DCs, SCCM/Ansible, monitoring agents (naturally fan out)
// TUNING: exclude known fan-out server AIDs; tune distinct-peer threshold to baseline
#event_simpleName=NetworkConnectIP4
| ConnectionDirection=0
| in(field="LocalAddressIP4", values=[REPLACE_WITH_SEGMENT_CIDR])
| in(field="RemotePort", values=["445","3389","22","5985","5986","135"])
| groupBy([aid, ComputerName], function=[count(RemoteAddressIP4, as=distinct_peers, distinct=true), count(as=conns)])
| distinct_peers >= 8
| sort(distinct_peers, order=desc, limit=100)
| table([ComputerName, aid, distinct_peers, conns], limit=200)

// HUNT: Remote logon to behind-VTEP host (correlate with Q1/Q3)
// MITRE: T1021
// CONF: medium  FP: medium  COST: low | REQUIRES: UserLogon on downstream hosts
// FALSE POSITIVES: normal network/RDP logons abound; use only to corroborate a flagged source
// TUNING: scope ComputerName to the behind-VTEP host list; join to Q1/Q3 timeframe
#event_simpleName=UserLogon
| in(field="LogonType", values=["3","10"])
| in(field="ComputerName", values=[REPLACE_WITH_BEHIND_VTEP_HOSTS])
| groupBy([ComputerName, UserName, LogonType, RemoteAddressIP4], function=count(as=logons))
| sort(logons, order=desc, limit=200)
| table([ComputerName, UserName, LogonType, RemoteAddressIP4, logons], limit=200)

// HUNT: Arista mitigation-ACL deny hits on decap IP
// MITRE: T1190, T1599
// CONF: high  FP: low  COST: low | REQUIRES: EOS syslog in NGSIEM (ACL deny logging enabled)
// FALSE POSITIVES: misconfigured ACL denying legitimate co-resident traffic (BGP/SSH on same IP)
// TUNING: ensure the ACL explicitly permits legit co-resident protocols before relying on deny=malicious
#repo=*
| @rawstring=/%(ACL|SECURITY)-\d-[A-Z_]*DENY/
| @rawstring=/(?<dst>REPLACE_WITH_DECAP_IP)/
| @rawstring=/(?<proto>gre|ipinip|ip-in-ip| proto \d+|udp)/i
| groupBy([dst, proto], function=count(as=denies))
| sort(denies, order=desc, limit=100)
| table([dst, proto, denies], limit=200)

// HUNT: EOS config change adding a decap endpoint
// MITRE: T1542
// CONF: medium  FP: low  COST: low | REQUIRES: EOS config syslog in NGSIEM
// FALSE POSITIVES: approved network changes; correlate against change tickets
// TUNING: suppress events whose source user/session matches an approved change window
#repo=*
| @rawstring=/(interface Vxlan|interface Tunnel\d+|ip decap-group)/i
| @rawstring=/(CONFIG|SESSION|cmd=)/i
| groupBy([@host, @rawstring], function=count(as=hits))
| sort(hits, order=desc, limit=100)
| table([@host, @rawstring, hits], limit=200)

Custom IOAs operate on endpoint sensor behavior. Because the switch has no Falcon sensor and the exploit is a network packet, there is no clean IOA pattern for the exploit itself. IOAs here target the downstream consequence and should be promoted only after the network hunts (Q1–Q4) are baselined.

All remaining queries (Q1, Q2, Q5, Q6, Q7) are investigate-only hunt / scheduled-search detections — run on a schedule and triage hits; they are not IOA-promotable.

No atomic file/domain/hash IOCs exist for this flaw. The quick-copy blocks below are the operational equivalents: config-state checks, behavioral signatures, the mitigation-ACL audit, and a Falcon IOC-Management CSV scaffold for any campaign infrastructure you later attribute to exploitation.

show interfaces vxlan 1        # active with <IP> => vulnerable
show interfaces Tunnel0        # active source/dest => vulnerable
show ip decap-group            # any group => vulnerable (GUE/IPinIP/NVGRE)
show ip access-lists foo       # deny-rule hits => attempted exploit

SIG1 inbound to behind-VTEP host from source outside allowed CIDR
SIG2 single source touches >= 10 hosts OR >= 20 ports in a behind-VTEP segment
SIG3 inbound 445/3389/22/5985/5986 from outside mgmt CIDR
SIG4 behind-VTEP host fans out to >= 8 internal admin-port peers
SIG5 EOS ACL deny on decap IP (wrong-protocol packet)

# Every active VTEP/GRE/decap IP MUST have a protocol-pinning ACL.
# VXLAN-only example (permit UDP 4789, deny all else to decap IP):
ip access-list foo
   counters per-entry
   1 permit udp any host REPLACE_WITH_DECAP_IP eq 4789
   2 deny ip any host REPLACE_WITH_DECAP_IP
   3 permit ip any any
# NOTE: explicitly permit BGP/SSH first if the IP is multi-use.

type,value,action,severity,expiration,description,tags
ipv4,REPLACE_WITH_ATTACKER_SRC,detect,high,2026-09-15,CVE-2026-7473 decap exploit source,campaign:AristaDecap
ipv4,REPLACE_WITH_DECAP_IP,enrich,medium,2026-07-15,Arista decap endpoint (asset),campaign:AristaDecap

Playbook A — Upstream ACL (Approach 1), VXLAN-only example

# On the upstream switch/router in front of the decap IP.
# Permit only legitimate VXLAN (UDP 4789); deny everything else to decap IP.
ip access-list foo
   counters per-entry
   1 permit udp any host REPLACE_WITH_DECAP_IP eq 4789
   2 deny ip any host REPLACE_WITH_DECAP_IP
   3 permit ip any any
!
# GRE-only variant:
ip access-list gre-pin
   counters per-entry
   1 permit gre any host REPLACE_WITH_GRE_DECAP_IP
   2 deny ip any host REPLACE_WITH_GRE_DECAP_IP
   3 permit ip any any
!
# Bind the ACL to the ingress interface(s) facing untrusted networks:
interface Ethernet1
   ip access-group foo in

Playbook B — Decap-device MAC/UDF ACL (Approach 2), 7280R/7500R VXLAN v4

# Requires a TCAM profile with UDF key fields (consumes TCAM; may drop MPLS).
hardware tcam
   profile tunnelpin copy default
      feature acl port mac
         no key size limit
         key field udf-16b-1 udf-16b-2 udf-32b-1
      no feature mpls
!
mac access-list payload alias ip-next-protocol-udp offset 2 pattern 0x00110000 mask 0xff00ffff
mac access-list payload alias ip-dip-decap-ip      offset 4 pattern 0xREPLACEHEX mask 0x00000000
mac access-list payload alias udp-dport-vxlan      offset 5 pattern 0x000012b5 mask 0xffff0000
!
mac access-list foo
   counters per-entry
   1 permit any any ip payload alias ip-next-protocol-udp alias ip-dip-decap-ip alias udp-dport-vxlan
   2 deny   any any ip payload alias ip-dip-decap-ip
   3 permit any any

Playbook C — Verify & monitor

# Confirm the ACL is bound and counting:
show ip access-lists foo
# Confirm which decap endpoints still exist:
show interfaces vxlan 1
show interfaces Tunnel0
show ip decap-group
# Forward syslog to NGSIEM (so Q6/Q7 fire):
logging host REPLACE_WITH_SIEM_COLLECTOR
logging level ACL informational

Do not deploy blind: if the decap IP also carries BGP/SSH/management, add explicit permit rules for those protocols above the deny rule, or you will break the control plane. Pilot on one device in a maintenance window.

Honest gaps: the exploit itself (attack-chain step 2) occurs entirely on the switch, where Falcon has no sensor — it is undetectable until it produces a downstream consequence or hits a mitigation-ACL deny counter. All host-side hunts assume Falcon sensors exist on the behind-VTEP segment and that you can enumerate that host/CIDR set; where you cannot, those rows drop to GAP. EOS syslog ingest into Next-Gen SIEM is the single dependency that unlocks Q6/Q7. Validation gates (Section 11) must pass — especially benign baselining of Q1–Q4 — before any promotion to alerting.

Detections are portable templates. Replace REPLACE_WITH_* placeholders with your own VTEP/decap IPs, behind-VTEP segment CIDRs, and management/scanner source ranges, and validate field names in your tenant before scheduling.