Arista EOS CVE-2026-73439

Exploitation requires a very specific stack of conditions all present simultaneously on Arista EOS: (1) OpenConfig must be configured, (2) a gNMI server must be running on the system, (3) gNSI Pathz must be configured with an active Pathz policy present, and (4) that policy must contain BOTH a group rule AND a user rule referencing the SAME path. Only when this rule collision exists does gNMI mis-enforce the policy. Limiting factors: the attacker must already be an authenticated gNMI user (PR:L), the deployment must use the OpenConfig/gNMI management plane with gNSI Pathz authorization (a non-default, advanced management configuration), and there is no impact on a default EOS device that does not run gNMI/Pathz. These conditions make real-world exposure far narrower than the network-reachable CVSS vector alone suggests.

This is a real but tightly-scoped authorization flaw whose headline CVSS 4.0 score of 7.7 overstates day-to-day risk. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H) already signals two meaningful brakes: PR:L means the attacker must be an authenticated gNMI/gNSI user, and AT:P (attack requirements present) reflects that exploitation only becomes possible in a specific policy state - namely a Pathz policy that contains BOTH a group rule and a user rule for the same path. No EPSS score, KEV listing, or public POC was provided in the input, so exploitation status is 'no public exploit identified at time of analysis'; there is no evidence of active or automated exploitation. The impact where it applies is genuine (unauthorized read/write of gNMI paths the policy was meant to restrict), but the VA:H (availability) claim is weak - the description only mentions unauthorized read/write, not service disruption. Net: prioritize patching where OpenConfig/gNMI with gNSI Pathz is actually deployed and enforcing least-privilege, but this is not a broadly-sprayable, unauthenticated internet threat. Note the AV:N vector is defensible only because gNMI is a network service; it still requires valid credentials plus the specific colliding-rule policy condition, so treat AC as effectively high in practice.

An authenticated gNMI user who is intentionally restricted by a gNSI Pathz policy connects to the Arista EOS gNMI server and requests a path that the policy is supposed to deny. Because a group rule and a user rule both cover that same path, EOS mis-resolves the enforcement precedence, and the user is granted read or write access they should not have - for example reading sensitive config or modifying a restricted OpenConfig leaf. No public exploit code is available; exploitation requires only valid credentials plus the specific overlapping-rule policy state.