Un développeur laisse un mot de passe dans le code. Un groupe APT étatique l'exploite pendant 18 mois sans être détecté. Ce scénario n'est pas hypothétique — c'est exactement ce qui vient de se passer avec Dell RecoverPoint for VMs et CVE-2026-22769, CVSS 10.0. Les identifiants codés en dur dans les appliances enterprise ne sont pas un bug parmi d'autres : c'est une faille systémique, récurrente, que les acteurs les plus sophistiqués de la planète cherchent et trouvent méthodiquement.

Ce qu'est un identifiant codé en dur — et pourquoi ça n'aurait jamais dû exister

Un identifiant codé en dur (hardcoded credential) est un nom d'utilisateur et/ou un mot de passe intégré directement dans le code source d'une application ou d'un firmware, sans mécanisme de configuration externe, de rotation, ou de personnalisation par l'administrateur. Dans le cas de Dell RecoverPoint for VMs (CVE-2026-22769), c'étaient les credentials d'administration Apache Tomcat Manager : identiques sur chaque appliance déployée dans le monde, immuables, et directement exploitables par quiconque disposait d'un accès réseau à l'interface de gestion.

La question qui se pose immédiatement est : comment un tel problème peut-il exister en 2026, dans un produit enterprise vendu à des entreprises du Fortune 500, des banques, des hôpitaux, et des opérateurs d'infrastructures critiques ? La réponse est inconfortable : parce que les pratiques de développement sécurisé ne sont toujours pas universellement appliquées dans l'industrie des équipements réseaux et des appliances, et parce que les audits de code source des composants intégrés (Tomcat, Spring, bibliothèques tierces) sont systématiquement déprioritisés au profit des fonctionnalités.

Les identifiants codés en dur naissent souvent d'intentions initialement légitimes : un compte de service pour des scripts internes d'administration, un accès de diagnostic pour le support technique, un compte de test jamais supprimé avant la mise en production. Dans d'autres cas, ils résultent d'un simple oubli — un développeur qui configure un composant middleware avec les credentials par défaut et ne pense jamais à les externaliser vers un gestionnaire de secrets sécurisé.

Le problème fondamental est que contrairement à une vulnérabilité d'injection ou à un débordement de buffer, les identifiants codés en dur ne peuvent pas être corrigés par un simple patch une fois déployés massivement. Ils requièrent une mise à jour firmware sur chaque instance, souvent complexe et risquée dans des environnements de production critiques. C'est pourquoi, une fois découverts, ils sont exploités sur une fenêtre temporelle très longue avant que la majorité des déploiements ne soient mis à jour.

En 2026, les outils de détection automatique de secrets dans le code (GitLeaks, TruffleHog, Semgrep avec les règles secrets) sont matures, peu coûteux, et triviaux à intégrer dans un pipeline CI/CD. Il n'y a aucune excuse technique valable pour laisser passer ce type de vulnérabilité dans un produit commercial. Ce qui persiste, c'est un problème de culture et de priorité dans les organisations qui développent des équipements enterprise.

L'historique embarrassant : les cas emblématiques des dix dernières années

CVE-2026-22769 n'est pas un incident isolé. C'est le dernier épisode d'une longue série qui illustre l'ampleur systémique du problème dans l'industrie des équipements réseau et des appliances enterprise.

En 2016, CVE-2016-1289 exposait des identifiants SSH codés en dur dans Cisco Prime Infrastructure, permettant un accès root à distance. En 2017, Fortinet reconnaissait la présence d'une backdoor SSH dans FortiOS — identifiants statiques permettant un accès administrateur sur toutes les appliances FortiGate d'une certaine génération. Ces incidents n'ont pas déclenché de prise de conscience durable dans l'industrie.

En 2019, les recherches sur Cisco ROMMON (CVE-2019-1649, Thrangrycat) exposaient des mécanismes de boot sécurisé contournables grâce à des clés de chiffrement codées en dur. En 2020, l'incident SolarWinds démontrait comment des identifiants statiques dans le pipeline de build pouvaient compromettre la supply chain de 18 000 organisations simultanément — un cas extrême, mais dont la mécanique de base (credentials statiques dans un composant partagé) est identique.

En 2022, CVE-2022-20821 touchait les credentials codés en dur dans Cisco IOS XR. En 2023, plusieurs recherches sur les firmware de routeurs domestiques (ASUS, TP-Link, Netgear) révélaient des dizaines de comptes backdoor identiques sur des millions d'appareils déployés. En 2024, des chercheurs de Bishop Fox documentaient 15 appliances VPN et firewall enterprise avec des credentials statiques dans leurs interfaces de gestion.

Et en 2026, CVE-2026-22769 dans Dell RecoverPoint boucle la boucle, avec 18 mois d'exploitation silencieuse par une APT étatique. Le point commun de tous ces incidents : une fois les credentials publiés dans un CVE, ils sont automatiquement intégrés dans les outils d'attaque automatisés — Metasploit, scanners Shodan — et l'exploitation devient triviale pour n'importe quel acteur. L'APT UNC6201 a eu 18 mois d'avance exclusive ; après la publication, c'est tout le monde qui peut s'en emparer.

Ce qui frappe dans cette liste, c'est la régularité. Un incident de ce type tous les 6 à 12 mois, sur des produits enterprise de premier rang, vendus à prix gold à des organisations avec des exigences de sécurité contractuelles. L'industrie ne traite pas ce problème avec la sévérité qu'il mérite, et les clients paient le prix — parfois littéralement.

Pourquoi les APT adorent les credentials statiques

Du point de vue d'un groupe APT étatique, les identifiants codés en dur représentent le saint graal de l'accès initial. Contrairement à un exploit de corruption mémoire qui peut être instable, nécessiter un timing précis, ou provoquer des crashs détectables, un credential statique offre un accès silencieux, fiable, et répétable. On s'authentifie avec un nom d'utilisateur et un mot de passe valides — aucun IDS basé sur l'analyse comportementale ne lève d'alerte sur une authentification légitime réussie.

La durée d'exploitation de CVE-2026-22769 (18 mois) illustre parfaitement l'avantage opérationnel que représente ce type de vulnérabilité pour une APT avec un objectif de persistance à long terme. UNC6201 n'avait pas besoin de maintenir une infrastructure d'exploit fragile ou de contourner des mécanismes de détection comportementale. Il suffisait de connaître les credentials statiques — probablement extraits par reverse engineering du firmware — et de les utiliser de manière espacée et discrète.

Les appliances de backup et disaster recovery constituent une cible particulièrement attractive pour plusieurs raisons cumulatives. Premièrement, elles ont accès à l'intégralité des données répliquées sur l'infrastructure — une mine d'or pour le cyberespionnage sans avoir à compromettre les serveurs de production un par un. Deuxièmement, elles sont systématiquement moins bien surveillées : les équipes SOC concentrent leurs alertes sur les serveurs applicatifs et les postes de travail, pas sur les appliances d'infrastructure supposées être des boîtes noires fiables. Troisièmement, les appliances DR ont généralement des permissions très larges dans les environnements VMware, précisément parce que leur fonction légitime nécessite ces accès.

La technique des Ghost NICs découverte dans l'opération UNC6201 illustre un autre avantage des APT qui compromettent des appliances VMware : la capacité à manipuler l'infrastructure de virtualisation elle-même pour créer des vecteurs de mouvement latéral transparents aux outils de monitoring. Une interface réseau virtuelle créée et supprimée dynamiquement sur un hôte ESXi ne laisse aucune trace dans les règles de firewall statiques, aucune entrée dans les tables de routage permanentes, et ne déclenche aucune alerte dans les SIEM configurés pour surveiller des interfaces réseau fixes.

Enfin, les identifiants codés en dur présentent un avantage de persistance unique : ils survivent aux réinitialisations de configuration, aux changements de mot de passe administrateur, et parfois même aux mises à jour partielles de firmware. Tant que la version vulnérable est présente, l'accès est maintenu — indépendamment de toutes les mesures de sécurité opérationnelles que l'organisation peut avoir mises en place par ailleurs.

Comment détecter les credentials codés en dur dans votre parc

La détection proactive des identifiants codés en dur dans votre environnement repose sur plusieurs approches complémentaires. Aucune n'est suffisante seule — c'est leur combinaison qui donne une couverture réaliste.

La première approche est le scan de secrets dans vos dépôts de code internes. Si vous développez des outils d'infrastructure, des scripts d'administration, ou des configurations déployées via GitOps, l'intégration de Gitleaks, TruffleHog, ou des fonctionnalités built-in de GitLab et GitHub Advanced Security dans votre pipeline CI/CD est non négociable. Ces outils analysent chaque commit pour détecter les patterns ressemblant à des secrets : mots de passe, clés API, tokens OAuth, certificats privés. Une configuration en mode bloquant empêche tout push de commit contenant un secret détecté.

La deuxième approche concerne les appliances et équipements tiers. Ici, la détection proactive est plus complexe car vous n'avez pas accès au code source. La démarche pragmatique est le suivi rigoureux des CVE et des bulletins de sécurité éditeurs (Fortinet PSIRT, Dell PSIRT, Cisco PSIRT, Palo Alto Networks Security Advisories) sur tous les équipements de votre parc. L'abonnement aux flux CERT-FR, CISA KEV, et NVD en filtrant sur vos éditeurs vous donne une visibilité quasi-temps réel sur les nouvelles vulnérabilités de credential statique.

La troisième approche est l'inventaire des comptes d'administration avec mots de passe statiques dans votre SI. Chaque appliance, chaque équipement réseau, chaque serveur devrait être audité pour identifier les comptes dont le mot de passe n'a jamais changé depuis le déploiement initial. Les outils PAM (Privileged Access Management) comme CyberArk, HashiCorp Vault, ou BeyondTrust permettent de centraliser et de faire tourner automatiquement les credentials d'administration, éliminant de facto le problème des mots de passe statiques sur les équipements qui le supportent.

La quatrième approche, souvent négligée, est l'analyse de firmware par des équipes de sécurité spécialisées. Des outils comme Binwalk permettent d'extraire et d'analyser les systèmes de fichiers embarqués dans les firmwares, révélant parfois des fichiers de configuration avec des credentials en clair ou des binaires compilés avec des chaînes d'authentification statiques. C'est une démarche qui dépasse les capacités des équipes SI classiques mais qui peut être confiée à des prestataires de sécurité lors d'audits ciblés sur les équipements critiques.

Sur le plan de la détection d'exploitation active, les logs d'authentification des composants middleware sur vos appliances constituent une source précieuse. Des authentifications réussies sur des endpoints de déploiement d'application (/manager/deploy, /manager/text/deploy) depuis des IPs non autorisées doivent déclencher des alertes immédiates. La surveillance des modifications de fichiers dans les répertoires d'application des middlewares via HIDS (Wazuh, OSSEC, Falco) complète ce dispositif en alertant sur le dépôt de nouveaux exécutables ou scripts dans des répertoires sensibles.

Ce que les éditeurs devraient faire — et pourquoi ils ne le font pas

La réponse de Dell à CVE-2026-22769 illustre un pattern récurrent dans l'industrie : publication d'un patch et d'un bulletin de sécurité, sans réelle remise en question des pratiques de développement ayant permis cette vulnérabilité d'exister. Aucun éditeur majeur n'a jamais publié, à ma connaissance, un post-mortem public détaillant comment des credentials codés en dur se sont retrouvés dans leur produit, quels contrôles ont failli, et quelles mesures structurelles ont été prises pour que ça ne se reproduise pas.

Cette opacité n'est pas accidentelle. Elle protège la réputation commerciale à court terme, mais elle nuit à l'ensemble de l'industrie en empêchant le partage d'apprentissages sur des défaillances systémiques. Les programmes de bug bounty sont utiles mais insuffisants : ils récompensent la découverte, pas la prévention. Ce dont l'industrie a besoin, c'est d'une obligation de transparence sur les incidents de sécurité liés à des défauts de développement, similaire à ce que la directive NIS2 commence à imposer pour les incidents opérationnels.

La pression réglementaire commence à produire des effets. Le Cyber Resilience Act européen, entré en vigueur progressivement depuis 2024, impose des exigences de sécurité by design sur les produits avec éléments numériques mis sur le marché européen. La présence de credentials codés en dur constitue une violation directe de ces exigences, exposant les éditeurs à des amendes significatives. C'est un levier économique qui, couplé aux coûts croissants des incidents, devrait progressivement changer les comportements — mais sur une échéance de plusieurs années, pas de plusieurs mois.

Les bonnes pratiques côté éditeurs sont connues : génération de credentials uniques à l'initialisation de chaque appliance, séparation stricte entre comptes de service internes et comptes d'administration exposés, désactivation des interfaces de management middleware (Tomcat Manager, Spring Boot Admin) sur les builds de production, et intégration obligatoire de scans de secrets dans les pipelines de build comme condition de non-régression bloquante. Ces pratiques ne sont pas nouvelles, elles ne sont pas coûteuses à implémenter — elles sont simplement non prioritaires pour trop d'éditeurs.

Mon avis d'expert

CVE-2026-22769 ne m'a pas surpris. J'aurais pu vous citer cinq équipements enterprise standards pour lesquels je n'aurais pas parié qu'il n'existait pas de credentials statiques quelque part dans leurs composants. Ce qui m'a frappé dans cet incident, c'est la durée : 18 mois. Un an et demi pendant lequel un APT étatique avait un accès root silencieux sur des appliances de disaster recovery, c'est-à-dire sur une copie de l'intégralité des données de ses victimes. Pas de ransomware, pas de destruction — juste de l'observation et de la collecte. C'est le cyberespionnage dans sa forme la plus efficace et la plus dangereuse. La défense contre ce type d'attaque ne passe pas par un antivirus ou un SIEM mieux configuré. Elle passe par une réduction de la surface d'attaque sur les équipements d'infrastructure, une surveillance active des composants middleware, et une culture de la vérification de l'intégrité — pas seulement des serveurs de production, mais de tout ce qui a accès à vos données critiques.

Conclusion

Les identifiants codés en dur dans les appliances enterprise sont une vulnérabilité systémique que l'industrie refuse de traiter avec le sérieux qu'elle mérite. Tant que les éditeurs ne sont pas contraints par la réglementation ou pénalisés commercialement de manière significative pour ce type de défaut, le pattern va se répéter. Pendant ce temps, les APT étatiques — qui ont les ressources pour extraire et analyser des dizaines de firmwares par mois — continueront à constituer des inventaires de credentials statiques qu'ils exploiteront patiemment et silencieusement.

Pour les RSSI et administrateurs systèmes : l'inventaire de vos appliances, la mise en place d'une veille CVE ciblée sur vos éditeurs, et le placement des interfaces de gestion dans des VLAN isolés ne sont pas des bonnes pratiques optionnelles. Ce sont des mesures de base sans lesquelles votre SOC sera toujours en retard sur les acteurs les plus sophistiqués.

Besoin d'un regard expert sur la sécurité de vos appliances ?

Ayi NEDJIMI réalise des audits ciblés sur vos équipements d'infrastructure pour identifier les configurations dangereuses avant qu'un APT ne les exploite.

Prendre contact