- Une vulnérabilité de traversée de chemin de sévérité maximale (CVSS 10.0) affecte les versions auto-gérées de GitLab et permet à un attaquant distant, sans aucune authentification, de lire des fichiers sensibles du serveur.
Ce qu’il faut savoir
Une faille de sécurité désignée CVE-2026-85706 a été répertoriée sur les éditions Community Edition (CE) et Enterprise Edition (EE) de GitLab. Classée avec un score CVSS 3.1 de 10.0, soit le niveau le plus élevé, cette vulnérabilité de type traversée de chemin (*path traversal*) réside dans l'API de commits des dépôts. Elle résulte d'une combinaison d'un confinement de chemin inadéquat et d'un défaut d'application de l'authentification, selon les analyses publiées par des chercheurs en sécurité.
Versions affectées
La faille touche une plage précise de versions auto-gérées de GitLab : toutes les versions à partir de la 18.7 et antérieures à la 19.1.8, les versions 19.2 antérieures à la 19.2.6, ainsi que les versions 19.3 antérieures à la 19.3.2. GitLab.com, la version hébergée par l'éditeur, fonctionne déjà avec une version corrigée. Les clients de GitLab Dedicated ne sont pas concernés et n'ont aucune mesure à prendre.
Conditions d'exploitation et données exposées
L'exploitation de cette vulnérabilité ne nécessite ni authentification, ni interaction de la part d'un utilisateur. Elle est exploitable à distance avec une faible complexité d'attaque. Un attaquant pourrait ainsi lire des fichiers arbitraires situés sur le serveur GitLab, dans la mesure où le processus GitLab y a accès. Selon la configuration du déploiement et les permissions des fichiers, cela peut inclure des informations de configuration sensibles, des identifiants, des secrets, des jetons d'accès, des clés SSH, des identifiants de base de données ou d'autres données côté serveur.
Un exploit de concept (*proof-of-concept*) de cette vulnérabilité a par ailleurs été rendu public, ce qui peut accélérer les tentatives d'exploitation en milieu réel.
Recommandations et incertitudes
GitLab recommande fortement la mise à niveau immédiate des installations auto-gérées affectées. Aucune solution de contournement fournie par l'éditeur ne devrait être considérée comme un substitut au correctif. En l'absence de possibilité de patcher sans délai, la restriction de l'accès réseau aux instances vulnérables peut réduire l'exposition, mais elle demeure une mesure temporaire de réduction du risque et non une correction.
Étant donné que l'exploitation réussie peut exposer des fichiers sensibles côté serveur, les organisations disposant d'instances accessibles depuis Internet devraient également évaluer si les identifiants ou secrets accessibles au processus GitLab nécessitent une rotation.
Le caractère exact de certaines configurations déployées en production rend difficile l'estimation précise du nombre d'instances réellement exposées. Les éditeurs et équipes de sécurité sont invités à croiser les informations fournies par les sources disponibles et à vérifier directement auprès des communications officielles de GitLab l'état des correctifs pour leurs environnements spécifiques.
Cette vulnérabilité s'inscrit dans une série de défauts affectant des plateformes de développement collaboratif largement utilisées. Sa sévérité et la facilité de son exploitation en font une cible de choix pour les acteurs malveillants, d'autant plus qu'un exploit public est désormais disponible.
7 sources
Cette synthèse rapproche plusieurs sources et est présentée dans la langue de cette édition. Langue source : EN.