CVE-2026-73444: Arista EOS VRRPv2 Authentication Bypass

CVE-2026-73444 Overview

CVE-2026-73444 is an authentication bypass vulnerability in Arista EOS implementations of the Virtual Router Redundancy Protocol version 2 (VRRPv2) when configured with IP Authentication Header (IP-AH) authentication. An unauthenticated attacker with access to the layer 2 network segment on which VRRP is running can bypass the authentication check and claim the virtual router master role. Once elected master, the attacker controls the virtual gateway address and can intercept, modify, or discard traffic that hosts on the segment send through that gateway. The flaw is classified under [CWE-303: Incorrect Implementation of Authentication Algorithm].

Critical Impact
Adjacent-network attackers can hijack the VRRP virtual gateway, positioning themselves as a man-in-the-middle for all traffic destined to the shared virtual IP address.

Affected Products

Arista EOS with VRRPv2 configured
Arista EOS deployments using IP Authentication Header (IP-AH) authentication for VRRP
Refer to Arista Security Advisory #0157 for the affected release trains

Discovery Timeline

2026-09-15 - CVE-2026-73444 published to the National Vulnerability Database
2026-09-16 - Record last modified in NVD

Technical Details for CVE-2026-73444

Vulnerability Analysis

VRRP allows multiple routers on the same layer 2 segment to share a virtual IP address that acts as the default gateway for local hosts. The router with the highest advertised priority is elected master and answers ARP requests for the virtual IP. VRRPv2 optionally uses IP-AH to cryptographically authenticate advertisement messages so only trusted routers can participate in election.

On affected Arista EOS versions, the IP-AH authentication check for VRRPv2 advertisements is not enforced correctly. The device accepts VRRP advertisements that should be rejected, allowing an attacker on the same broadcast domain to inject a crafted advertisement with a higher priority. The legitimate master then relinquishes the role.

Once the attacker holds the master role, hosts continue to resolve the virtual IP to the attacker's MAC address. Traffic to the virtual gateway is delivered to the attacker's interface, enabling passive interception, active modification, or selective drops that degrade availability.

Root Cause

The root cause is an incorrect implementation of the authentication algorithm ([CWE-303]) for VRRPv2 IP-AH. The protection intended to gate participation in the election process fails to reject unauthenticated or improperly authenticated advertisements, defeating the security guarantee of IP-AH.

Attack Vector

Exploitation requires adjacent network access. The attacker must be positioned on the same layer 2 segment as the VRRP speakers, either through a compromised host, a rogue device plugged into the switch fabric, or a wireless client bridged to the VLAN. No credentials or user interaction are required.

The attacker crafts a VRRPv2 advertisement (IP protocol 112) with a priority higher than the current master and sends it to the VRRP multicast group 224.0.0.18. The vulnerable EOS device accepts the message despite failing IP-AH validation, and the attacker is elected master.

See the Arista Security Advisory #0157 for protocol-level detail.

Detection Methods for CVE-2026-73444

Indicators of Compromise

Unexpected VRRP master state transitions in EOS logs, particularly rapid or repeated failovers on segments that were previously stable
VRRP advertisements sourced from MAC or IP addresses not belonging to any authorized router in the VRRP group
ARP cache entries on hosts showing the virtual gateway IP mapped to an unexpected virtual MAC (00:00:5e:00:01:XX) origin

Detection Strategies

Enable and monitor VRRP state-change syslog messages on all EOS switches participating in a VRRP group
Correlate MAC address learning events on access ports with VRRP advertisement sources to identify rogue speakers on non-router ports
Use packet capture on the VRRP VLAN to inspect IP protocol 112 traffic and verify that advertisements originate only from authorized peers

Monitoring Recommendations

Alert on any new device transmitting to the 224.0.0.18 multicast group
Baseline the expected VRRP master and preempt behavior per group and alert on deviations
Forward EOS logs to a centralized SIEM or data lake and build detections for unauthorized VRRP priority changes

How to Mitigate CVE-2026-73444

Immediate Actions Required

Inventory all EOS devices with VRRPv2 configured and identify those relying on IP-AH authentication
Apply the fixed EOS release listed in Arista Security Advisory #0157
Restrict physical and logical access to VLANs carrying VRRP traffic to trusted infrastructure only

Patch Information

Arista has published fixed software releases in Security Advisory #0157. Consult the advisory for the specific patched versions that correspond to your deployed EOS train, and follow the vendor's recommended upgrade path.

Workarounds

Migrate affected VRRP groups to VRRPv3, which does not rely on the vulnerable IP-AH authentication mechanism
Isolate VRRP-speaking interfaces on dedicated VLANs with no untrusted host access
Deploy port security or 802.1X on access ports to prevent rogue devices from joining the VRRP broadcast domain
Use control-plane ACLs to permit VRRP advertisements only from known router IP addresses on trusted uplinks

bash

# Configuration example: restrict VRRP source addresses via a control-plane ACL
ip access-list vrrp-guard
   permit vrrp host 10.0.0.2 host 224.0.0.18
   permit vrrp host 10.0.0.3 host 224.0.0.18
   deny   vrrp any host 224.0.0.18 log
   permit ip any any