Two 10.0s in Arista EOS and no hotfix: your config decides, not your version

A 10.0 out of 10 is the highest score a vulnerability can get. There is nothing above it. Arista published two in September, both in EOS, both on data centre switches, and both with the same sentence in the resolution section: "There is no hotfix for this issue". They went by with strikingly little noise for that score.

The reason for that silence is the part that interests us, and it is not that nobody cares. It is that nobody can say how many devices are affected. Both features ship switched off, so exposure cannot be derived from the installed version: it depends on whether somebody, one day, wrote a line into the running config. No headline summarises that and no scanner answers it. It is answered by whoever can type two commands on your switches.

Both advisories, briefly

The first is advisory 0174, CVE-2026-73453, published on 9 September 2026 and revised to 1.1 on the 22nd. CVSS 3.1 base 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H; under CVSS 4.0 it drops to 9.5. Classified as CWE-94, code injection. The description does not hedge: an unauthenticated P4Runtime client can, by crafting a packet during session initiation, execute arbitrary code on the switch. Arista adds that it found the issue internally and is not aware of malicious use in customer networks.

The second is advisory 0158, carrying two identifiers. CVE-2026-73456: on a device with gNPSI enabled, "an unauthenticated gNPSI client can craft a malicious request to allow arbitrary code execution", with full administrative control of the switch. Also CVSS 3.1 10.0, also CWE-94; under CVSS 4.0, 9.2. And attached to it, CVE-2026-73457, scored 5.3: gNPSI client credentials can end up logged in clear text in local or remote accounting logs, visible to authenticated users. CWE-532. We will come back to this one; it is the one that takes longest to hurt.

The affected versions are not the same in both advisories, and the difference matters. 0174 reaches a long way back: 4.36.1F and earlier, 4.35.5M and earlier, 4.34.7M and earlier, every release in 4.33.x, 4.32.x, 4.31.x and 4.30.x, and from 4.29.2F onwards in the 4.29 train. 0158 is far narrower: only 4.36.1F and earlier, 4.35.5M and earlier, and the 4.34.2F–4.34.7M stretch. Which is to say: if you are on a 4.30 with gNPSI enabled, that ten is not yours. The 0174 platform list is long and fairly recognisable — 710, 720, 750, 7010TX, 7020R, 7050X3/X4, 7060X, 7130 running EOS, 7170, 7260X3, 7280R, 7300X3, 7500R, 7800R3/R4, CloudEOS, cEOS-lab, vEOS-lab, CloudVision eXchange, among others — and it is worth noting what is not there: Wi-Fi access points, CloudVision CUE, Portal and AGNI, and the 7130 running MOS (note: the 7130 running EOS is affected). The operationally good news, if you can call it that: the fixed releases are the same for both advisories, 4.36.2F, 4.35.6M and 4.34.8M onwards. One jump closes both.

Why it is 10.0 and not 9.8: the letter of the vector nobody reads

The usual profile for "unauthenticated remote execution" is 9.8. This one is 10.0, and the difference sits in a single letter of the vector: S:C, Scope: Changed. It means the impact does not stay inside the vulnerable component. In CVSS, scope changes when a flaw in one piece lets an attacker affect resources managed by a different security authority.

Translated to your floor: the switch is not the target, it is the crossing. A device switching traffic for several VLANs, several tenants or several sites holds nothing worth stealing, but it sees and touches everything that passes through. That letter is why the score hits the ceiling, and it is also why the right conversation is not "we must patch a switch" but "we must decide what crosses that switch and who is allowed to talk to it". This is not new; we wrote about it a few weeks ago over something else: . The pattern repeats every time the management plane and the data plane share a road.

Neither interface is exotic: they are the ones you switched on in order to see

Here is the uncomfortable part. P4Runtime is the interface through which a controller programs data-plane behaviour. gNPSI, the gRPC Network Packet Sampling Interface, is how the switch hands packet samples to a collector. Neither is a lab curiosity: one is programmability, the other is telemetry. Both exist so that an external system can see and steer the network.

Both ship switched off. Advisory 0174 says so plainly — "P4Runtime is disabled by default in Arista EOS" — and the same holds for gNPSI. From which follows a conclusion that is not comfortable to write: the switch exposed to these two 10.0s is not the old forgotten one, it is the one somebody modernised. The one enrolled in a telemetry pilot, the one wired to a collector so there would finally be traffic samples, the one that stopped being a blind box. Whoever did that work did it well and for good reasons. And it is the device to look at today.

"There is no hotfix" changes the calendar, not just the task

Arista normally lets you apply patches live through extensions. Not for these two: "There is no hotfix for this issue". That turns the response into an EOS version change, and an EOS version change on a production switch is not a ticket: it is a window, a boot order, an adjacency check and a rollback plan. If the device sits in an MLAG pair, it is two windows and a verification in between.

That is why the advisory offers a middle path worth reading in full, because it is not "turn it off" but "put authentication on it". The mitigation Arista publishes for P4Runtime is to bring the service up in mTLS mode and require authorisation by client certificate. This is what an already-mitigated configuration looks like, exactly as the advisory prints it:

p4-runtime
   no shutdown
   !
   transport grpc foo
      ssl profile campus
      authentication username priority x509-spiffe

management security
   ssl profile campus
      certificate server.crt key server.key
      trust certificate ca.crt

management api gnsi
   service authz

Read it slowly and you will see what it really says: the default state of that interface is no certificate and no authorisation. This is not an Arista oversight; it is the inheritance of a whole family of gRPC management interfaces designed on the assumption that they lived inside a trusted management network. That assumption was reasonable when the collector sat in the same cabinet. It stops being reasonable the moment the collector is a virtual machine on another subnet, or a SaaS.

The 5.3 is the one that will hurt you a year from now

CVE-2026-73457 scores 5.3 and will therefore fall out of almost every report. It says gNPSI client credentials may be written in clear text into accounting logs, local or remote. Note the "remote". Those logs are exactly the ones you set up for traceability: they leave the device, land on a TACACS+ server or a syslog collector, are retained by policy for months and get exported whenever somebody asks for them.

The score measures the damage to the switch. The real consequence is at the other end of the cable: a system whose whole purpose is to retain and share has started holding secrets without anyone deciding so. And upgrading EOS does not clean what is already written. If gNPSI was enabled in your case, the job does not end with the version jump: those credentials have to be rotated and you have to find out how far copies of those logs travelled. It is boring work, and it is what separates a closed incident from one that looks closed.

The twenty-second check

Both advisories ship their own verification commands, and that is this post's deliverable. There is nothing to interpret: run them and read them.

switch> show p4-runtime
switch> show management api gnpsi
switch> show trace Gnpsi | grep Auth

The reading criterion for the first comes from the advisory itself: if the output says Enabled: no, there is no exposure to that flaw. Full stop. The second tells you whether gNPSI is up, and the third — also published by Arista — is the one that lets you see the authentication of clients that reached that interface. Twenty seconds per device, less if your inventory is automated. And if a third party runs the network, you do not need to run it yourself: you need somebody to send you the output of those commands on every switch, in writing, with a date. "We are covered" is not an answer; the command output is.

The three fields missing from almost every network inventory

The part that outlives this particular advisory is this one, and it applies to any vendor. A normal network inventory records model, serial number, firmware version, management addresses and, if you are lucky, the date of the last update. With that you can answer "which version do I have?", which is a question that does not help today. Three fields are missing:

• Which management and telemetry services are switched on on that device, by name. Not "it has management": gNMI, gNPSI, gNOI, P4Runtime, NETCONF, REST, SNMP, whichever. That list decides which advisories you have to act on and which you can skip.
• Which VRF they listen in. A service in the management VRF, behind its ACL, is a bounded risk; the same service listening in the default VRF is an entirely different thing. Same CVE, not the same problem.
• Whether they demand a client certificate, or settle for you simply arriving. That is the one that really separates an advisory that costs you an afternoon from one that costs you a quarter, and it is the one that is never written down anywhere.

We keep our network documented in NetBox as the source of truth, and these three fields do not come as standard anywhere: you have to decide to add them and decide who maintains them. It is exactly the work we described in 43 CVEs in your array's fibre switch, and none is critical, where the problem was not the severity of anything but that the device had no owner. An inventory that does not know what is switched on is not an inventory: it is an old shopping list.

Who this does not touch, and why saying so matters

If both commands say no, this is not about you. No window, no branch jump, no meeting. And that deserves saying as plainly as the bad news, because the cost of not checking cuts both ways: one is leaving a ten open; the other, less often discussed, is opening a late-night window that was never needed, spending the quarter's interruption budget and arriving without it at the advisory that did matter. A conditional severity misread costs money in both directions.

And a clarification worth making: none of this is an argument against Arista. We are not resellers of theirs or of anyone, and a month later, on 7 October, another vendor published half a dozen flaws in its own switching operating system, also found in internal review. Finding and publishing your own bugs is what a serious vendor does; the alternative is somebody else finding them. What is fair to criticise, and it runs across the whole sector, is that a modern management interface still comes up without authentication because "it is on the management network". That management network, in more than one place we have seen, is a VLAN with good intentions.

What we would do this week

First, both commands on every switch, with the output saved and dated. Second, for the ones that come back enabled: decide between switching the feature off, if the telemetry pilot died eighteen months ago or bringing it up in mTLS with certificate authorisation, which is what the vendor signs off. Third, schedule the jump to 4.36.2F, 4.35.6M or 4.34.8M with the calm of someone who knows how many devices are affected, rather than the hurry of someone who does not. And fourth, open the three fields in the inventory, because the advisory arriving in two months will ask the same question again.

Sources (checked 15 Oct 2026): CVE-2026-73453, the 10.0 score with its vector and the 9.5 under CVSS 4.0, the CWE-94 class, the publication (9 Sep 2026) and revision 1.1 (22 Sep 2026) dates, the lists of affected and unaffected versions and platforms, the sentence "P4Runtime is disabled by default in Arista EOS", the show p4-runtime command with its "Enabled: no" criterion, the mTLS mitigation configuration snippet, the fixed releases and the sentence "There is no hotfix for this issue" all come from Arista Networks advisory 0174. CVE-2026-73456 and CVE-2026-73457, their scores (10.0 and 5.3 under CVSS 3.1; 9.2 and 6.0 under CVSS 4.0), the CWE-94 and CWE-532 classes, the clear-text credential logging in local or remote accounting logs, the show management api gnpsi command, gNPSI's default-off state and its fixed releases, come from Arista Networks advisory 0158. The definition of Scope: Changed is from the FIRST CVSS 3.1 specification. The half dozen flaws published the same month by another vendor come from advisory cisco-sa-hardening-nxosw1-cWzSbtR, dated 7 October 2026. What is ours, and we bound it: reading the S:C letter against a switch that traffic crosses, the observation that the exposed device is the one somebody modernised, the two-costs argument for checking, and the three inventory fields.