SolarWinds corrige une clé statique qui ouvre l’exécution de code à distance sur Access Rights Manager
Le 17 septembre 2026, SolarWinds a publié un correctif pour CVE-2026-28326, une exécution de code à distance sans authentification dans Access Rights Manager causée par une clé statique codée en dur. Appliquez la 2026.2.1 sans attendre et auditiez vos outils de gouvernance d’accès à la recherche de secrets en dur.
17 septembre 2026. SolarWinds publie un bulletin pour CVE-2026-28326, une faille de son produit Access Rights Manager (ARM) cotée 8,8 sur l’échelle CVSS. 19 septembre. La faille est couverte publiquement, sans trace d’exploitation à ce jour. 20 septembre. Le correctif 2026.2.1 est la seule version à exécuter. Pourquoi c’est important : la vulnérabilité tient à une clé statique codée en dur, et elle aboutit à une exécution de code à distance sans authentification — dans un outil dont le métier est précisément de contrôler qui a accès à quoi.
Une clé unique qui ouvre toutes les portes
Le cœur du problème tient en une phrase du bulletin : « The issue stems from a hard-coded static key ». Access Rights Manager embarque une clé statique codée en dur dans son code. Or une clé statique n’est pas un secret : c’est une valeur identique sur toutes les installations, distribuée avec le binaire, et donc connue de quiconque a déjà extrait, désassemblé ou simplement téléchargé le produit.
La conséquence est mécanique. Si cette clé protège un jeton d’authentification, un canal chiffré ou la validation d’une charge utile, l’attaquant qui la connaît peut forger ce qu’il faut pour se faire passer pour un composant légitime. SolarWinds qualifie le résultat sans ambiguïté : une exécution de code à distance sans authentification. Aucun compte, aucun mot de passe, aucune interaction utilisateur n’est requis — il suffit d’atteindre le service et de connaître la clé, ce qui est acquis d’avance puisqu’elle est identique partout.
L’ironie n’échappe à personne. Access Rights Manager est un produit de gouvernance des accès : il sert à provisionner, auditer et révoquer des droits sur des serveurs, des fichiers et des annuaires. Qu’un tel outil soit lui-même percé par une clé universelle — le contraire exact d’un contrôle d’accès — transforme une faille technique en argument de comité d’audit : la boîte qui vend la gestion des privilèges distribuait, dans son binaire, l’équivalent d’un passe-partout.
Ce que corrige exactement la 2026.2.1
Le bulletin est court mais précis. La faille affecte toutes les versions d’Access Rights Manager 2026.2 et antérieures. Le correctif est livré dans la version 2026.2.1, seule version remédiée. SolarWinds crédite le chercheur Kai Huang, du cabinet Armadin, pour la découverte et le signalement. L’éditeur précise ne pas avoir connaissance d’une exploitation en conditions réelles à la date du bulletin — une précision rassurante, mais qui ne change rien à l’urgence : un correctif d’exécution de code à distance sans authentification ne se planifie pas, il s’applique.
Le score CVSS 8,8 place la faille en criticité haute, juste sous le seuil des 9,0 réservés aux catastrophes. Le vecteur d’attaque est réseau, la complexité d’attaque faible, et aucun privilège ni interaction n’est exigé. En pratique, toute instance ARM joignable depuis un réseau — y compris le réseau interne, où ces outils de gouvernance sont souvent exposés sans filtre — est une cible.
Deux points méritent l’attention d’un RSSI au-delà du correctif lui-même. D’abord, la nature de la cause : une clé codée en dur n’est pas un oubli isolé, c’est une classe de défaut que les scanners de secrets et la revue de code sont censés attraper avant la mise en production. Ensuite, la position du produit : ARM opère souvent avec des privilèges élevés, car il doit lire les annuaires et pousser des droits. Une exécution de code dans ce contexte ne donne pas un simple shell — elle donne potentiellement la main sur l’ensemble de la chaîne d’identité.
Un éditeur sous pression sur la chaîne d’identité
La faille ne tombe pas dans le vide. Il y a environ deux mois, SolarWinds corrigeait déjà une faille critique de Web Help Desk — CVE-2026-28323, cotée 9,8 — un contournement d’authentification SAML lorsque l’authentification SAML 2.0 était activée. Le même bulletin traitait une faille de déni de service (CVE-2026-28299, 8,2) capable de faire planter le serveur par épuisement mémoire.
Le motif est révélateur. Dans les deux cas, le défaut se loge dans la couche d’authentification ou dans la couche d’identité — le SAML d’un côté, la clé statique de l’autre — et non dans une fonction métier périphérique. Pour un éditeur dont le portefeuille est historiquement associé à la gestion des infrastructures et des identités, la répétition de failles dans cette couche est plus embarrassante qu’un simple correctif mensuel : elle interroge la robustesse des mécanismes d’authentification internes à l’éditeur lui-même.
Pour un RSSI, la lecture est double. Il ne s’agit pas de pointer du doigt un fournisseur, mais de reconnaître un risque systémique : les outils de gestion des accès et d’identité concentrent les privilèges les plus larges de l’entreprise, et sont donc les cibles où une faille d’authentification produit le plus de dégâts. Un produit de gouvernance ne devrait jamais embarquer de secret statique ; s’il le fait, c’est le signe qu’il faut le segmenter et le surveiller comme un actif critique, pas comme un logiciel utilitaire.
Comment détecter ce type de faille chez vous
La bonne nouvelle : cette classe de défaut se détecte avant l’éditeur, si l’on s’en donne les moyens.
- Scannez les secrets en dur. Des outils comme TruffleHog, gitleaks ou les scanners intégrés aux plateformes de CI détectent les clés, mots de passe et chaînes statiques suspectes dans les dépôts, les images et les binaires. Une clé statique partage la signature d’un secret : une valeur longue, aléatoire et identique d’un build à l’autre.
- Inventoriez vos outils de gouvernance. Recensez ARM, les PAM, les IAM et tout composant qui manipule des privilèges. Notez leur version, leur exposition réseau et leur niveau de privilège. Un correctif non appliqué sur un tel outil a un coût disproportionné.
- Segmentez la surface d’identité. Ces outils ne devraient être joignables que depuis un réseau d’administration dédié, jamais depuis le réseau utilisateur ni, évidemment, depuis Internet.
- Surveillez les signaux d’exploitation. Une exécution de code sur un outil de gouvernance laisse des traces : connexions sortantes anormales, création de comptes, élévation de privilèges. Le journal d’accès de l’outil lui-même est la première source à brancher sur la détection.
La leçon générale dépasse SolarWinds. Une clé codée en dur qui débouche sur une RCE sans authentification est un scénario que l’on retrouve dans les équipements réseau, les objets connectés et les appliances de sécurité — bref, partout où un éditeur a choisi la commodité d’un secret embarqué plutôt que la rigueur d’un provisionnement par instance.
Verdict
Si vous exploitez SolarWinds Access Rights Manager, appliquez la 2026.2.1 immédiatement, et considérez toute instance en 2026.2 ou antérieure comme compromise par conception tant qu’elle n’est pas à jour — le correctif est d’autant plus urgent qu’il est trivial de reproduire une attaque fondée sur une clé connue de tous. Si vous ne l’exploitez pas, retenez la règle générale : tout produit qui détient des privilèges mérite une segmentation stricte et une veille correctif prioritaire, car c’est là qu’une faille d’authentification coûte le plus cher. Si vous maintenez des logiciels en interne, ajoutez la détection de secrets en dur à votre chaîne de CI et traitez chaque occurrence comme un incident : une clé statique qui survit au code review est un passe-partout en attente d’être trouvé.