EUVD-2026-80319
GHSA-v538-9xwx-vp3j
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as existing gRPC/gNSI user
-
DeliveryOperator initiates Authz policy rotation to revoke access
-
ExploitRace across multiple gNSI transports silently fails rotation
-
ExecutionRevoked user retains gRPC access
-
ImpactPerform unauthorized privileged operations
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a non-default deployment where MULTIPLE gNSI transports are configured on Arista EOS, AND an Authz policy rotation is performed to change/revoke access, AND the attacker is an already-authenticated gRPC/gNSI user (PR:L) who was targeted by that revocation. The bug is a timing race (AC:H) that must coincide with the rotation, and the rotation fails silently, so exploitation is opportunistic rather than attacker-triggered on demand. Limiting factors: single-transport gNSI configurations are unaffected, Bootz is explicitly not affected, no unauthenticated path exists, and the outcome is retention of previously held access rather than escalation to new privileges. |
| Impact | This is a genuinely moderate, not critical, issue and the vendor's CVSS 4.0 score of 6.0 is well-calibrated. The 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N, impact VI:H only) correctly captures a narrow, integrity-focused authorization failure: exploitation requires an existing authenticated principal (PR:L), a hard-to-win timing race (AC:H), and a specific precondition (AT:P - multiple gNSI transports configured plus a concurrent Authz policy rotation). Only integrity is affected (VI:H, with VC:N/VA:N), reflecting that a revoked user retains the access they previously had rather than gaining new capabilities or crashing the device. Exploitation signals reinforce low urgency: E:X (exploit maturity not defined), no EPSS score, no KEV listing, and no public POC - so this is 'no public exploit identified at time of analysis.' Arista explicitly states the flaw was discovered internally and they are not aware of any malicious exploitation. There is no signal conflict: the CVSS vector, the description, and the absence of exploitation intelligence all agree this is a subtle race-condition authorization-persistence bug, not a widely weaponizable network exploit. Priority should be driven by whether an environment actually runs multiple gNSI transports and relies on Authz policy rotation for access revocation. |
| Exploit ScenarioDerived | An operator rotates the gNSI Authz policy to revoke a user's access to gRPC interfaces on an Arista EOS device that has multiple gNSI transports configured. Due to a race condition, the rotation fails silently while appearing successful, so the just-revoked authenticated user continues to reach and act on gRPC interfaces they should no longer have. No public exploit code exists; this is an opportunistic timing condition rather than a deterministic attack. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
An authenticated user with gRPC/gNSI access on Arista EOS can retain permissions that a security policy rotation was supposed to revoke, because a race condition in the gNSI Authz service causes the policy rotation to fail silently when multiple gNSI transports are configured on the device. Only non-default deployments with more than one gNSI transport are affected, Bootz is explicitly out of scope, and the flaw does not grant new privileges - it merely preserves access the attacker already legitimately held, so the outcome is a stale authorization state rather than a privilege escalation. Exploitation requires the revocation and the race to coincide, making it opportunistic rather than attacker-triggerable on demand; Arista discovered the issue internally and reports no malicious exploitation, and no public exploit code has been identified at time of analysis. The vendor's CVSS 4.0 score of 6.0 is well-calibrated for a genuinely moderate, not critical, issue.
RemediationAI
Arista has published Security Advisory 0169 (https://www.arista.com/en/support/advisories-notices/security-advisory/24725-security-advisory-0169), and the primary fix is to move to the EOS release identified there as containing the gNSI Authz race-condition fix; the provided intelligence does not include an exact fixed version string, so the version must be confirmed against that advisory before upgrading. Until the approved image can be deployed, the most effective compensating control is to reduce the deployment to a single gNSI transport, which the vendor identifies as the condition under which the bug does not manifest - the trade-off is loss of transport redundancy and any load distribution the additional transports provided. If multiple transports are operationally required, re-apply or re-commit the authorization policy after each rotation and then independently verify that the intended access actually took effect (for example by re-testing the revoked principal's access rather than trusting the rotation's return status), since silent failure is the core symptom; this adds operational overhead and a verification step to every policy change. Additionally, restrict gRPC/gNSI reachability to trusted management networks and authenticated administrative hosts with ACLs and control-plane policies, which limits who can occupy a session during the race window but does not remove the underlying defect. Patches should be scheduled normally rather than as an emergency, given no known exploitation, no public exploit code, and the non-default multi-transport prerequisite.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
gNSI (gRPC Network Security Interface) is Arista's gRPC-based interface for configuring and querying security policy on EOS, and its Authz service enforces the authorization policy that maps authenticated gRPC sessions to permitted operations. The root cause is a classic CWE-362 concurrent execution using a shared resource with improper synchronization: when more than one gNSI transport is active, a policy rotation (an update that adds or revokes access) can interleave with in-flight Authz state updates so that the rotation is applied to only part of the state and the failure is not surfaced as an error. Because the rotation reports success or simply completes without a raised fault, the authorization tables remain in their pre-rotation state and revoked principals keep working credentials on the gRPC interfaces. The affected component set is captured by the CPE cpe:2.3:a:arista_networks:eos:*:*:*:*:*:*:*:*, i.e. EOS generally, though effective exposure is limited to configurations that both run gNSI and define multiple gNSI transports. The assessed CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N) reflects a network-reachable, high-complexity timing condition, no confidentiality impact, and a high integrity impact on the authorization state; the CVSS 4.0 vector (AT:P, VI:H) agrees that the vulnerable system itself is the attacked component and that the integrity of the policy state is what suffers.
Know when Eos gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Authenticated existing user (PR:L) exploits a hard-to-win race (AC:H) during a specific config/rotation condition; only integrity of access control is affected (I:H), no confidentiality or availability impact.
Primary rating from Vendor (Arista).
CVSS VectorVendor: Arista
Lifecycle Timeline
2DescriptionCVE.org
On affected platforms running Arista EOS, when multiple gRPC Network Security Interface (gNSI) transports are configured, a race condition in the gNSI Authz service may cause a policy rotation to fail silently. An authenticated user whose access was revoked by the new policy may retain unauthorized access to gRPC interfaces. This does not affect Bootz.
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which
GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of
Heap-based buffer overflow in dnsmasq before 2.78 allows remote attackers to cause a denial of service (crash) or execut
Remote code execution in OpenSSH's sshd server (regression of CVE-2006-5051) allows unauthenticated remote attackers to
Tunnel decapsulation logic in Arista EOS fails to verify the encapsulation protocol type, allowing any tunneled packet d
Command injection in Arista EOS-based products lets an authenticated user of the gRPC Network Security Interface (gNSI)
The C+ mode offload emulation in the RTL8139 network card device model in QEMU, as used in Xen 4.5.x and earlier, allows
On affected modular platforms running Arista EOS equipped with both redundant supervisor modules and having the redundan
Heap-based buffer overflow in the PCNET controller in QEMU allows remote attackers to execute arbitrary code by sending
Arista EOS before 4.11.12, 4.12 before 4.12.11, 4.13 before 4.13.14M, 4.14 before 4.14.5FX.5, and 4.15 before 4.15.0FX1.
On affected platforms running Arista EOS with mirroring to multiple destinations configured, an internal system error ma
On affected platforms running Arista EOS with SNMP configured, a specially crafted packet can cause a memory leak in the
Exploit-DB