Arista EOS: stale 802.1X ACL entry survives re-auth and is applied to a new supplicant

CVSS 5.6CVE-2026-75944Firmware, BMC & network fabriccurated

Impact

A race during supplicant re-authentication can leave a stale ACL entry in the system. If an administrator later restarts the AclAgent, that stale entry can be applied to new supplicants, so a host lands on the network with access control derived from a different, earlier session. Unlike the sub-second leaks in the same advisory, this state is persistent and the wrong policy stays in force until noticed. On a fabric where 802.1X separates management, storage and tenant segments, that means a port can quietly hold the wrong authorization profile after a routine agent restart. Arista also scores availability impact on the switch itself.

Who can reach it

A low-privileged attacker on an adjacent network segment, as an 802.1X supplicant, with high attack complexity. The unintended enforcement only takes effect after an administrator restarts the AclAgent, so exploitation depends on operator action.

What to do

Follow Arista security advisory 0150 for the fixed EOS releases or hotfix; the record does not name versions, so confirm the target for your train. Until then, treat an AclAgent restart as an event that requires re-verifying applied ACLs on dot1x ports rather than as a routine action. An EOS upgrade is a switch maintenance window; the hotfix path in Arista advisories is generally less disruptive - check the advisory for which applies.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-75944 https://www.arista.com/en/support/advisories-notices/security-advisory/24706-security-advisory-0150

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.