Arista EOS: gNSI Authz Rotate can activate the in-flight authorization policy

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

Impact

During a gNSI Authz Rotate RPC, a policy uploaded in the ongoing stream can become active even though it was not meant to be committed. The result is a switch enforcing an authorization policy the operator did not finalize - the command-authorization rules on a fabric device silently differ from what the management system believes it pushed. For an operator automating switch config across a GPU fabric with gNMI/gNSI, this breaks the assumption that a failed or abandoned rotate leaves the old policy in place. Bootz is not affected. Found internally by Arista, with no known exploitation.

Who can reach it

Requires high privilege on the management path (CVSS PR:H) - someone already authorized to drive gNSI RPCs against the switch, i.e. the automation system or an operator on the management network.

What to do

Apply the fix per Arista advisory 0167. Until then, verify the active Authz policy on each switch after any rotate operation rather than trusting the RPC's outcome, and treat gNSI access as the privileged path it is.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73445 https://www.arista.com/en/support/advisories-notices/security-advisory/24723-security-advisory-0167

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.