HPE Aruba corrige deux exécutions de code sans authentification dans AOS-CX

1er septembre 2026. HPE Aruba Networking publie l’avis HPESBNW05134, qui corrige plus de vingt vulnérabilités dans ArubaOS-CX, le système d’exploitation de ses commutateurs CX. Deux bugs indépendants — CVE-2026-73749 (CVSS 9.8) et CVE-2026-73782 — donnent chacun l’exécution de code à distance sans authentification. Aucune exploitation confirmée dans la nature à ce jour. Pourquoi c’est important : un commutateur de cœur ou d’accès compromis devient un point d’interception du trafic, de saut de VLAN et de persistance que presque aucun EDR ne surveille.

Deux chemins d’exécution de code dans le même bulletin

CVE-2026-73749 est un débordement de tampon dans un démon d’ArubaOS-CX, provoqué par le traitement incorrect d’une entrée malformée. Un attaquant distant envoie des paquets spécialement conçus au service concerné — sans authentification, sans interaction utilisateur, avec une complexité d’attaque faible — et obtient l’exécution de code avec les privilèges élevés du démon. HPE ne nomme ni le démon ni le transport concerné, une pratique courante avant qu’un proof-of-concept public ne tombe.

CVE-2026-73782 est une faille de chaîne de format dans l’interface en ligne de commande d’ArubaOS-CX, également notée de sévérité élevée. Une chaîne de format apparaît quand une entrée contrôlée par l’attaquant — un nom d’hôte, une chaîne SNMP, un message syslog — est passée comme spécificateur de format plutôt que comme donnée. L’attaquant peut alors lire ou écrire en mémoire arbitraire et pivoter vers l’exécution de code.

L’anomalie tient à la coïncidence : deux composants structurellement différents du même système — un démon réseau d’un côté, le CLI de l’autre — sont exploitables indépendamment sans aucune information d’identification. La plupart des bulletins critiques livrent un bug vedette et une traîne de correctifs de moindre gravité. Celui-ci en livre deux.

Un périmètre qui couvre tout le parc maintenu

ArubaOS-CX équipe les commutateurs de la série CX — les familles 6000, 8000, 9000 et 10000 — massivement déployées en accès, distribution, cœur et top-of-rack dans les campus, les datacenters, la santé, l’éducation et les réseaux d’opérateurs. La plage affectée couvre essentiellement toutes les branches encore maintenues :

Le détail qui signe la gravité : la branche 10.10.x a déjà atteint sa fin de maintenance et ne reçoit normalement plus que des correctifs de failles critiques découvertes en interne. HPE a fait une exception pour corriger ces deux bugs sur cette branche — un signal que l’éditeur traite l’affaire comme prioritaire, pas comme un correctif de routine.

Pourquoi un commutateur vaut pire qu’un serveur

Un commutateur n’est pas un poste de travail. Le compromettre donne une position qui dépasse largement la machine elle-même. Depuis un commutateur de distribution ou de cœur, un attaquant peut intercepter, rediriger ou jeter le trafic de tous les hôtes situés derrière lui, pivoter entre VLAN, empoisonner les tables ARP ou DHCP, et récolter des informations d’identification au passage des flux TACACS+ ou RADIUS qu’il relaie, ainsi que des secrets 802.1X.

Surtout, le commutateur est un point de persistance furtif. Les équipes d’intervention reimage rarement un équipement réseau, et la plupart des SOC n’ont aucune visibilité au-delà du syslog sur ce qui se passe dans le plan de gestion d’un switch. Une exécution de code non authentifiée sur la fabrique de commutation est ce qui se rapproche le plus du pire scénario pour une CVE réseau.

Un mois chargé pour les équipements réseau

La faille Aruba s’inscrit dans une séquence dense pour le matériel réseau. Début septembre 2026, la CISA a inscrit au catalogue KEV deux failles MikroTik RouterOS activement exploitées. Cisco a de son côté corrigé une faille critique sur ses commutateurs Nexus 9000 — une exécution de code root non authentifiée via les ports TCP 43210 et 43211. Quelques jours plus tôt, Arista publiait des correctifs pour des exécutions de code non authentifiées via P4Runtime et gNPSI.

Ce regroupement n’est pas un hasard. Les équipements réseau sont devenus la cible privilégiée des acteurs qui cherchent un point d’appui durable, et les éditeurs concentrent leurs avis de sécurité en début de mois, souvent alignés sur leurs cycles de correctifs. Chaque avis critique sur du matériel réseau ouvre une fenêtre où la rapidité de correction compte double : l’équipement est rarement patché au même rythme qu’un serveur, et sa compromission n’est souvent détectée qu’après coup.

L’exposition compte plus que le score

Aucun proof-of-concept public ni exploitation confirmée n’existe à la date de publication, et la faille n’est pas listée dans le catalogue KEV de la CISA. Il ne faut pas y lire une raison d’attendre. Les CVE critiques sur équipements réseau avec avis public sont régulièrement armées en quelques jours à quelques semaines une fois le correctif rétro-ingéniérable. La fenêtre entre « patché et calme » et « scan de masse » est courte pour un bug 9.8 sur du matériel réseau.

La vraie question n’est pas le score CVSS, mais la surface d’exposition : le plan de gestion de vos commutateurs est-il isolé dans un VRF ou un VLAN dédié, ou bien est-il joignable depuis les VLAN utilisateurs — et, pire, depuis Internet ? Les failles ne sont exploitables que si le démon ou le CLI vulnérable est joignable par l’attaquant. Or, dans beaucoup de réseaux, cette joignabilité est plus large que ce que les équipes croient.

Ce qu’il faut faire maintenant

La correction se joue en trois gestes, dans l’ordre.

• Patcher en priorité. Appliquez la branche corrigée (10.18.1002, 10.17.1030, 10.16.1060, 10.13.1190, 10.10.1181) dès la prochaine fenêtre de maintenance. Téléchargez le firmware uniquement depuis le portail de support HPE et vérifiez signatures et sommes de contrôle.
• Isoler le plan de gestion dès aujourd’hui, patch ou pas. Déplacez les interfaces de gestion dans un VRF/VLAN de gestion joignable uniquement depuis des hôtes d’administration nommés, et imposez-le par des ACL sur chaque chemin routé. Cette seule mesure transforme un bug 9.8 en bug quasi inexploitable.
• Réduire les services exposés. Désactivez le REST API et l’interface web (https-server) sur tout commutateur qui n’a pas besoin de gestion programmatique, et coupez Telnet ainsi que les chaînes SNMPv1/v2c en lecture-écriture.

La surveillance vient en complément, pas en substitut. Centralisez le syslog d’ArubaOS-CX vers le SIEM et alertez sur les créations de compte, les changements de configuration, les core dump et les échecs d’authentification — les tentatives d’exploitation de services embarqués produisent souvent un bruit de crash avant de réussir.

Verdict

Si vous exploitez des commutateurs Aruba CX en production, appliquez la branche corrigée à la première fenêtre de maintenance disponible : deux exécutions de code sans authentification livrées dans le même bulletin sont un signal rare, et l’historique des CVE réseau montre qu’il précède souvent une exploitation de masse. Si le patch est impossible à court terme, isolez immédiatement le plan de gestion dans un VLAN/VRF dédié et désactivez le REST API et l’interface web sur les équipements qui n’en ont pas besoin — ces deux mesures convertissent un risque critique en un risque résiduel acceptable le temps de planifier la mise à jour.

Références

• HPE — HPESBNW05134, Multiple Vulnerabilities in HPE Aruba Networking AOS-CX
• SecurityWeek — HPE Patches Critical RCE Vulnerabilities in AOS-CX
• BleepingComputer — HPE patches critical ArubaOS-CX remote code execution flaw
• IONIX Threat Center — CVE-2026-73749
• Security Arsenal — CVE-2026-73749 detection and remediation guide, 4 septembre 2026