Arista EOS exposes unauthenticated code execution through P4Runtime and gNPSI
Arista published four security advisories for Arista EOS on September 9, including an unauthenticated RCE rated CVSS 10.0 via P4Runtime (CVE-2026-73453) and two code-execution flaws in the gNPSI telemetry interface. No active exploitation is documented yet, but patching must come before the control plane is ever exposed.
September 9, 2026. Arista Networks publishes four security advisories for Arista EOS, the operating system of its switches and routers. At the center is CVE-2026-73453, an unauthenticated arbitrary code execution through P4Runtime, rated CVSS 10.0. The same day, advisory 0158 documents CVE-2026-73456 and CVE-2026-73457, two code-execution flaws through gNPSI. No active exploitation has been observed yet — which leaves a narrow window to patch before a proof of concept changes the calculus.
The programmable control plane becomes the attack surface
The novelty is less the severity than the location. The Arista EOS flaws do not touch SNMP management or the CLI, but the programmable interfaces that define the modern network: P4Runtime, the runtime that drives the programmable P4 data plane, and gNPSI, the gRPC-based packet-sampling telemetry interface.
CVE-2026-73453 shows the danger. An unauthenticated P4Runtime client can send a malicious request during session initiation and gain complete administrative control of the switch. The score speaks for itself: CVSS 10.0 in v3.1, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, classified CWE-94, code injection. The service listens on port 9559, typically in the management VRF.
CVE-2026-73456 and CVE-2026-73457 follow the same pattern through gNPSI: an unauthenticated client crafts a request to run arbitrary code and seize the device. Three code-execution paths, zero authentication required.
From management to control, the boundary blurs
For twenty years, securing a network device meant locking down the management plane: SSH, SNMP, the console port. The Arista EOS flaws are a reminder that the boundary has moved. P4Runtime and gNPSI are not management in the classic sense — they are programmatic control interfaces, built so an SDN controller or a telemetry collector can talk to the device at data-plane speed.
That evolution moved the attack surface without always moving the reflexes. A team that closes SSH and SNMP to the internet can leave P4Runtime reachable because “the controller has to connect somehow.” The result is the same as an open console: an unauthenticated path to full control, but in a protocol teams audit less because it is newer.
The CVSS 10.0 of CVE-2026-73453 is the symptom of that mismatch: the maximum severity comes from a path that requires no credentials, no interaction, and no privilege — exactly the profile that modern programmable interfaces, built for internal trust, offer by default.
IS-IS, or when the routing protocol itself breaks
The fourth advisory in the wave concerns IS-IS, the link-state routing protocol used in network cores and by carriers. Crafted packets can break an IS-IS adjacency, causing traffic loss, or corrupt the link-state database (LSDB), with the same result.
The difference in nature matters. An RCE through P4Runtime or gNPSI requires reaching a management or telemetry interface. An IS-IS flaw plays out on the routing control plane — the path your neighbors’ packets traverse continuously. Corrupting an LSDB means convincing routers to build false routing tables; breaking an adjacency means degrading connectivity without touching the data plane at all. IS-IS is not a campus protocol: it is the core protocol of large carriers and the data centers that prize its stability and its independence from IP. A flaw that corrupts its link-state database therefore hits the most sensitive infrastructure in the network — the part whose outage cascades to thousands of customers in seconds.
Arista also published advisory 0181 for VeloCloud Edge: insufficient input validation in management and configuration workflows lets a request or configuration value be interpreted as an operating-system command. The SD-WAN surface is therefore added to the control plane.
Why these interfaces are so often exposed
The delicate part is organizational. P4Runtime and gNPSI are enabled in the architectures that do telemetry and programmatic control — precisely the modern deployments that have legitimate reasons to leave these ports open toward a controller or a collector.
Best practice keeps them confined to the management VRF, unrouted toward the internet. But a poorly segmented management VRF, a forgotten ACL, or a compromised controller is enough to turn an interface designed for trust into a front door. The CVSS 10.0 of CVE-2026-73453 assumes the worst configuration — reachable over the network — but that is exactly the configuration many teams underestimate.
The deeper lesson is that the network’s trust boundary has moved inside the data center. When the control plane was SNMP and a console cable, exposure was a configuration mistake. Now it is a product feature — P4Runtime and gNPSI exist to be consumed by controllers — so the security question is no longer “is it exposed?” but “who is allowed to consume it, and from where?” That question is harder to answer, which is why the answer so often defaults to “everyone.”
Arista recommends patching to the fixed EOS versions and checking the real exposure of the affected services. For anyone who knows the gear, the verification is simple:
# Check whether P4Runtime is enabled and which VRF it listens on
switch>show p4-runtime
# Check the state of IS-IS adjacencies
switch>show isis neighborsWhat to do, in order
- Patch EOS to the versions listed in advisories 0158, 0160, 0174, and 0181 — do not wait for public exploitation.
- Confine P4Runtime and gNPSI to the management VRF, unrouted toward the internet, and ACL-restrict access to authorized controllers.
- Audit IS-IS adjacencies and the control plane: an LSDB corruption may not show up in access logs, but in unexplained topology changes.
- Isolate SD-WAN management (VeloCloud Edge) behind the same constraints, since advisory 0181 widens the surface.
Detecting a compromise that leaves no authentication trace
The worst part of these flaws is their silence. An unauthenticated RCE through P4Runtime generates no failed-login to watch — there is no failure. The compromise looks like a legitimate session, and the attacker has the same privileges as the administrator.
Detection therefore has to run on indirect signals: unexplained configuration changes, unusual controller sessions, abnormal memory consumption by the process, or topology changes nobody initiated. For IS-IS, the symptom is clearer: an adjacency that flaps for no reason, or an LSDB that changes while no link has moved.
The defense is the same as for any core infrastructure: centralized configuration logging, daily config diffs, and a memory limit (cgroup) on control-plane processes, so excessive allocation becomes a controlled restart rather than a device outage.
The timing matters too. Arista disclosed these flaws with no public proof of concept and no observed exploitation — a courtesy window that historically closes within days to weeks for flaws of this severity on reachable control planes. Teams that patch now are fixing a vulnerability; teams that wait are racing an exploit.
Verdict
Arista EOS is not under active exploitation — for now. That is precisely what makes this wave a maturity test: patching before the proof of concept, rather than after the incident.
If you run Arista EOS switches, patch now and confine P4Runtime (port 9559) and gNPSI to the management VRF. The CVSS 10.0 of CVE-2026-73453 is not an academic curiosity: it describes an unauthenticated path to full control of a core device.
If you manage a core or carrier network, treat the IS-IS advisory with the same priority as the RCEs: a corrupted LSDB or a broken adjacency is a connectivity outage that leaves no authentication trace.