Dos 10.0 en Arista EOS y ningún hotfix: lo decide tu configuración, no tu versión

Un 10.0 sobre 10 es la nota máxima que puede sacar una vulnerabilidad. No hay nada por encima. Arista publicó dos en septiembre, los dos en EOS, los dos en switches de centro de datos, y los dos con la misma frase en el apartado de resolución: «There is no hotfix for this issue». Pasaron con un ruido llamativamente bajo para esa puntuación.

El motivo de ese silencio es la parte que nos interesa, y no es que a nadie le importe. Es que nadie puede decir a cuántos equipos afectan. Las dos funciones implicadas vienen apagadas de fábrica, así que la exposición no se deduce de la versión instalada: se deduce de si alguien, algún día, escribió una línea en la configuración. Y eso no hay titular que lo resuma ni escáner que lo conteste. Lo contesta quien pueda teclear dos órdenes en tus switches.

Los dos avisos, en corto

El primero es el aviso 0174, CVE-2026-73453, publicado el 9 de septiembre de 2026 y revisado a 1.1 el 22. CVSS 3.1 base 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H; en CVSS 4.0 baja a 9,5. Clasificado como CWE-94, inyección de código. La descripción no se anda con rodeos: un cliente no autenticado de P4Runtime puede, manipulando un paquete durante el arranque de la sesión, ejecutar código arbitrario en el switch. Arista añade que lo encontró internamente y que no tiene constancia de uso malicioso en redes de clientes.

El segundo es el aviso 0158, con dos identificadores. CVE-2026-73456: en un equipo con gNPSI activado, «an unauthenticated gNPSI client can craft a malicious request to allow arbitrary code execution», con control administrativo completo del switch. También CVSS 3.1 10.0, también CWE-94; en CVSS 4.0, 9,2. Y pegado a él, CVE-2026-73457, de 5,3: las credenciales del cliente gNPSI pueden acabar registradas en texto claro en los logs de accounting, locales o remotos, y visibles para usuarios autenticados. CWE-532. Volveremos a este, que es el que más tarda en doler.

Las versiones afectadas no son las mismas en los dos avisos, y la diferencia importa. El 0174 llega lejos: 4.36.1F y anteriores, 4.35.5M y anteriores, 4.34.7M y anteriores, todas las de 4.33.x, 4.32.x, 4.31.x y 4.30.x, y desde la 4.29.2F en la rama 4.29. El 0158 es mucho más estrecho: solo 4.36.1F y anteriores, 4.35.5M y anteriores y el tramo 4.34.2F–4.34.7M. Es decir, si estás en una 4.30 con gNPSI encendido, ese diez no es tuyo. La lista de plataformas del 0174 es larga y bastante reconocible —710, 720, 750, 7010TX, 7020R, 7050X3/X4, 7060X, 7130 con EOS, 7170, 7260X3, 7280R, 7300X3, 7500R, 7800R3/R4, CloudEOS, cEOS-lab, vEOS-lab, CloudVision eXchange, entre otras— y conviene fijarse también en lo que no está: puntos de acceso wifi, CloudVision CUE, Portal y AGNI, y los 7130 con MOS (ojo: los 7130 con EOS sí están). La buena noticia operativa, si se le puede llamar así: las versiones corregidas son las mismas para los dos avisos, 4.36.2F, 4.35.6M y 4.34.8M en adelante. Un salto cierra los dos.

Por qué es 10.0 y no 9,8: la letra que casi nadie mira del vector

El perfil habitual de un «ejecución remota sin autenticar» es 9,8. Este es 10.0, y la diferencia está en una sola letra del vector: S:C, Scope: Changed. Significa que el impacto no se queda dentro del componente vulnerable. En CVSS, el alcance cambia cuando el fallo en una pieza permite afectar a recursos que están gestionados por otra autoridad de seguridad distinta.

Traducido a tu planta: el switch no es el objetivo, es el paso. Un equipo que conmuta tráfico de varias VLAN, de varios inquilinos o de varias sedes no guarda nada que valga la pena robar, pero ve y toca todo lo que cruza por él. Esa letra es la razón de que la puntuación se vaya al tope, y es también la razón de que la conversación correcta no sea «hay que parchear un switch» sino «hay que decidir qué pasa por ese switch y quién puede hablar con él». Esto no es nuevo; lo escribimos hace unas semanas a propósito de otra cosa: . El patrón se repite cada vez que el plano de gestión y el plano de datos comparten camino.

Las dos interfaces no son exóticas: son las que encendiste para ver

Aquí está lo incómodo. P4Runtime es la interfaz por la que un controlador programa el comportamiento del plano de datos. gNPSI, gRPC Network Packet Sampling Interface, es por donde el switch entrega muestras de paquetes a un colector. Ninguna de las dos es un capricho de laboratorio: una es programabilidad y la otra es telemetría. Las dos existen para que un sistema externo vea y dirija la red.

Las dos vienen apagadas. El aviso 0174 lo dice con todas las letras —«P4Runtime is disabled by default in Arista EOS»— y lo mismo ocurre con gNPSI. De ahí se sigue una conclusión que no es cómoda de escribir: el switch expuesto a estos dos dieces no es el viejo y olvidado, es el que alguien modernizó. El que se metió en un piloto de telemetría, el que se conectó a un colector para por fin tener muestras de tráfico, el que dejó de ser una caja ciega. Quien hizo ese trabajo lo hizo bien y por buenos motivos. Y es el equipo que hay que mirar hoy.

«No hay hotfix» cambia el calendario, no solo la tarea

Arista permite normalmente aplicar parches en caliente mediante extensiones. Para estos dos no: «There is no hotfix for this issue». Eso convierte la respuesta en un cambio de versión de EOS, y un cambio de versión de EOS en un switch de producción no es un ticket: es una ventana, un orden de arranque, una comprobación de adyacencias y un plan de vuelta atrás. Si el equipo está en pareja MLAG, además, son dos ventanas y una verificación por medio.

Por eso el aviso ofrece una salida intermedia que merece leerse entera, porque no es «apágalo» sino «ponle autenticación». La mitigación que publica Arista para P4Runtime es levantar el servicio en modo mTLS y exigir autorización por certificado de cliente. Así es como se ve una configuración ya mitigada, tal y como la imprime el aviso:

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

Léelo despacio y verás lo que de verdad dice: que el estado por defecto de esa interfaz es sin certificado y sin autorización. No es un descuido de Arista; es la herencia de un montón de interfaces gRPC de gestión que se diseñaron dando por supuesto que vivían en una red de administración de confianza. Esa suposición era razonable cuando el colector estaba en el mismo armario. Deja de serlo en cuanto el colector es una máquina virtual en otra subred, o un SaaS.

El 5,3 es el que te va a doler dentro de un año

CVE-2026-73457 saca un 5,3 y por eso va a quedar fuera de casi todos los informes. Dice que las credenciales del cliente gNPSI pueden quedar escritas en texto claro en los registros de accounting, locales o remotos. Nótese el «remotos». Esos registros son precisamente los que configuraste para tener trazabilidad: salen del equipo, llegan a un servidor TACACS+ o a un recolector de syslog, se conservan por política durante meses y se exportan cuando alguien los pide.

La puntuación mide el daño en el switch. La consecuencia real está en el otro extremo del cable: un sistema cuyo propósito es conservar y compartir ha pasado a guardar secretos sin que nadie lo decidiera. Y actualizar EOS no limpia lo ya escrito. Si en tu caso gNPSI estaba activo, la tarea no termina con el salto de versión: hay que rotar esas credenciales y hay que mirar hasta dónde han llegado las copias de esos registros. Es trabajo aburrido y es el que distingue un incidente cerrado de uno que parece cerrado.

La comprobación de veinte segundos

Los dos avisos traen sus propias órdenes de verificación, y ese es el entregable de este post. No hay que interpretarlas: hay que ejecutarlas y leerlas.

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

El criterio de lectura del primero lo da el propio aviso: si la salida dice Enabled: no, no hay exposición a ese fallo. Punto. La segunda te dice si gNPSI está levantado, y la tercera —que también la publica Arista— es la que te deja ver la autenticación de los clientes que han llegado a esa interfaz. Veinte segundos por equipo, menos si tienes automatizado el inventario. Y si la red la lleva un tercero, no hace falta que la ejecutes tú: hace falta que alguien te mande por escrito la salida de las dos órdenes en cada switch, con fecha. Que te digan «estamos cubiertos» no es una respuesta; la salida del comando sí.

Los tres campos que faltan en casi todos los inventarios de red

La parte que sobrevive a este aviso concreto es esta, y vale para cualquier fabricante. Un inventario de red normal guarda modelo, número de serie, versión de firmware, direcciones de gestión y, con suerte, la fecha de la última actualización. Con esos datos puedes contestar «¿qué versión tengo?», que es una pregunta que hoy no sirve. Faltan tres campos:

• Qué servicios de gestión y telemetría están encendidos en ese equipo, por nombre. No «tiene gestión»: gNMI, gNPSI, gNOI, P4Runtime, NETCONF, REST, SNMP, el que sea. Es la lista que decide a qué avisos tienes que hacer caso y a cuáles no.
• En qué VRF escuchan. Un servicio en la VRF de gestión, con su ACL, es un riesgo acotado; el mismo servicio escuchando en la VRF por defecto es otra cosa completamente distinta. Es el mismo CVE y no es el mismo problema.
• Si exigen certificado de cliente, o se conforman con que llegues. Esta es la que de verdad separa un aviso que te quita la tarde de uno que te quita el trimestre, y es la que nunca está escrita en ningún sitio.

Nosotros llevamos la red documentada en NetBox como fuente de verdad, y estos tres campos no vienen de serie en ningún sitio: hay que decidir ponerlos y hay que decidir quién los mantiene. Es exactamente el mismo trabajo que describíamos en 43 CVE en el switch de fibra de tu cabina, y ninguna es crítica, donde el problema no era la gravedad de nada sino que aquel equipo no tenía dueño. Un inventario que no sabe qué hay encendido no es un inventario: es una lista de compras antigua.

A quién no le toca, y por qué decirlo importa

Si las dos órdenes dicen que no, esto no va contigo. Ni ventana, ni salto de rama, ni reunión. Y merece la pena decirlo con la misma claridad con la que se cuenta la mala noticia, porque el coste de no comprobarlo tiene dos caras: una es dejar un diez abierto; la otra, menos comentada, es abrir una ventana de madrugada que no hacía ninguna falta, gastar el crédito de interrupciones del trimestre y llegar sin él al aviso que sí importaba. Una severidad condicional mal leída cuesta dinero en las dos direcciones.

Y una aclaración que toca hacer: nada de esto es un argumento contra Arista. No somos revendedores suyos ni de nadie, y un mes después, el 7 de octubre, otro fabricante publicó media docena de fallos de su sistema operativo de switching encontrados también en revisión interna. Encontrar y publicar fallos propios es lo que hace un fabricante serio; la alternativa es que los encuentre otro. Lo que sí es criticable, y es transversal a todo el sector, es que una interfaz de gestión moderna siga arrancando sin autenticación porque «está en la red de gestión». Esa red de gestión, en más de una casa que hemos visto, es una VLAN con buena intención.

Lo que haríamos esta semana

Primero, las dos órdenes en todos los switches, y la salida guardada con fecha. Segundo, para los que salgan activados: decidir entre apagar la función si el piloto de telemetría murió hace año y medioo levantarla en mTLS con autorización por certificado, que es lo que el fabricante firma. Tercero, programar el salto a 4.36.2F, 4.35.6M o 4.34.8M con la calma de quien sabe a cuántos equipos afecta y no con la prisa de quien no lo sabe. Y cuarto, abrir los tres campos en el inventario, porque el aviso que viene dentro de dos meses va a preguntar otra vez lo mismo.

Fuentes (consultadas el 15-10-2026): CVE-2026-73453, la puntuación 10.0 con su vector y el 9,5 de CVSS 4.0, la clase CWE-94, las fechas de publicación (9-09-2026) y revisión 1.1 (22-09-2026), la lista de versiones y plataformas afectadas y no afectadas, la frase «P4Runtime is disabled by default in Arista EOS», la orden show p4-runtime con el criterio «Enabled: no», el fragmento de configuración de mitigación en mTLS, las versiones corregidas y la frase «There is no hotfix for this issue» salen del aviso 0174 de Arista Networks. CVE-2026-73456 y CVE-2026-73457, sus puntuaciones (10.0 y 5,3 en CVSS 3.1; 9,2 y 6,0 en CVSS 4.0), las clases CWE-94 y CWE-532, el registro de credenciales en texto claro en logs de accounting locales o remotos, la orden show management api gnpsi, el estado apagado por defecto de gNPSI y sus versiones corregidas, del aviso 0158 de Arista Networks. La definición de Scope: Changed es de la especificación CVSS 3.1 de FIRST. La media docena de fallos publicados el mismo mes por otro fabricante, del aviso cisco-sa-hardening-nxosw1-cWzSbtR, del 7 de octubre de 2026. Lo nuestro, y lo acotamos: la lectura de la letra S:C aplicada a un switch de paso, la observación de que el equipo expuesto es el que alguien modernizó, el argumento de los dos costes de no comprobar y los tres campos de inventario.