Arista EOS: ingress ACLs on shared SVIs stop enforcing after a secondary switch card event

CVSS 6.3CVE-2026-73451Firmware, BMC & network fabriccurated

Impact

On dual switch card chassis, restarting the secondary switch card forwarding agent or inserting a secondary card can silently stop ingress security ACLs on shared-mode SVIs from being applied. Packets that should be denied are permitted. The failure is silent: the configuration still shows the ACL, so an operator auditing config sees a tenant boundary that the hardware is no longer enforcing. On a multi-tenant GPU fleet this is the difference between a segmented management or storage VLAN and an open one. Arista found this internally and reports no known exploitation.

Who can reach it

No attacker action triggers the condition - it follows an operational event on the switch (card insertion or forwarding agent restart). Exploitation afterwards only requires sending traffic that the ACL was supposed to deny.

What to do

Upgrade to the fixed EOS release or hotfix from Arista security advisory 0151; the record does not state a version. Operationally, after any secondary switch card insertion or forwarding agent restart on an affected chassis, verify ACL counters on shared SVIs rather than trusting the running configuration.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73451 https://www.arista.com/en/support/advisories-notices/security-advisory/24707-security-advisory-0151

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.