Arista EOS EUVD-2026-80590

Requires the affected device to be running Arista EOS on one of the specific (unenumerated) affected platforms AND configured with loose-mode Unicast Reverse Path Forwarding (uRPF); default deployments without loose uRPF are not exposed. Limiting factors: uRPF is a non-default, deliberately enabled anti-spoofing feature, so only environments that configured loose uRPF and depend on it for source-address verification are affected; impact is limited to forwarding traffic that should have been dropped (integrity of the filter), with no confidentiality or availability loss. Exploitation depends on the attacker being able to source or inject traffic that traverses the affected device.

This is a genuinely moderate-severity issue, not an inflated high-CVSS finding - the vendor score of 5.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N) is well-calibrated. The impact is confined to integrity of a security control (I:L, with C:N and A:N): a loose Unicast RPF configuration fails to drop traffic it should reject, so anti-spoofing filtering is silently weakened rather than the device being compromised. The scope change (S:C) is defensible because the failure lets spoofable/illegitimate traffic transit the router and reach downstream systems the filter was meant to protect. On the threat-signal side there is no EPSS score, no POC, and no CISA KEV entry provided; Arista discovered the issue internally and explicitly states it is not aware of any malicious use - so this is 'no public exploit identified at time of analysis.' No SSVC decision data was supplied. Net: real-world urgency is LOW-to-MODERATE - it is a defense-in-depth degradation (uRPF is itself typically a supplementary anti-spoofing control), config- and platform-gated, with no confidentiality or availability loss and no evidence of exploitation. Note the 'Authentication Bypass' tag overstates and mischaracterizes the flaw: this is anti-spoofing/route-verification filtering, not authentication.

On an affected Arista EOS platform where operators rely on loose uRPF to drop packets with spoofed or unroutable source addresses, an attacker sends traffic with source addresses that should fail the reverse-path check; because of this bug the device forwards it anyway. The attacker can thereby bypass the intended anti-spoofing drop to inject spoofed-source traffic into or through the network (e.g., to evade source-based filtering or facilitate spoofing-based attacks). No public exploit code is identified, and Arista reports no observed malicious use.