CVE-2026-73462 in EOS
Summary
by MITRE • 09/16/2026
On affected platforms running Arista EOS with IGMP (Internet Group Management Protocol) snooping configured (enabled by default on all VLANs), a network-adjacent unauthenticated attacker can send malformed network packets on an affected VLAN to cause the IGMP snooping agent to terminate unexpectedly. This results in a temporary disruption of multicast traffic management, which may cause multicast traffic to be flooded to all ports of the affected VLAN until the service recovers. Repeated exploitation could result in a prolonged loss of intended multicast forwarding behavior.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified involves a critical flaw within the Internet Group Management Protocol (IGMP) snooping agent present in Arista EOS operating systems, specifically affecting platforms where this feature is enabled by default across all VLANs. This security issue allows for remote exploitation by an unauthenticated attacker who possesses network adjacency to the affected switch. The core technical deficiency lies in the input validation mechanisms of the IGMP snooping process, which fails to adequately sanitize or verify incoming multicast control packets. When a malicious actor transmits specifically crafted malformed network packets into the targeted VLAN, they trigger an exception condition within the software that causes the IGMP snooping agent to crash and terminate unexpectedly. This behavior classifies as a denial of service vulnerability resulting from improper input validation, aligning with CWE-20 Improper Input Validation in standard security taxonomies.
The operational impact of this flaw is significant for network stability and performance integrity. Upon termination of the IGMP snooping process, the switch loses its ability to intelligently manage multicast traffic flows based on group membership reports. Consequently, the device reverts to a fallback state where it floods all incoming multicast packets out through every port within the affected VLAN rather than forwarding them only to interested receivers. This flooding behavior creates substantial unnecessary network congestion and consumes bandwidth that could otherwise be allocated to legitimate unicast or properly targeted multicast traffic. Furthermore, this disruption compromises the confidentiality of data streams intended for specific groups, as they become visible to all devices on the broadcast domain, potentially exposing sensitive information to unauthorized parties within the same VLAN segment.
Repeated exploitation of this vulnerability can lead to a prolonged loss of intended multicast forwarding behavior if the service does not recover automatically or requires manual intervention by network administrators. The intermittent nature of the crash means that during periods when the agent is down, the network operates inefficiently and insecurely. This scenario aligns with ATT&CK technique T1498 Network Denial of Service, as it degrades the availability and performance of critical network services without requiring authentication credentials. Attackers can leverage this capability to disrupt business-critical applications that rely on multicast communication, such as video streaming services, financial market data feeds, or real-time collaboration tools hosted within the enterprise LAN.
Mitigation strategies should focus primarily on applying vendor-provided software updates that patch the underlying code defect in the IGMP snooping implementation. Until patches are available, network administrators can mitigate risk by disabling IGMP snooping on VLANs where it is not strictly necessary for multicast traffic management, although this may impact other legitimate multicast applications. Additionally implementing strict access control lists to restrict source IP addresses allowed to send IGMP messages from untrusted segments or hosts can reduce the attack surface. Monitoring tools should be configured to detect abnormal spikes in multicast packet volumes across VLANs, which would indicate active flooding resulting from a successful exploitation of this vulnerability. Regular auditing of network configurations and keeping firmware up to date are essential practices for maintaining resilience against such protocol-level exploits.