Cisco comble sept failles dans Meraki, dont un buffer overflow à CVSS 9.6, sans workaround disponible
Le 7 octobre 2026, Cisco publie un correctif de durcissement qui comble sept vulnérabilités dans l’ensemble du parc Meraki — MX, MS, MR, MV, MG et Campus Gateways — jusqu’à CVSS 9.6, découvertes en interne à l’aide de modèles d’IA frontière. Sans workaround possible, la mise à jour du firmware est la seule issue pour des équipements qui portent le réseau de l’entreprise.
7 octobre 2026. Cisco publie « Cisco Meraki Security Hardening Release » et comble sept vulnérabilités dans l’ensemble de son parc Meraki. CVSS 9.6. C’est la note de la plus grave, un débordement de tampon mémoire. Aucun workaround. C’est ce que l’éditeur précise d’emblée pour les sept failles. Pourquoi c’est important : ces failles touchent les switches, les points d’accès, les passerelles SD-WAN et les caméras d’entreprises entières, sans échappatoire possible hors de la mise à jour du firmware.
Sept failles, regroupées par classe de faiblesse
Cisco ne publie pas sept avis séparés, mais un seul correctif de durcissement qui regroupe les vulnérabilités par classe de faiblesse — la CWE, Common Weakness Enumeration. Chaque groupe reçoit un CVE unique qui représente le bug le plus grave de sa catégorie. La lecture est donc inverse de l’habituelle : un CVE, ici, ne désigne pas une faille unique mais un ensemble de défauts apparentés.
Le tableau complet mérite d’être lu en détail, car les notes sont hautes.
- CVE-2026-76463 — contrôle d’accès insuffisant (CWE-284), notée CVSS 8.8. Elle couvre les contournements d’autorisation, d’authentification et de privilèges.
- CVE-2026-76464 — restriction insuffisante des opérations dans les limites d’un tampon mémoire (CWE-119), notée CVSS 9.6. C’est le débordement de mémoire, la faille la plus critique du lot.
- CVE-2026-76467 — contrôle insuffisant d’une ressource sur sa durée de vie (CWE-664), notée CVSS 7.5. Pointeurs nuls, libérations invalides, descripteurs de fichiers.
- CVE-2026-76468 — validation d’entrée insuffisante (CWE-20), notée CVSS 8.2. Traversée de chemin et contrôle de chemin externe inclus.
- CVE-2026-76469 — contrôle de flux insuffisant (CWE-691), notée CVSS 7.4. Boucles infinies, récursion non contrôlée, conditions de course.
- CVE-2026-76470 — calcul incorrect (CWE-682), notée CVSS 8.8. Débordements et troncatures arithmétiques.
- CVE-2026-76472 — neutralisation insuffisante d’éléments spéciaux (CWE-74), notée CVSS 8.8. Injections de commandes, d’OS ou d’arguments.
Une nuance technique tempère la note maximale. Le vecteur du 9.6 est adjacent (AV:A) : l’attaquant doit déjà être présent sur le segment réseau local, pas sur l’Internet ouvert. Cela n’est guère rassurant pour un parc Meraki — ces équipements vivent précisément à l’intérieur du réseau qu’ils protègent, et un attaquant qui a déjà un pied sur un poste compromis du campus ou de l’agence se trouve exactement à la bonne distance.
Ce découpage n’est pas un détail éditorial : il change la manière de trier le risque. Une seule CVE peut masquer plusieurs dizaines de bugs concrets, et la note publiée est un plafond, pas une moyenne.
Un parc entier concerné, quelle que soit la configuration
L’étendue du produit est l’autre fait marquant. Les sept failles touchent six familles d’équipements, et Cisco précise que c’est le cas indépendamment de la configuration de l’appareil.
La liste couvre presque tout le catalogue Meraki : les MX Security and SD-WAN Appliances, les MS Series Switches, les MR Wireless Access Points, les MV Smart Cameras, les MG Cellular Gateways et les Campus Gateways. Autrement dit, du cœur de réseau à la caméra de surveillance, en passant par le Wi-Fi et la connectivité cellulaire de secours, aucun segment n’est épargné.
La conséquence opérationnelle est brutale. Sur un avis classique, une équipe peut espérer qu’une fonction désactivée la mette hors de portée. Ici, non : il n’y a pas de workaround, et la vulnérabilité ne dépend d’aucun réglage. Un parc Meraki est exposé du simple fait d’être un parc Meraki.
Cette situation tranche avec le précédent avis NX-OS du 7 octobre 2026, où l’exposition dépendait de fonctions activées comme NX-API ou NGOAM. Sur Meraki, le calcul est plus simple — et plus exigeant.
Un virage assumé : tester avec des modèles d’IA frontière
La méthode de découverte mérite qu’on s’y arrête. Cisco indique que ces failles ont été trouvées « lors de tests de sécurité internes utilisant les processus existants ainsi que des modèles d’IA frontière ». C’est la première fois que l’éditeur le formule aussi explicitement pour un correctif Meraki.
Ce choix s’inscrit dans une stratégie plus large. Cisco a annoncé une transition vers un « modèle de divulgation des vulnérabilités fondé sur le risque », dans lequel les failles découvertes en interne sont regroupées par classe et publiées en vagues de durcissement plutôt qu’en avis éparpillés. L’IA y sert d’accélérateur : elle ratisse une surface — ici, un système d’exploitation qui équipe des millions d’appareils — à une vitesse qu’une équipe humaine ne tiendrait pas.
La bonne nouvelle tient en une phrase : Cisco n’a connaissance d’aucune annonce publique ni d’exploitation de ces failles. La moins bonne, c’est que les failles restent présentes tant que le firmware n’est pas à jour — et qu’un avis « sans exploitation connue » peut basculer en urgence en quelques jours.
Mettre à jour sans workaround : le calendrier réel
Sans workaround, la mise à jour est la seule sortie. Or les correctifs n’arrivent pas tous en même temps, ce qui complique la planification.
Pour les MX, les versions corrigées sont 18.107.14, 19.2.9 (uniquement pour les appareils Z3), 26.1.7 et 26.2.3. Pour les MS Series Switches, il faut 18.1.9 (mi-octobre 2026), IOS XE 17.15.6, 17.18.4.1 ou 26.1.2. Pour les MR, les versions sont 30.7.3, 31.1.8.1, 32.2.5 et 33.1.3. Les Campus Gateways attendent 32.2.5 (fin octobre) ou 33.1.4 (mi-novembre), et les MV Smart Cameras doivent passer en 8.0.
Deux points attirent l’attention. D’abord, certaines versions ne sont pas encore disponibles — 18.1.9 mi-octobre, 32.2.5 fin octobre, 33.1.4 mi-novembre — ce qui laisse une fenêtre d’attente pendant laquelle l’appareil reste vulnérable sans parade. Ensuite, la gestion Meraki passe par le Dashboard : pour la plupart des parcs, la mise à jour se pilote centralement, ce qui accélère le déploiement à condition d’avoir validé la fenêtre de maintenance.
Pour les équipes qui gèrent des Catalyst configurés dans le cloud via Meraki Dashboard, Cisco renvoie vers l’avis de durcissement IOS XE d’août 2026 pour les versions correspondantes.
Le piège des scanners et le ventre mou de l’IoT
Deux effets de bord méritent l’attention d’une équipe qui gère un parc Meraki.
Le premier touche aux scanners de vulnérabilités. Comme Cisco regroupe des dizaines de bugs sous un seul CVE par classe de faiblesse, un scanner qui se contente de comparer la version du firmware à une liste de CVE risque de mal évaluer l’exposition : il verra sept entrées, là où la réalité est un éventail de défauts concrets. Le diagnostic fiable passe par l’avis Cisco lui-même et le tableau des versions corrigées, pas par une signature générique de vulnérabilité.
Le second touche à la nature du parc. Les MX et les MS sont généralement suivis par l’équipe réseau ; les MV Smart Cameras et les MG Cellular Gateways le sont beaucoup moins. Une caméra de surveillance ou une passerelle cellulaire de secours traîne souvent des mois sans mise à jour, oubliée dans un couloir ou un local technique. Or ces appareils sont couverts par le correctif au même titre que le cœur de réseau.
Un attaquant qui entre par une caméra non patchée est déjà dans le VLAN de gestion. C’est la vraie leçon de ce correctif : la surface Meraki ne se résume pas aux équipements « nobles » du réseau, et la mise à jour doit couvrir l’ensemble du Dashboard, y compris les appareils que personne ne regarde.
Verdict
Si vous gérez un parc Meraki — switches, AP, caméras, MX ou gateways cellulaires, traitez ce correctif comme une priorité de la semaine : il n’existe aucun workaround, et la faille la plus grave atteint CVSS 9.6 sur des équipements qui portent votre réseau. Inventoriez vos versions, puis planifiez les mises à jour en tenant compte des versions encore à paraître — pour les Campus Gateways, la fenêtre peut glisser jusqu’à mi-novembre. Si votre parc est entièrement géré dans le Dashboard, c’est l’occasion de vérifier que votre politique de mise à jour automatique couvre bien les six familles concernées ; une caméra MV oubliée dans un couloir reste un point d’entrée. Dans tous les cas, surveillez les avis Cisco des prochains jours : un durcissement découvert par IA et publié sans exploitation connue peut se transformer en urgence active plus vite qu’un cycle de maintenance classique.