Un mot de passe codé en dur dans Cisco Secure FMC, exploité avant correctif : mécanisme, chaînage, et comment tenir les secrets hors du code web.
Le 29 juillet 2026, Cisco publie un avis de sécurité pour son Secure Firewall Management Center, le FMC : la console centrale qui pilote des flottes entières de pare-feux d'entreprise. Le contenu tient en une phrase. Le logiciel embarque un compte dont les identifiants sont écrits en dur dans le code, identiques sur toutes les installations du monde, et quelqu'un s'en sert déjà.
Pas une erreur de configuration chez un client distrait : un compte livré d'usine, gravé dans le produit, exploité avant même que le correctif existe.
Ce billet raconte ce qu'on sait de cette faille, CVE-2026-20316, puis s'attarde sur deux questions plus intéressantes que l'alerte elle-même. Pourquoi son score de gravité, un modeste 5,3 sur 10, décrit si mal ce qui se passe sur le terrain. Et pourquoi ce motif précis, le mot de passe codé en dur, resurgit depuis vingt ans dans l'équipement de sécurité d'entreprise, celui qu'on achète pour se protéger. Avec, pour finir, un retour dans nos projets web : ce défaut-là n'a pas besoin d'une usine de firmware pour naître, un commit suffit.
via GIPHY
Ce qu'on sait de CVE-2026-20316
Le FMC n'est pas un pare-feu : c'est la tour de contrôle. Les boîtiers Cisco Secure Firewall (ex-Firepower) filtrent le trafic ; le FMC, lui, les administre tous. Il pousse les politiques de sécurité, centralise les journaux, orchestre les mises à jour. Qui tient le FMC tient tous les pare-feux qu'il pilote.
L'avis du 29 juillet décrit des « identifiants statiques » pour un compte intégré à faibles privilèges, dont Cisco ne divulgue pas le nom. Un attaquant distant, sans authentification préalable, peut s'y connecter et lire les données auxquelles ce compte a accès. Et l'avis ajoute une phrase qui pèse : cet accès peut être combiné avec d'autres vulnérabilités du FMC pour obtenir une élévation de privilèges. Lesquelles ? Cisco ne le dit pas.
Le périmètre, lui, est large : les branches 7.0, 7.2, 7.4, 7.6, 7.7 et 10.0 sont toutes touchées, autrement dit tout ce qui est maintenu. Aucun contournement n'existe : on ne peut ni désactiver le compte, ni changer son mot de passe. La seule sortie est un correctif dédié, publié pour chaque branche. Cisco note une circonstance atténuante : le risque chute si l'interface d'administration n'est pas exposée à Internet. Elle ne devrait jamais l'être ; l'exploitation en cours prouve qu'elle l'est pourtant, quelque part.
Pour qui administre un FMC, la conduite à tenir tient en trois gestes : appliquer le correctif de sa branche sans attendre le prochain créneau, vérifier que l'interface d'administration n'est joignable que depuis un réseau de gestion, et chercher dans les journaux les indicateurs publiés, parce qu'un correctif ne déloge pas un intrus déjà entré.
La chronologie tient en trois dates. En juillet, l'équipe de réponse de Cisco (le PSIRT) constate une exploitation active. Le 29, l'avis sort, et la CISA ajoute la CVE à son catalogue KEV le jour même. Le 30, le CERT-FR relaie, en toutes lettres : « Cisco indique que la vulnérabilité CVE-2026-20316 est activement exploitée ». Une faille exploitée avant son correctif, un zero-day au sens propre.
Un dernier détail, publié avec l'avis : les indicateurs de compromission. Sur un FMC attaqué, on trouve dans /var/log/messages la trace d'un fichier license.tmp et d'un processus www qui invoque un script d'empaquetage en root. Gardez ce détail en tête, il raconte toute la suite.
Un 5,3 exploité avant son correctif
CVSS, pour ceux qui n'y passent pas leurs journées, est le barème standard de gravité des vulnérabilités : une note de 0 à 10, calculée depuis un vecteur qui décrit les conditions d'attaque et l'impact. Celui de CVE-2026-20316 se lit ainsi : attaquable depuis le réseau, sans privilèges, sans interaction d'un utilisateur. Sur l'accessibilité, le pire scénario possible. Mais l'impact retenu est « confidentialité : faible », intégrité et disponibilité nulles. Verdict comptable : 5,3, sévérité « Medium ». Dans beaucoup d'organisations, un Medium attend le prochain cycle de maintenance.
En face, le catalogue KEV de la CISA (Known Exploited Vulnerabilities) ne recense que les vulnérabilités dont l'exploitation est constatée sur le terrain, preuves à l'appui. Environ 1 700 entrées au total, quand il se publie des dizaines de milliers de CVE par an. Pour les agences fédérales américaines, une entrée au KEV déclenche une obligation de correction sous délai ; pour tout le monde, c'est le meilleur filtre de priorisation disponible. Une CVE notée 5,3 qui y entre le jour de sa publication, c'est un grand écart : la théorie du score dit « moyen », le terrain dit « déjà utilisé ».
Le barème fonctionne pourtant comme prévu. Le score de base évalue chaque vulnérabilité isolément, hors contexte d'exploitation ; les métriques d'environnement et de menace qui pourraient l'ajuster existent sur le papier, presque personne ne les calcule. Le KEV a été créé pour combler ce trou : réinjecter le terrain dans la priorisation. Quand les deux signaux divergent, c'est le terrain qui commande.
L'écart s'explique. Un score CVSS note une vulnérabilité au singulier ; un attaquant travaille au pluriel. Le compte en dur du FMC, pris isolément, ouvre peu de portes : c'est ce que mesure le 5,3. Mais Cisco l'écrit dans son propre avis, cet accès se combine avec d'autres failles pour monter en privilèges. Et l'indicateur de compromission publié n'est pas une hypothèse : un processus www, le compte le moins privilégié de la machine, qui exécute un script en root, c'est la photographie d'un chaînage réussi. L'attaquant est entré par la petite porte, et il est déjà propriétaire des lieux.
Ajoutez la simplicité. Exploiter un compte en dur ne demande ni shellcode, ni fuzzing, ni développement d'exploit : l'attaque tient dans un formulaire de connexion. La faille de l'ANTS s'exploitait avec une boucle for ; celle-ci s'exploite avec un copier-coller.
Même sans élévation, relisez ce que « les données accessibles à ce compte » veut dire sur cet équipement précis. Le FMC voit la topologie, les règles de filtrage, ce qui est journalisé et ce qui ne l'est pas. Pour préparer une intrusion, cette lecture seule suffit : elle dit ce que la défense voit, et surtout ce qu'elle ne voit pas.
Ce mécanisme, un droit d'accès jugé sur son étiquette plutôt que sur ce qu'il permet en pratique, les lecteurs de ce blog l'ont déjà croisé. C'est l'histoire de la faille IDOR de l'ANTS : un utilisateur « authentifié, donc en règle », à qui rien ne demandait si le compte consulté était le sien. Ici, un compte « à faibles privilèges, donc sans gravité », dont personne n'a regardé ce qu'il ouvrait une fois combiné. Deux failles sans rapport technique, la même erreur de raisonnement.
Sur le même sujet
Une boucle for contre 11,7 millions de Français : autopsie d'une faille IDOR
Vingt ans que le même motif revient
Ce n'est pas la première fois. Loin de là.
En 2018, la presse spécialisée tenait déjà les comptes : un compte d'accès retiré du code pour la quatrième fois en quatre mois, sixième vulnérabilité d'identifiants en dur de l'année chez Cisco, onzième depuis début 2017. La plus parlante touchait DNA Center, la console d'administration réseau : des « identifiants statiques non documentés pour le compte administrateur par défaut », score maximal (CVE-2018-0222).
En 2024, la Smart Licensing Utility, un utilitaire de gestion de licences, embarque un compte administrateur en dur (CVE-2024-20439, notée 9,8). Exploitation constatée, entrée au KEV en mars 2025, et déjà un chaînage : les attaquants la combinaient avec une fuite d'information dans les journaux de debug du même produit.
En 2025, l'Unified Communications Manager, la téléphonie d'entreprise : des identifiants SSH root en dur, « destinés au développement et aux tests », impossibles à changer ou à supprimer (CVE-2025-20309, notée 10 sur 10). Là non plus, aucun contournement : un correctif, sinon rien.
En 2026, le FMC. Le motif est si récurrent qu'il a son matricule dans la nomenclature des faiblesses logicielles : la faille FMC est classée CWE-259, « Use of Hard-coded Password », déclinaison de la famille CWE-798, « Use of Hard-coded Credentials ». Une famille abonnée au Top 25 des faiblesses les plus dangereuses : 18e en 2023, 22e en 2024.
Pourquoi ça revient ? Ni malveillance, ni monopole Cisco : l'entreprise documente, corrige, publie ses indicateurs de compromission, et le motif existe chez d'autres constructeurs. La mécanique de fabrication est plus banale, et n'importe quel développeur la reconnaîtra. Un compte de test pour la CI. Un accès de support pour diagnostiquer à distance. Un raccourci « en attendant la vraie authentification ». Chacun naît avec une date de péremption implicite, qu'aucun processus ne fait respecter. Le temporaire part en release, et la release part chez tous les clients.
Et le libellé « à faibles privilèges » joue un rôle précis dans cette survie. Un compte root en dur saute aux yeux en revue de code ; un compte de service en lecture seule ressemble à un détail d'implémentation. C'est l'étiquette rassurante qui lui fait passer les relectures, et c'est la même qui, des années plus tard, fait sous-noter la CVE. Le FMC coche les deux cases.
Ce qui change avec une appliance, c'est la position du client : aveugle, et menotté. Aveugle, parce que personne ne greppe le firmware de son pare-feu ; un compte en dur y reste invisible jusqu'à ce qu'un chercheur rétro-conçoive l'image, ou qu'un attaquant trouve la recette le premier. Menotté, parce que le jour où le mot de passe fuit, impossible d'en changer : il est dans le binaire. La rotation, le geste réflexe pour n'importe quel secret compromis, exige ici un correctif du constructeur et une fenêtre de maintenance chez chaque client. Un mot de passe codé en dur, c'est une constante qui se prend pour un secret.
Reste l'économie de l'arbitrage, et elle est déloyale : la commodité du compte en dur est immédiate, encaissée par l'équipe qui développe ; le risque est différé, porté par les clients. Vingt ans de CVE montrent comment cet arbitrage se rejoue tant qu'aucune contrainte extérieure ne le renchérit. La contrainte arrive, on y revient en clôture.
Et dans un projet web ?
Un projet PHP n'embarque pas de firmware, mais le même motif y prospère sous des formes très reconnaissables. La clé d'API collée « en attendant » dans un fichier versionné. Le compte de test des fixtures, mot de passe connu de toute l'équipe, qui traverse les environnements jusqu'à la prod. Le token statique échangé entre deux services maison, « on mettra de la vraie auth plus tard ».
La comparaison avec une appliance joue pourtant en notre faveur, et c'est ce qui rend le sujet actionnable : notre code, on peut le grepper ; nos secrets, on peut les faire tourner par un changement de configuration. Ce que le client d'un FMC ne peut pas faire, nous le pouvons chaque jour. Encore faut-il un outillage et une doctrine. Voici ceux de ce blog, un projet dont toute l'infrastructure est versionnée, donc vérifiable.
Un scanner de secrets à trois étages. gitleaks tourne en hook de pre-commit, où il bloque un secret avant son entrée dans l'historique ; en CI sur chaque pull request, en filet si le hook a été contourné ; et en audit périodique sur l'historique complet du dépôt. Sa liste d'exclusions ne contient que du bruit structurel, valeurs de test et certificats locaux ; jamais le chemin d'un vrai secret.
Une source unique pour les secrets de production. Ici, un coffre Ansible Vault, chiffré et versionné ; ailleurs, ce sera un gestionnaire de secrets managé, ou le coffre natif de Symfony (secrets:set). L'outil importe moins que la propriété obtenue : aucun secret ne vit dans le code, et le code démarre à l'identique qu'ils soient là ou pas.
Des valeurs factices qui coupent le réseau. Convention maison : tout client d'API externe (emailing, statistiques, indexation) lit sa clé dans une variable d'environnement, et si la valeur est vide ou préfixée dummy-, le client se tait et journalise au lieu d'appeler. L'environnement de développement démarre sans aucun vrai secret. La tentation du « je colle la vraie clé dans le code, c'est pour tester » perd son terrain.
Le compte de test, lui, ne se scanne pas : son mot de passe est censé être là. La garde est ailleurs, dans la frontière des environnements. Des fixtures chargées par groupes, jamais en production, et un mot de passe de test qui n'ouvre rien d'autre que des données de test. Le jour où un compte de fixtures peut se connecter en prod, ce n'est plus un compte de test, c'est un compte en dur avec un alibi.
Et la doctrine pour le jour où ça rate quand même : un secret qui a fuité se répare par rotation, jamais par réécriture d'historique. Réécrire les commits fabrique une illusion d'effacement ; la valeur a été publique, donc elle est compromise, donc elle change. C'est la leçon FMC lue en miroir : la gravité d'une fuite se mesure au temps qu'il faut pour faire tourner la valeur. Une constante ne tourne jamais.
Honnêteté oblige, ce blog n'a pas toujours été au niveau de sa propre doctrine. Son serveur MCP de production, une petite API de gestion de contenu, a d'abord tourné avec un token Bearer statique : généré une fois, rangé dans le coffre, valable pour toujours.
Pas codé en dur dans les sources, mais cousin germain du motif : un secret unique, sans expiration, dont la révocation n'était prévue nulle part. Il a depuis été remplacé par un vrai serveur OAuth2, jetons courts, signés, révocables ; et la vieille clé traîne encore dans le coffre, inerte, étiquetée « à purger ». Comme la plupart de ses semblables, elle était née d'un report.
Le mot de la fin
Au printemps, un portail citoyen laissait incrémenter des identifiants dans une URL. Cet été, un pare-feu d'entreprise embarque son passe-partout d'usine. À quelques mois d'écart, le même fil rouge : un accès censé être limité, qui ne l'est pas dans les faits, évalué sur son étiquette jusqu'à ce que quelqu'un regarde ce qu'il permet.
L'équipement de sécurité mérite là-dessus une lucidité particulière, parce qu'il concentre le risque. Un pare-feu, une console d'administration, un gestionnaire d'identité, ce sont des logiciels : écrits sous les mêmes délais, avec les mêmes raccourcis que les nôtres, puis placés à l'endroit exact du réseau où une faille rapporte le plus. Le mot « Secure » dans un nom de produit décrit une promesse commerciale ; la tenir est un travail d'ingénierie, jamais un acquis. La défense en profondeur existe pour ce jour précis : celui où une couche, même la plus chère, se découvre une constante qui se prenait pour un secret.
La contrainte extérieure annoncée plus haut, elle, a une date. Le 11 septembre 2026, le Cyber Resilience Act active ses obligations de signalement : un fabricant devra notifier sous 24 heures toute vulnérabilité activement exploitée dans un produit vendu en Europe. Le motif ne disparaîtra pas par décret ; son coût, en revanche, change de camp.
Contexte réglementaire
Cyber Resilience Act : mainteneur, steward ou simple passant ?
Il reste le versant qui nous appartient, à nous qui n'assemblons pas de firmware. Le compte de test « qu'on virera avant la release », le token « en attendant », la clé « juste pour la démo » : chacun attend quelque part son avis de sécurité. Le vôtre est parti en prod dans quelle release ?
Une coquille, une erreur dans ce billet ? Signale-la-moi.
Ce billet est publié sous licence Creative Commons BY-NC-SA 4.0 (attribution, pas d'usage commercial, partage dans les mêmes conditions).