CVE-2026-73456: Arista EOS gNPSI RCE
TL;DR - CVE-2026-73456 is a CVSS 10.0 unauthenticated remote-code-execution vulnerability in Arista EOS when gNPSI is enabled. - Affected EOS version ranges and the fixed release are not verified in the available sources. - No CISA KEV listing or verified public PoC is known. Restrict gNPSI exposure and consult Arista Security Advisory 0158 immediately.
Vulnerability at a Glance
| Field | Details |
|---|---|
| CVE ID | CVE-2026-73456 |
| CVSS score | 10.0, critical |
| CVSS vector | Not included in the available NVD record |
| Attack vector | Network |
| Authentication required | No authentication required for the malicious gNPSI request |
| Affected product | Arista EOS platforms with gRPC Network Packet Sampling Interface (gNPSI) enabled |
| Patch available | No fixed version verified from the available sources |
| CISA KEV status | Not listed as of 2026-09-16 |
CVE-2026-73456 affects a configuration-dependent service rather than every Arista EOS deployment by default. The available description states that an unauthenticated gNPSI client can send a crafted request that may enable arbitrary code execution on an affected switch.
The absence of a verified fixed release in the retrieved source material is a data limitation, not evidence that no vendor remediation exists. Arista Security Advisory 0158 is the authoritative source for affected EOS releases, fixed versions, and any supported configuration workaround.
What Is This Vulnerability?
The reported flaw is in the handling of a malicious request received through the gNPSI service on affected Arista EOS platforms. An attacker who can reach that service does not need valid credentials, according to the available vulnerability description. Successful exploitation may allow arbitrary code execution and could provide full administrative control of the compromised switch.
The precise technical root cause has not been disclosed in the available NVD record or independently verified from the Arista advisory. It is therefore not appropriate to classify the issue as a confirmed buffer overflow, command injection, unsafe deserialization flaw, or authentication bypass. Defenders should treat the vulnerability as a remotely reachable code-execution condition while avoiding assumptions about the underlying implementation defect.
Technical Notes
The known execution path is:
Unauthenticated client
|
v
Reachable gNPSI service
|
v
Crafted malicious request
|
v
Potential arbitrary code execution
|
v
Potential full administrative control of the EOS switch
Because the public technical detail does not identify a request type, protocol field, payload structure, or vulnerable function, a reliable exploit signature cannot be derived from the available information. Network controls and service exposure reduction are consequently important interim defenses.
Who Is Affected?
The affected product family is Arista EOS. The relevant condition is that the switch is running an affected EOS release and has the gRPC Network Packet Sampling Interface, or gNPSI, enabled. A switch that does not expose or enable gNPSI may not be in the vulnerable configuration, but administrators should verify the state rather than infer it from product family alone.
Specific vulnerable EOS version ranges were not available in the retrieved NVD record, and the Arista advisory could not be programmatically read because the advisory endpoint returned an anti-automation challenge. The currently verified scope is therefore:
| Product | Feature condition | Vulnerable version range | Fixed version |
|---|---|---|---|
| Arista EOS | gNPSI enabled and reachable by an attacker | Not disclosed in the available sources | Not verified in the available sources |
Organizations should inventory Arista switches, record EOS versions, and determine whether gNPSI is enabled or reachable from user, transit, internet-facing, or shared management networks. Prioritize devices with externally reachable gNPSI services and switches that carry sensitive east-west or data-center traffic.
CVSS Score Breakdown
CVE-2026-73456 is reported with a CVSS base score of 10.0, which is the highest critical severity rating. The description supports a network attack vector and no required authentication: an attacker can reportedly send a malicious request to the gNPSI service without first logging in.
The available NVD result does not include a CVSS vector string. As a result, the individual metric values for attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability cannot be independently confirmed. The reported impact is nevertheless severe because arbitrary code execution on a network switch can affect device configuration, forwarding behavior, credentials, telemetry, and traffic visibility.
| CVSS component | Available assessment |
|---|---|
| Attack vector | Network |
| Attack complexity | Not disclosed |
| Privileges required | None or unauthenticated access |
| User interaction | Not disclosed |
| Scope | Not disclosed |
| Confidentiality impact | Potentially high due to administrative control |
| Integrity impact | Potentially high due to switch control |
| Availability impact | Potentially high due to device compromise or disruption |
Treat the 10.0 rating as a prioritization signal, not as a substitute for exposure analysis. A gNPSI service restricted to a dedicated, trusted telemetry network presents a different practical exposure than the same service reachable from the internet, a user VLAN, or an untrusted tenant network.
Exploitation Status
CVE-2026-73456 is not listed in the CISA Known Exploited Vulnerabilities catalog as of 2026-09-16. Therefore, exploitation in the wild is not confirmed by CISA KEV. This status does not prove that no exploitation has occurred; it only means there is no verified CISA KEV entry in the supplied research data.
No verified public proof-of-concept repository, exploit code, or technical exploit write-up was identified in the available search results. The PoC status should therefore be recorded as not known or not verified, rather than definitively impossible. Because the vulnerability is unauthenticated and rated CVSS 10.0, defenders should not wait for a public exploit before reducing exposure.
Technical Notes
Use external telemetry to check whether gNPSI is reachable from networks that should not access telemetry or management services. A generic network-monitoring query can identify unexpected connections to the documented gNPSI listener once the organization has confirmed its port and transport configuration:
(event.category:network OR event.dataset:firewall)
and destination.ip: <EOS_SWITCH_IP>
and source.network: <UNTRUSTED_OR_USER_NETWORK>
and destination.port: <CONFIRMED_GNPSI_PORT>
The exact port, protocol, and EOS log message for this service were not provided in the available sources. Do not treat a guessed port or generic malformed-request string as a validated signature. Correlate unexpected gNPSI connections with EOS configuration changes, management logins, process or service restarts, and changes to AAA, routing, ACL, telemetry, or interface configuration.
How to Detect It
Start with asset and configuration discovery. Build an inventory containing each Arista switch hostname, management address, EOS release, gNPSI status, listener address, and the networks permitted to connect. Compare that inventory with firewall, ACL, flow, and NetFlow records to identify services reachable beyond the intended telemetry or management segment.
Detection should focus on anomalous clients and behavior because a vendor-confirmed exploit signature is not available. Look for new source IP addresses connecting to gNPSI, connections from internet or end-user ranges, bursts of malformed or failed requests, service restarts, unexpected configuration writes, and administrative activity shortly after an unusual gNPSI connection.
Organizations using broader endpoint visibility can also review their endpoint detection and response capabilities when investigating activity on management hosts that communicate with affected switches.
Technical Notes
A practical SIEM correlation pattern is:
firewall_allow
| where destination_device_type == "Arista EOS"
| where service == "gNPSI" or destination_port in (<CONFIRMED_GNPSI_PORTS>)
| where source_zone not in ("telemetry", "trusted-management")
| stats count(), min(_time), max(_time),
values(source.ip), values(destination.ip)
by destination.device
On the switch, review EOS system, AAA, configuration, and management logs around suspicious network events. Useful indicators include unexpected login or privilege changes, configuration commits from unfamiliar source addresses, ACL or management-plane changes, and unexplained process or service restarts. The exact log pattern is release-dependent and was not supplied in the available advisory data, so administrators should preserve raw logs and validate detections against a known-good switch running the same EOS release.
Mitigation and Patching
The specific affected EOS versions and fixed release are not verified from the available sources. Administrators must consult Arista Security Advisory 0158 through the Arista support channel and use the exact upgrade target listed there. Do not select a version based only on the CVE publication date or assume that the newest train is automatically the vendor-recommended remediation.
Until the fixed release is confirmed and deployed, restrict gNPSI access to the smallest possible set of trusted telemetry or management addresses. If the feature is not required, disable it using the vendor-supported EOS procedure after confirming operational impact. Apply change control, preserve the current configuration, verify redundancy and rollback procedures, and test telemetry collection after the upgrade or configuration change.
Network teams should also review privileged access controls and service accounts associated with switch administration. A password manager such as Try 1Password → can help teams store unique administrative credentials and recovery information securely, although credential management does not replace patching or gNPSI network restrictions.
Technical Notes
Because an exact fixed version and EOS-specific syntax were not verified, use a controlled workflow rather than an invented command:
1. Obtain Arista Security Advisory 0158 from the Arista support portal.
2. Confirm the switch's EOS release and gNPSI configuration.
3. Select the advisory's specified fixed EOS image.
4. Upload and validate the image using the organization's approved Arista EOS process.
5. Schedule a reload or failover according to the switch platform and redundancy design.
6. Verify the EOS version, gNPSI state, telemetry operation, and management-plane ACLs.
For immediate exposure reduction, implement a management-plane or infrastructure ACL that permits the confirmed gNPSI listener only from approved telemetry collectors. The following is a policy pattern, not a ready-to-deploy EOS command, because the exact service syntax and port were not provided:
permit <TRUSTED_TELEMETRY_COLLECTOR_SUBNETS> -> <SWITCHES> service <CONFIRMED_GNPSI_SERVICE>
deny any -> <SWITCHES> service <CONFIRMED_GNPSI_SERVICE>
log denied gNPSI connection attempts
If gNPSI is unnecessary, disable it through the supported Arista EOS configuration method documented in the advisory. Validate that disabling it does not interrupt required packet-sampling or observability workflows.
Incident Response Considerations
If an affected switch was reachable from an untrusted network or shows signs of suspicious activity, treat it as a potential security incident. Preserve configuration snapshots, system and AAA logs, flow records, management-plane ACL logs, and relevant network captures before making changes where operationally feasible.
Investigate for:
- Unexpected clients connecting to the gNPSI service
- Configuration changes from unfamiliar source addresses
- New or modified administrative accounts
- Changes to AAA, routing, ACL, telemetry, or interface settings
- Unexplained service or process restarts
- Traffic forwarding, mirroring, or visibility anomalies
- Connections from the switch to unusual external destinations
If compromise is suspected, isolate the switch or restrict management access according to the organization’s incident-response plan. Coordinate with Arista support to determine whether a forensic image, diagnostic bundle, or hardware replacement is required. Rotate credentials that may have been exposed and review adjacent network devices for related unauthorized changes.
References
The primary vendor reference is Arista Security Advisory 0158. It should be used to confirm the affected EOS release ranges, fixed release, supported workaround, and any platform-specific instructions. The advisory was not fully retrievable in the available research session because the endpoint returned an anti-automation challenge.
The NVD record supplies the CVE description and reported CVSS 10.0 severity but does not provide the CVSS vector, precise root-cause classification, affected version ranges, or fixed release in the retrieved data. CISA KEV is also relevant for exploitation tracking, although the CVE was not listed there as of the stated review date.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.