Arista EOS vulnerabilities

On affected platforms running Arista EOS with IGMP 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.

Under certain circumstances on affected platforms running Arista EOS with gRPC Network Packet Sampling Interface (gNPSI) enabled, the gNPSI client credentials might be logged in clear text in local or remote accounting logs to authenticated users.

On affected platforms running Arista EOS with VRRPv2 IP-AH authentication configured, an unauthenticated attacker within the same layer 2 network segment on which VRRP is running can capture a legitimate authenticated VRRP advertisement and replay it indefinitely. Replayed advertisements can be used to advertise stale VRRP state, for example to prevent a backup router from taking over the virtual gateway after the original master has gone down.

On Arista EOS platforms with VRRP enabled, peer device VRRP authentication credentials are logged in cleartext. An authenticated user with sufficient privileges can read these credentials from agent trace logs or from a system receiving forwarded log output, without access to the network segment running VRRP.

On affected platforms running Arista EOS, an unauthenticated attacker who is network-adjacent to the switch and able to connect to a device with PIM Sparse Mode and MLAG configured can send malformed messages that cause the Pimsm agent to terminate unexpectedly. The agent is automatically restarted, but repeated attacks can cause continuous restarts and a sustained denial of service.

Arista EOS versions before 4.11.12, 4.12 before 4.12.11, 4.13 before 4.13.14M, 4.14 before 4.14.5FX.5, and 4.15 before 4.15.0FX1.1 allow remote attackers to execute arbitrary code as root by leveraging management-plane access.

Under certain circumstances on affected platforms running Arista EOS with gRPC Network Packet Sampling Interface (gNPSI) enabled, an unauthenticated gNPSI client can craft a malicious request to allow arbitrary code execution, granting an attacker full administrative control over the compromised switch.

An unauthenticated actor with network access to the private HA interconnect may trigger sensitive HA peer functions without verification. This could result in elevated command execution on Edge units where HA is enabled.

An unauthenticated P4Runtime client can achieve arbitrary code execution under certain conditions on affected platforms running Arista EOS configured with P4Runtime. By crafting a malicious packet during session initiation, an attacker can obtain complete administrative control over the switch.

A privileged attacker can exploit gNSI Certz service on Arista EOS-based products to escalate privileges and execute arbitrary OS commands via a crafted Certz Rotate request. The Bootz service is also affected.

On affected platforms running Arista EOS with Dynamic Host Configuration Protocol (DHCP) relay configured, an unauthenticated attacker with network access could send a crafted DHCP reply packet from an IP address that is not configured as a helper address, and the relay agent would forward it to clients without validating the source.

On platforms running Arista EOS with OpenConfig configured, a gNMI Set request can be run when it should have been rejected. This can result in unexpected configuration being applied to the switch.

Platforms running Arista EOS with OpenConfig configured may accept gNMI Set requests that should have been rejected, leading to unexpected configuration changes on the switch.

On specific platforms using Arista EOS with a loose Unicast Reverse Path Forwarding (uRPF) configuration, certain traffic may not be subjected to the intended verification drop. Consequently, traffic that should be dropped based on these routes could still be processed and forwarded by the device.

A specially crafted packet can cause the premature expiry of multicast forwarding state on affected interfaces. This may result in temporary multicast traffic loss during the affected period.

On affected platforms running Arista EOS with OSPFv3 configured, a specially crafted packet can cause the OSPFv3 agent to restart unexpectedly.

On affected platforms running Arista EOS with SNMP configured, SNMPv3 local or remote user credentials may be exposed as a one-way hashed, localized key value within the device's running and sanitized configurations. An authenticated user who gains access to this information could use it for unauthorized read operations on SNMP tables or to send fraudulent trap notifications to the NMS.

On affected platforms running Arista EOS with OSPFv3 configured, an unauthenticated attacker on the same OSPFv3 broadcast domain can send a specially crafted set of packets that can cause the Ospf3 agent to restart unexpectedly. The crash results in the loss of all OSPFv3 adjacencies on the affected device and may disrupt routing across the broader OSPF domain until the agent recovers.

On affected platforms running Arista EOS with OSPFv2 and OSPFv2 segment routing configured, a specially crafted OSPFv2 packet from an adjacent OSPF neighbor may cause OSPF to restart unexpectedly.

On affected platforms running Arista EOS with OSPFv2 configured, a specially crafted OSPFv2 packet from an unauthenticated attacker on the same broadcast segment, with OSPFv2 authentication configured, can cause adjacency flapping and packet loss. The disruption can affect routing across the broader OSPF domain.

On affected platforms running Arista EOS, an authenticated user with access to gNMI (gRPC Network Management Interface) may receive incorrect authorization results, potentially allowing access beyond their currently assigned permissions.

On affected platforms running Arista EOS with gRPC Network Management Interface (gNMI) enabled, a specially crafted request could allow a malicious authenticated client with gNMI access to execute arbitrary code with root privileges on the switch.

On affected platforms running Arista EOS, when multiple gRPC Network Security Interface (gNSI) transports are configured, a race condition in the gNSI Authz service may cause a policy rotation to fail silently. An authenticated user whose access was revoked by the new policy may retain unauthorized access to gRPC interfaces. This does not affect Bootz. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation.

On affected EOS platforms with AAA-based gRPC authorization enabled for OpenConfig, gRPC requests of an authenticated user to OpenConfig may use the wrong privilege level, resulting in an authorization using the wrong AAA method list. This does not impact non-gRPC OpenConfig requests such as NETCONF.

On affected platforms running Arista EOS with gRPC Network Security Interface (gNSI) Credentialz configured, a specially crafted request can cause unintended modifications to the target account's properties. This may result in the account being assigned elevated privileges or access beyond what an administrator intended.

On Arista EOS platforms, an issue with the gRPC Network Security Interface (gNSI) Authz Rotate RPC may cause an incorrect Authz policy uploaded in the ongoing RPC stream to become active. This does not affect Bootz. The issue was discovered internally by Arista, and the company is not aware of any malicious uses in customer networks.

On Arista EOS platforms with OpenConfig and a gNMI server, when gNSI Pathz is configured with a policy containing both a group rule and a user rule for the same path, gNMI may fail to enforce the policy correctly. Under certain conditions, an authenticated user may gain unauthorized read or write access to gNMI paths that the Pathz policy intended to restrict.

On Arista EOS platforms with OpenConfig-related services (gNMI, gNSI, RESTCONF, NETCONF), sensitive requests and responses may be unintentionally logged. These logs may be stored locally or sent to remote accounting servers. Examples include sensitive CLI commands and sensitive OpenConfig YANG leafs.

On affected platforms running Arista EOS with MLAG Dual Primary Detection configured, an unauthenticated attacker with access to the Dual Primary Detection network segment can send specially crafted packets to interfere with the dual-primary state. If the MLAG primary switch fails while these packets are present, the secondary switch incorrectly concludes it is in a dual-primary condition and err-disables its interfaces, leading to a traffic interruption.

On affected platforms running Arista EOS with IS-IS graceful restart enabled, an unauthenticated attacker who can inject a malformed IS-IS LSP PDU packet can cause the IS-IS graceful restart procedure to terminate prematurely. This may result in traffic loss following a restart event.

On affected platforms running Arista EOS with IS-IS configured, an unauthenticated attacker can inject a specially crafted IS-IS LSP PDU, causing the legitimate LSP to be unexpectedly purged from the IS-IS link-state database. This may result in traffic loss.

On affected platforms running Arista EOS with IS-IS configured on a broadcast interface, an unauthenticated attacker can send a crafted IS-IS Hello PDU that causes the device to tear down an established IS-IS adjacency. This may result in traffic disruption and loss of IP reachability for prefixes advertised through that adjacency.

On affected platforms running Arista EOS with VRRPv2 IP Authentication Header (IP-AH) authentication configured, an unauthenticated attacker with access to the layer 2 network segment on which VRRP is running could bypass VRRP authentication and claim the virtual router master role, enabling the attacker to intercept, modify, or discard traffic that hosts on the segment send to the virtual gateway address.

On affected platforms running Arista EOS with DHCP relay/snooping configured with the information option (Option 82), or with the DHCP server configured with match criteria based on the information option, an unauthenticated attacker connected to a client-facing VLAN where the relay is configured can send a specially crafted packet that causes the DHCP Relay service to restart.

On affected platforms running Arista EOS with authenticated Bidirectional Forwarding Detection (BFD) sessions configured, a specially crafted packet can cause the BFD session(s) to go down. This may result in undesirable network changes because various routing protocols monitor status on BFD session(s).

On Arista EOS platforms, under certain circumstances, plaintext shared secrets for configured TACACS+ servers may be exposed. The issue affects systems running Arista EOS.

On Arista EOS platforms, under certain circumstances, user passwords may be written in cleartext to log files when specialized non-standard debugging trace levels are explicitly enabled. Exploitation requires authenticated local administrative access to the device shell.

On Arista EOS platforms, under certain circumstances, plaintext private keys may be written in cleartext to log files when specialized non-standard debugging trace levels are explicitly enabled. Exploitation requires authenticated local administrative access to the device shell.

On Arista EOS platforms with dual switch cards and ingress Security ACLs configured on shared-mode Switched Virtual Interfaces (SVI), restarting the secondary switchcard forwarding agent or inserting the secondary switchcard can cause Security ACLs on shared SVIs to stop functioning. This may result in incorrect packet permit/deny behavior.

On affected platforms running Arista EOS with password authentication configured, a specially crafted password can create orphan authentication sessions. Repeated exploitation can exhaust authentication resources, preventing legitimate users from logging in.

On affected platforms running Arista EOS with both 802.1X port authentication and the RADIUS proxy feature configured with dynamic authorization, a low-privileged attacker on an adjacent network segment who induces a RADIUS packet through a configured RADIUS proxy client can prevent RADIUS dynamic authorization messages, including Change-of-Authorization (CoA) and Disconnect-Requests as defined in RFC 5176, from being applied to locally authenticated 802.1X sessions. This allows an endpoint session that a RADIUS server or network access control system has ordered disconnected to remain authorized on the network.

Vulnerability in Arista EOS with IPsec configured. A specially crafted packet can stop all IPsec traffic processing in the dataplane. After reset, traffic may not resume. Non-IPsec traffic is unaffected.

On affected platforms running Arista EOS with MACsec and egress ACLs configured on the same interfaces, the ACL policies may not be enforced for packets egressing on those ports.

On platforms running Arista EOS with 802.1x authentication configured on access/trunk ports and routing enabled on the access VLAN, a malicious supplicant may bypass the requirement to perform 802.1x authentication.

In Arista’s EOS when in 802.1X mode, multi-auth unauthenticated hosts might be allowed access to a switch port if there exists an EAPOL capable device in the fallback VLAN.

On affected platforms running Arista EOS with MACsec configuration, a specially crafted packet can cause the MACsec process to terminate unexpectedly. Continuous receipt of these packets with certain MACsec configurations can cause longer term disruption of dataplane traffic.

On affected platforms running Arista EOS, certain serial console input might result in an unexpected reload of the device.

On affected platforms running Arista EOS, the global common encryption key configuration may be logged in clear text in local or remote accounting logs. Knowledge of both the encryption key and protocol specific encrypted secrets from the device running-config could then be used to obtain protocol specific passwords in cases where symmetric passwords are required between devices.

On affected platforms running Arista EOS with mirroring to multiple destinations configured, an internal system error may trigger a kernel panic and cause system reload.