Arista EOS: gNMI fails to enforce Pathz policy when a group rule and a user rule cover the same path

CVSS 7.7CVE-2026-73439Firmware, BMC & network fabriccurated

Impact

When OpenConfig gNMI is running and a gNSI Pathz authorization policy contains both a group rule and a user rule for the same path, EOS may resolve them incorrectly and let an authenticated user read or write gNMI paths the policy was written to deny. The practical effect is that the delegation model an operator built for a shared fabric does not hold: a restricted automation account or a limited operator can read configuration and state it should not see, or push changes to it. On a GPU cluster the affected switches carry storage and east-west traffic for multiple tenants, so unauthorized write access to interface, ACL or routing paths reaches beyond the account's own scope.

Who can reach it

An authenticated gNMI client on the management network whose access is supposed to be constrained by a Pathz policy. Exploitation requires the specific policy shape - a group rule and a user rule for the same path - so it depends on how the policy was authored.

What to do

Follow Arista security advisory 0164: upgrade EOS to the fixed release for your platform. As an interim step, audit Pathz policies for paths covered by both a group rule and a user rule and rewrite them so the intended restriction is expressed by a single rule type, or disable the gNMI server until patched. EOS upgrade requires a switch reload on most platforms; the advisory does not describe a hot patch, so schedule per-switch maintenance with redundant paths available.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73439 https://www.arista.com/en/support/advisories-notices/security-advisory/24720-security-advisory-0164

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.