CVE-2026-7473: Arista Extensible Operating System Incomplete Comparison with Missing Factors Vulnerability

Is it exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on 9 Jun 2026, 4 days after the CVE record was published.

How likely is exploitation in the next 30 days?

1.1%

EPSS score, percentile 65.7 of all scored records

How severe?

6.9 Medium

CVSS v4.0 base score, given by the CNA

What should I do?

CISA deadline 23 Jun 2026. Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

Advisories and patches (1)

Which versions are affected?

Affected

• 4.36.0
• 4.35.0 through 4.35
• 4.34.0 through 4.34
• 4.33.0 through 4.33
• 4.32.0 through 4.32
• 4.31.0 through 4.31

and 1 more in the table below

Versions by product

Source: CISA Known Exploited Vulnerabilities (KEV) catalog, 2026.10.28, as of 28 Oct 2026; FIRST Exploit Prediction Scoring System (EPSS), v2026.06.15, as of 28 Oct 2026; CVE List V5 (CVE Program), cve_2026-10-28_0000Z, as of 28 Oct 2026. About the data.

What to do

CISA due date for this action: 23 June 2026.

Solution (from the CVE record)

No software upgrade path is planned to address this issue due to the risk of breaking existing configuration on deployments. The recommended resolution of this issue is to follow the appropriate mitigation instructions detailed in the workaround block.

Workaround (from the CVE record)

There are two broad approaches to mitigate this issue - (1) applying ACLs on upstream devices or (2) applying ACLs on the devices where the unexpected decapsulation is happening. In both cases, the idea is to either selectively allow only legitimate tunnel traffic or to selectively block malicious tunnel traffic. For example, if a network is configured to forward VXLAN traffic, but GRE traffic is being unexpectedly forwarded, then ACLs can be used to either selectively allow just VXLAN traffic or selectively block GRE traffic. More details about using the ACL feature can be found in the  Arista User Manual https://www.arista.com/en/um-eos/eos-acls-and-route-maps#xx1150869 . A note of caution, the following ACL-based mitigation recommendations assume that the tunnel IP is dedicated solely to receiving the configured tunnel protocol traffic. When adapting these rules for your environment, it is important to explicitly permit any additional protocol traffic—such as BGP or SSH—if that IP serves multiple functions. To maintain connectivity, ensure these permit statements are sequenced before any deny statements directed at the decapsulation IP. The following configurations align with the recommendations outlined in the  Arista EOS Hardening Guide https://arista.my.site.com/AristaCommunity/s/article/arista-eos-hardening-guide#Comm_Kna_ka0Uw00000097VJIAY_71 .

Approach 1 - Applying ACL on Upstream Switches On upstream devices, applying ACLs to allow specific tunneled traffic is straightforward. ACLs can be applied that match on tunnel destination IP, the IP next protocol field, and (optionally) UDP destination port to selectively allow or block specific tunnel protocols. Example ACLs for Arista EOS follows. ACL to permit VXLANv4 Only This IPv4 ACL matches on VXLAN packets as follows: (a) IP next protocol = UDP (17) (b) IP DIP = VXLAN VTEP IP (c) UDP destination port = VXLAN UDP Port (4789) It allows VXLAN packets and drops all other packets to the VXLAN Decap IP. ip access-list foo    counters per-entry    1 permit udp any host <vxlan-decap-ip> eq 4789    2 deny ip any host <decap-ip>    3 permit ip any any   ACL to permit GREv4 Only This IPv4 ACL matches on GRE packets as follows: (a) IP next protocol = GRE (47) (b) IP DIP = GRE Tunnel Destination IP It allows GRE packets and drops all other packets to the GRE Decap IP. ip access-list foo    counters per-entry    1 permit gre any host <gre-decap-ip>    2 deny ip any host <gre-decap-ip>    3 permit any any   ACL to permit IP-in-IPv4 Only This IPv4 ACL matches on IP-in-IPv4 packets as follows: (a) IP next protocol = IPv4 (4) or IPv6 (41) (b) IP DIP = IP-in-IP Decap IP It allows IP-in-IPv4 packets and drops all other packets to the IP-in-IPv4 Decap IP. ip access-list foo    counters per-entry    1 permit 4 any host <ipip-decap-ip>    2 permit 41 any host <ipip-decap-ip>    3 deny ip any host <ipip-decap-ip>    4 permit any any   ACL to Permit IP-in-IPv6 Only This IPv6 ACL matches on IP-in-IPv6 packets as follows: (a) IP next protocol = IPv4 (4) or IPv6 (41) (b) IP DIP = IP-in-IP Decap IP It allows IP-in-IPv6 packets and drops all other packets to the IP-in-IPv6 Decap IP. ipv6 access-list foo    counters per-entry    1 permit 4 any host <ipip-decap-ip>    2 permit 41 any host <ipip-decap-ip>    3 deny ipv6 any host <ipip-decap-ip>…

Approach 2 - Applying ACL on Decapsulation Switches Applying ACLs on the decapsulation device is more complicated. It requires the use of MAC ACLs on 7020R Series, 7280R/R2 Series, and 7500R/R2 Series systems and IP ACLs on 7280R3 Series, 7500R3 Series, and 7800R3 Series systems. In both cases, a TCAM profile update is also required. Note that TCAM profile update is a disruptive operation that could impact traffic forwarding. More information can be found in  User-defined TCAM Profiles https://www.arista.com/en/support/toi/eos-4-26-0f/14755-user-defined-tcam-profiles . 7020R Series, 7280R/R2 Series, and 7500R/R2 Series Mitigation involves using MAC ACLs to allow specific expected protocol packets and block all other traffic to the configured decap IPs. The suggested MAC ACLs use User Defined Fields (UDFs) to match on specific fields in the packet headers. This requires a TCAM profile update to include the following UDF qualifiers: * For IPv4 tunnels, 2 16b and 1 32b UDF qualifiers need to be included. * For IPv6 tunnels, 2 16b and 4 32b UDF qualifiers need to be included. However, in order to make room for the UDF qualifiers, other TCAM features/qualifiers must be removed due to hardware constraints. Following are some suggested TCAM profile changes to accommodate the required UDF qualifiers: * TCAM profile that includes the UDF qualifiers for IPv4 tunnels, but removes support for MPLS: hardware tcam    profile test copy default       feature acl port mac          no key size limit           key field udf-16b-1 udf-16b-2 udf-32b-1       no feature mpls       no feature mpls pop ingress       no feature pbr mpls     * TCAM profile that includes the UDF qualifiers for IPv4 tunnels, but removes support for VXLAN: hardware tcam    profile test copy default       feature acl port mac          no key field src-mac          key field udf-16b-1 udf-16b-2 udf-32b-1      * TCAM profile that includes the UDF qualifiers for IPv6 tunnels, but rem…

Advisories and patches

• arista.com (Vendor advisory)

Linked from CISA's catalog entry

• https://www.arista.com/en/support/advisories-notices/security-advisory/24005-security-advisory-0137
• https://nvd.nist.gov/vuln/detail/CVE-2026-7473

Affected products and versions

As listed in the CVE record.

Versions not listed are: affected.

Source: CVE List V5 (CVE Program), cve_2026-10-28_0000Z, as of 28 Oct 2026. About the data.

About this vulnerability

Arista Extensible Operating System (EOS) contains an incomplete comparison with missing factors vulnerability when the switch incorrectly decapsulate and forwards other unexpected tunneled packet with a destination IP matching its configured decapsulation IP.

Summary: CISA's KEV catalog, as of 28 Oct 2026.

• CISA added CVE-2026-7473 to its Known Exploited Vulnerabilities (KEV) catalog on 9 Jun 2026.
• CISA's ransomware flag for this entry is "Unknown": no evidence of ransomware use in the catalog, which is not proof of none.
• The due date CISA sets for the required action is 23 Jun 2026.
• The CVE record was published on 5 Jun 2026, 4 days before it was added to KEV.
• The CVE record carries a CVSS v4.0 base score of 6.9 (Medium), given by its CNA.
• FIRST's EPSS model puts the probability of exploitation in the next 30 days at 1.1% (percentile 65.7), as of 28 Oct 2026.
• CISA's SSVC assessment in the CVE record: exploitation active, automatable yes, technical impact total.

Source: CISA Known Exploited Vulnerabilities (KEV) catalog, 2026.10.28, as of 28 Oct 2026; CVE List V5 (CVE Program), cve_2026-10-28_0000Z, as of 28 Oct 2026; FIRST Exploit Prediction Scoring System (EPSS), v2026.06.15, as of 28 Oct 2026. About the data.

Description

Arista EOS Unexpected Tunnel Protocol Decapsulation and Forwarding Bypass

On affected platforms running Arista EOS where a tunnel decapsulation configuration—such as VXLAN (Virtual Extensible LAN), decap-groups, or a GRE (Generic Routing Encapsulation) tunnel interface—is present, the switch will incorrectly decapsulate and forward other unexpected tunneled packet with a destination IP matching its configured decapsulation IP. This occurs because the switch does not verify the tunnel protocol type, potentially leading to the unexpected processing of non-configured tunnel traffic. This issue has been reported as being exploited in the wild.

Source: CVE List V5 (CVE Program), cve_2026-10-28_0000Z, as of 28 Oct 2026. About the data.

Weakness

• CWE-1023: Incomplete Comparison with Missing Factors

Attack patterns (CAPEC)

• CAPEC-272: Protocol Abuse

CWE and CAPEC are maintained by MITRE; the entries are those named in the CVE record and the KEV entry.

Timeline

More exploited Arista vulnerabilities

• CVE-2026-114625: Arista VeloCloud Orchestrator SQL Injection Vulnerability (added 23 Oct 2026)
• CVE-2026-93952: Arista VeloCloud Orchestrator Improper Input Validation Vulnerability (added 22 Sep 2026)
• CVE-2026-16812: Arista VeloCloud Orchestrator On-Prem OS Command Injection Vulnerability (added 27 Jul 2026)