Arista EOS: loose uRPF fails to drop some traffic it should verify

CVSS 6.9CVE-2026-73469Firmware, BMC & network fabriccurated

Impact

On specific platforms, traffic that a loose Unicast Reverse Path Forwarding configuration should drop is instead forwarded. The anti-spoofing control an operator configured is partially ineffective, so spoofed-source packets can cross a boundary the design assumed was closed. In a multi-tenant GPU cloud where uRPF is one of the controls keeping one tenant's traffic from impersonating another's addresses, the gap is an isolation gap rather than an outage. Arista found this internally and reports no known exploitation. The record does not say which traffic or which platforms, so confirm against the advisory for your hardware.

Who can reach it

Unauthenticated and network-reachable (AV:N) - any source able to send traffic through an interface relying on loose uRPF. No switch credentials needed.

What to do

Check Arista advisory 0176 for the affected platforms and fixed EOS releases before assuming your hardware is involved. Where uRPF is the only spoofing control on a boundary, add explicit ACL-based source filtering, which holds regardless of the EOS version, and schedule the upgrade normally rather than as an emergency.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73469 https://www.arista.com/en/support/advisories-notices/security-advisory/24732-security-advisory-0176

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.