Arista pubiceerde onlangs security advisory 0158, over twee lekken in de gRPC Network Packet Sampling Interface, gNPSI, van EOS. CVE-2026-73456 haalt een CVSS 3.1 basisscore van 10 en staat een ongeauthenticeerde gNPSI-client toe om via een request willekeurige code uit te voeren op de switch zelf. Onder CVSS 4.0 komt de score uit op 9.2. De classificatie is CWE-94, improper control of generation of code, ofwel de klassieke code injection.
Het tweede lek, CVE-2026-73457, is minder spectaculair maar operationeel net zo vervelend. Bij ingeschakelde trace-logging op de gNPSI-agent word de gebruikersnaam en het wachtwoord van de client in leesbare vorm weggeschreven naar het lokale of remote accounting-logbestand. De classificatie is CWE-532, insertion of sensitive information into log file, met een CVSS 3.1 score van 5.3 en een CVSS 4.0 score van 6.
Wanneer is een EOS-switch daadwerkelijk vatbaar voor CVE-2026-73456
gNPSI staat standaard uit, en zonder actieve transportconfiguratie is er simpelweg geen aanvalsoppervlak. Voor CVE-2026-73456 moet één van twee specifieke condities gelden.
- Ofwel draait een gNPSI-transport met TLS-serververificatie waarbij metadata-authenticatie is ingeschakeld naast x509-spiffe en x509-common-name in de authentication username priority.
- Ofwel draait de transport met mutual TLS waarbij x509-common-name als geldige authenticatiemethode is toegestaan.
In beide gevallen ontstaat ruimte voor een client om zich via metadata of een common-name claim te presenteren zonder dat de identiteit cryptografisch wordt afgedwongen op basis van SPIFFE.
Voor CVE-2026-73457 ligt de trigger elders. De trace-faciliteit EosRpcAuth moet expliciet zijn ingeschakeld op de Gnpsi-agent, terwijl trace-logging in EOS standaard uitstaat. We zien in de praktijk soms dat zo’n tracefaciliteit na een troubleshootingsessie gewoon aan blijft staan, soms weken- of maandenlang, en dat is precies het scenario waarin credentials in een accounting-log belanden.
De getroffen releases beslaat drie groepen: 4.36.1F en ouder in de 4.36-tak, 4.35.5M en ouder in de 4.35-tak, en releases tussen 4.34.2F en 4.34.7M in de 4.34-tak. Qua hardware raakt het de 700-serie, de 720D en 720XP/722XPM, de 750X, vrijwel de volledige 7000-reeks van 7010TX tot 7800R3/R4, de 7130 wanneer die EOS draait in plaats van MOS, en de AWE 5000 en AWE 7200R. Ook de virtuele varianten zijn kwetsbaar: CloudEOS, cEOS-lab, vEOS-lab en CloudVision eXchange, virtueel of fysiek.
Een hotfix bestaat niet
Arista’s mitigatieadvies is ondubbelzinnig: schakel gNPSI in met mutual TLS en configureer de authentication username priority zo dat alleen x509-spiffe is toegestaan, dus zonder metadata en zonder x509-common-name als terugvaloptie. SPIFFE-gebaseerde identiteit is van de drie methoden de enige die niet via een aanpasbaar veld of een certificate common-name is te vervalsen. Voor CVE-2026-73457 volstaat het uitschakelen van de EosRpcAuth trace, wat met een enkele trace-reset op de Gnpsi-agent te doen is. Zijn er al credentials gelogd, dan schrijft Arista voor om de betreffende Gnpsi-logbestanden te truncaten, ook de gearchiveerde en gecomprimeerde varianten op te ruimen, en de gecompromitteerde wachtwoorden te roteren.
Aangezien gNPSI standaard is uitgeschakeld, zijn systemen met de fabrieksinstellingen niet kwetsbaar. Maar check eea toch even want de enige echte oplossing is dus upgraden naar 4.36.2F of hoger, 4.35.6M of hoger, of 4.34.8M of hoger, afhankelijk dus van de gebruikte versie. Aan de slag dus.
Kijk voor meer info op https://www.arista.com/en/support/advisories-notices/security-advisory/24714-security-advisory-0158
