Arista EOS: gNSI authz policy rotation can fail silently, leaving revoked gRPC access in place

CVSS 6.0CVE-2026-73463Firmware, BMC & network fabriccurated

Impact

On EOS switches with more than one gNSI transport configured, a race in the gNSI Authz service can make an authorization policy rotation fail without reporting an error. A user whose access the new policy was meant to revoke keeps working access to the switch's gRPC interfaces. For a datacenter spine/leaf or a fabric managed through gNMI/gNSI automation, that means an offboarded operator or a decommissioned automation credential still holds the ability to read or change switch configuration, and the management system believes otherwise. Integrity impact only per the CVSS vector; Bootz is not affected. Found internally by Arista, with no known exploitation reported.

Who can reach it

An authenticated gRPC/gNSI user whose privileges were supposed to be removed by a policy rotation. Requires reachability to the switch management gRPC endpoint - normally the management VLAN - and the switch must have multiple gNSI transports configured.

What to do

Apply the fixed EOS release or hotfix listed in Arista security advisory 0169. EOS patch rollout means a switch reload or (where an SSU/hotfix applies) a service restart, scheduled per device - on a single-homed fabric leg that is a maintenance window for the GPU nodes behind it. As an immediate check, re-verify effective authz policy after any rotation rather than trusting the rotation's result, and reduce to a single gNSI transport where the configuration allows it.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73463 https://www.arista.com/en/support/advisories-notices/security-advisory/24725-security-advisory-0169

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.