Arista EOS expose des exécutions de code non authentifiées via P4Runtime et gNPSI
Arista a publié le 9 septembre quatre avis de sécurité pour Arista EOS, dont un RCE non authentifié noté CVSS 10.0 via P4Runtime (CVE-2026-73453) et deux exécutions de code via l’interface de télémétrie gNPSI. Aucune exploitation active n’est documentée à ce jour, mais la correction doit précéder toute exposition du plan de contrôle.
9 septembre 2026. Arista Networks publie quatre avis de sécurité pour Arista EOS, le système d’exploitation de ses commutateurs et routeurs. Au centre, CVE-2026-73453, une exécution de code arbitraire non authentifiée via P4Runtime, notée CVSS 10.0. Le même jour, l’avis 0158 documente CVE-2026-73456 et CVE-2026-73457, deux exécutions de code via gNPSI. Aucune exploitation active n’est observée pour l’instant — ce qui laisse une fenêtre étroite pour corriger avant qu’une preuve de concept ne change la donne.
Le plan de contrôle programmable devient la surface d’attaque
La nouveauté tient moins à la gravité qu’à la localisation. Les failles d’Arista EOS ne touchent pas la gestion SNMP ni le CLI, mais les interfaces programmables qui font la modernité du réseau : P4Runtime, le runtime qui pilote le plan de données programmable P4, et gNPSI, l’interface de télémétrie d’échantillonnage de paquets bâtie sur gRPC.
CVE-2026-73453 illustre le danger. Un client P4Runtime non authentifié peut envoyer une requête malveillante pendant l’initialisation de la session et obtenir le contrôle administratif complet du commutateur. Le score parle de lui-même : CVSS 10.0 en v3.1, vecteur AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, classé CWE-94, l’injection de code. Le service écoute sur le port 9559, typiquement dans le VRF de gestion.
CVE-2026-73456 et CVE-2026-73457 suivent le même schéma via gNPSI : un client non authentifié forge une requête pour exécuter du code arbitraire et s’emparer de l’appareil. Trois chemins d’exécution de code, zéro authentification exigée.
De la gestion au contrôle, la frontière s’efface
Pendant vingt ans, sécuriser un équipement réseau consistait à verrouiller le plan de gestion : SSH, SNMP, le port console. Les failles d’Arista EOS rappellent que la frontière a bougé. P4Runtime et gNPSI ne relèvent pas de la gestion au sens classique — ce sont des interfaces de contrôle programmatique, pensées pour qu’un contrôleur SDN ou un collecteur de télémétrie parle à l’équipement à la vitesse du plan de données.
Cette évolution a déplacé la surface d’attaque sans toujours déplacer les réflexes. Une équipe qui ferme SSH et SNMP vers Internet peut laisser P4Runtime joignable parce qu’« il faut bien que le contrôleur s’y connecte ». Le résultat est le même qu’une console ouverte : un chemin non authentifié vers le contrôle complet, mais dans un protocole que les équipes auditent moins parce qu’il est plus récent.
Le CVSS 10.0 de CVE-2026-73453 est le symptôme de ce décalage : la gravité maximale vient de ce que le chemin ne demande ni identifiant, ni interaction, ni privilège — exactement le profil que les interfaces programmables modernes, conçues pour la confiance interne, offrent par défaut.
L’IS-IS, ou quand le protocole de routage lui-même flanche
Le quatrième avis de la vague concerne IS-IS, le protocole de routage à état de liens utilisé dans les cœurs de réseau et chez les opérateurs. Des paquets forgés peuvent rompre une adjacence IS-IS, provoquant une perte de trafic, ou corrompre la base d’état de liens (LSDB), avec le même résultat.
La différence de nature compte. Un RCE sur P4Runtime ou gNPSI exige d’atteindre une interface de gestion ou de télémétrie. Une faille IS-IS, elle, se joue sur le plan de contrôle du routage — le chemin que les paquets de vos voisins empruntent en permanence. Corrompre une LSDB, c’est convaincre des routeurs de construire des tables de routage fausses ; rompre une adjacence, c’est dégrader la connectivité sans toucher au plan de données. IS-IS n’est pas un protocole de campus : c’est le protocole de cœur des grands fournisseurs d’accès et des datacenters qui privilégient sa stabilité et son indépendance vis-à-vis d’IP. Une faille qui corrompt sa base d’état de liens touche donc l’infrastructure la plus sensible du réseau — celle dont une panne se propage à des milliers de clients en quelques secondes.
Arista a aussi publié un avis 0181 pour VeloCloud Edge : une validation insuffisante des entrées dans les workflows de gestion et de configuration permet qu’une requête ou une valeur de configuration soit interprétée comme une commande système. La surface SD-WAN s’ajoute ainsi au plan de contrôle.
Pourquoi ces interfaces sont si souvent exposées
Le point délicat est organisationnel. P4Runtime et gNPSI sont activés dans les architectures qui font de la télémétrie et du contrôle programmatique — c’est-à-dire précisément les déploiements modernes qui ont des raisons légitimes de laisser ces ports ouverts vers un contrôleur ou un collecteur.
Les bonnes pratiques veulent qu’ils restent confinés au VRF de gestion, non routé vers Internet. Mais un VRF de gestion mal segmenté, une ACL oubliée, ou un contrôleur compromis suffit à transformer une interface conçue pour la confiance en porte d’entrée. Le CVSS 10.0 de CVE-2026-73453 suppose la pire configuration — atteignable depuis le réseau — mais c’est exactement la configuration que beaucoup d’équipes sous-estiment.
Arista recommande de corriger vers les versions EOS corrigées et de vérifier l’exposition réelle des services concernés. La vérification, pour qui connaît l’équipement, est simple :
# Vérifier si P4Runtime est activé et sur quel VRF il écoute
switch>show p4-runtime
# Vérifier l'état des adjacences IS-IS
switch>show isis neighborsCe qu’il faut faire, dans l’ordre
- Corriger EOS vers les versions indiquées dans les avis 0158, 0160, 0174 et 0181 — ne pas attendre l’exploitation publique.
- Confiner P4Runtime et gNPSI au VRF de gestion, sans routage vers Internet, et restreindre l’accès par ACL aux contrôleurs autorisés.
- Auditer les adjacences IS-IS et le plan de contrôle : une corruption de LSDB ne se voit pas forcément dans les journaux d’accès, mais dans des changements de topologie inexpliqués.
- Isoler la gestion SD-WAN (VeloCloud Edge) derrière les mêmes contraintes, car l’avis 0181 élargit la surface.
Détecter une compromission qui ne laisse pas de trace d’authentification
Le pire dans ces failles, c’est leur silence. Un RCE non authentifié sur P4Runtime ne génère pas d’échec de connexion à scruter — il n’y a pas d’échec. La compromission ressemble à une session légitime, et l’attaquant a les mêmes privilèges que l’administrateur.
La détection doit donc se faire sur des signaux indirects : des changements de configuration inexpliqués, des sessions de contrôleur inhabituelles, une consommation mémoire anormale du processus, ou des modifications de topologie que personne n’a lancées. Pour IS-IS, le symptôme est plus parlant : une adjacence qui tombe et remonte sans raison, ou une LSDB qui change alors qu’aucun lien n’a bougé.
La parade est la même que pour toute infrastructure de cœur : un journal centralisé des configurations, des diff de configuration quotidiens, et une limite mémoire (cgroup) sur les processus de contrôle, pour qu’une allocation excessive se traduise par un redémarrage contrôlé plutôt qu’une panne de l’équipement.
Verdict
Arista EOS n’est pas victime d’une exploitation active — pour l’instant. C’est précisément ce qui fait de cette vague un test de maturité : corriger avant la preuve de concept, plutôt qu’après l’incident.
Si vous exploitez des commutateurs Arista EOS, corrigez dès maintenant et confinez P4Runtime (port 9559) et gNPSI au VRF de gestion. Le CVSS 10.0 de CVE-2026-73453 n’est pas une curiosité académique : il décrit un chemin sans authentification vers le contrôle complet d’un équipement de cœur.
Si vous gérez un réseau de cœur ou d’opérateur, traitez l’avis IS-IS avec la même priorité que les RCE : une LSDB corrompue ou une adjacence rompue, c’est une panne de connectivité qui ne laisse aucune trace d’authentification.