Un dépôt Git n’est jamais seulement un dépôt Git. Derrière GitLab se trouvent souvent des runners, des pipelines CI/CD, des variables, des jetons, des fichiers de configuration et parfois toute une chaîne de déploiement. Lorsqu’une vulnérabilité permet de sortir du périmètre de fichiers prévu par une application, le problème change immédiatement d’échelle.
C’est précisément ce qui rend CVE-2026-85706 particulièrement sensible. La vulnérabilité affecte GitLab Community Edition et Enterprise Edition, possède un score CVSS 10.0 et est signalée comme exploitée dans la nature. Le CERT-FR l’a classée parmi les vulnérabilités critiques de la semaine du 7 au 13 septembre 2026.
Cette vulnérabilité ne doit pas être traitée comme une simple mise à jour logicielle. Pour une instance GitLab self-managed exposée pendant la période vulnérable, corriger le logiciel et vérifier les traces d’exploitation sont deux opérations différentes.
Le danger commence là où GitLab cesse de regarder
Le terme Path Traversal peut sembler abstrait. Pourtant, le principe est relativement simple : une application reçoit un chemin de fichier et doit s’assurer que ce chemin reste à l’intérieur du répertoire auquel l’utilisateur est autorisé à accéder.
Si cette frontière est mal contrôlée, une requête destinée à consulter une ressource précise peut potentiellement atteindre un autre emplacement du système de fichiers.
SOUS LE CAPOT
Requête utilisateur → API GitLab → validation du chemin → système de fichiers
frontière mal contrôlée → lecture hors du périmètre attendu
Dans CVE-2026-85706, le problème concerne l’API des commits de dépôt. Le CERT-FR classe la vulnérabilité comme un contournement de la politique de sécurité, avec un score CVSS de 10 selon le NVD, et indique qu’elle est exploitée.
Pourquoi une lecture de fichier peut devenir une affaire beaucoup plus grave
Il faut éviter un raccourci : lire un fichier arbitraire ne signifie pas automatiquement prendre le contrôle du serveur.
Le problème est ailleurs.
Sur un serveur GitLab, certains fichiers peuvent contenir des informations utilisées par l’application elle-même ou par les services auxquels elle est connectée. Une information sensible récupérée sur le serveur peut ensuite devenir un élément d’une attaque plus large.
Une vulnérabilité de lecture devient réellement dangereuse lorsqu’on regarde ce que le serveur sait, et pas seulement ce que l’application affiche.
GitLab peut se trouver au centre d’une chaîne comprenant code source, automatisation, runners, registres, déploiements et services externes. C’est cette chaîne de confiance qui doit être examinée après une exposition.
Le paradoxe du serveur GitLab moderne
GitLab est devenu une véritable plateforme DevSecOps. Le dépôt n’est que la partie visible.
Autour du dépôt peuvent graviter :
- des pipelines CI/CD ;
- des runners ;
- des variables d’environnement ;
- des jetons d’accès ;
- des registres de conteneurs ;
- des intégrations cloud ;
- des systèmes de déploiement ;
- des outils de supervision et de sécurité.
Cette centralisation est extrêmement pratique pour les équipes de développement. Elle signifie aussi qu’un incident touchant le serveur GitLab doit être analysé en tenant compte de son environnement.
Une vulnérabilité critique, mais surtout une question de contexte
Le score CVSS de 10.0 attire immédiatement l’attention. Mais le chiffre ne raconte pas toute l’histoire.
Deux entreprises utilisant exactement la même version vulnérable de GitLab peuvent avoir des niveaux d’exposition très différents selon leur architecture, leurs contrôles réseau, leurs secrets et leurs intégrations.
Les versions corrigées
GitLab a publié des versions correctives pour les branches concernées. Pour les installations self-managed, la première question est donc très concrète : quelle version tourne réellement sur votre serveur ?
Le piège : « J’ai patché, donc c’est terminé »
C’est probablement la partie la plus importante de cette affaire.
Installer le correctif empêche l’exploitation de la vulnérabilité corrigée. Cela ne répond cependant pas à une autre question : l’instance a-t-elle déjà été exploitée avant la mise à jour ?
Après le correctif, l’administrateur doit déterminer si des requêtes suspectes ont atteint l’instance pendant la période d’exposition et si des informations ont effectivement été transmises.
Ce que les administrateurs doivent vérifier
Pour une instance GitLab self-managed concernée, la réponse ne devrait donc pas s’arrêter à apt upgrade ou à une mise à jour du paquet.
✓ Identifier la version exacte de GitLab.
✓ Vérifier si l’instance est self-managed.
✓ Installer une version corrigée.
✓ Examiner les journaux d’accès et applicatifs.
✓ Rechercher les traces associées à l’API concernée.
✓ Identifier les données potentiellement exposées.
✓ Réinitialiser les secrets qui auraient pu être compromis.
✓ Vérifier les intégrations, runners et systèmes connectés.
GitLab.com n’est pas le même scénario
Il faut également distinguer une installation GitLab administrée par une entreprise d’un compte utilisant GitLab.com.
Les informations publiées concernant cette vulnérabilité distinguent les environnements self-managed des services opérés par GitLab. Rapid7 indique notamment que GitLab.com a été corrigé, tandis que les environnements GitLab Dedicated ne nécessitent pas d’action spécifique de la part du client pour cette vulnérabilité.
Aux organisations qui administrent elles-mêmes une instance GitLab CE ou EE et qui ont utilisé une version affectée pendant la période concernée.
Ce que cette faille révèle sur les infrastructures modernes
Il y a quelque chose de plus intéressant derrière cette vulnérabilité qu’un simple numéro CVE.
Les plateformes de développement modernes concentrent énormément de responsabilités dans une même interface. GitLab peut être à la fois dépôt de code, moteur CI/CD, gestionnaire de secrets, point d’intégration et interface d’administration.
Cette centralisation améliore considérablement le travail des équipes. Mais elle augmente aussi la valeur d’une compromission réussie.
On ne protège plus seulement un dépôt de code. On protège tout ce que ce dépôt permet d’atteindre.
Le signal important : la vulnérabilité est déjà exploitée
Le CERT-FR indique explicitement que CVE-2026-85706 est exploitée et lui attribue un score CVSS de 10 selon le NVD. Rapid7 la classe également parmi les vulnérabilités critiques exploitées dans la nature.
Ce détail change la manière dont une équipe de sécurité doit prioriser son intervention : il ne s’agit plus seulement d’une faille publiée avec une mise à jour disponible. Il faut considérer la possibilité qu’une instance vulnérable ait déjà été ciblée.
La différence se joue dans les journaux, les secrets, les intégrations et les preuves d’exploitation.
Pour une instance GitLab self-managed vulnérable, la priorité est double : corriger puis investiguer.
Les versions corrigées existent : 19.1.8, 19.2.6 et 19.3.2. Mais si l’instance était exposée avant la mise à jour, le travail de sécurité ne s’arrête pas au numéro de version.
Patch, logs, secrets, intégrations : c’est toute la chaîne qu’il faut regarder.
Sources & liens de sécurité
Sources consultées et vérifiées par HexaOS — 17 septembre 2026.
Sources vérifiées par HexaOS — 17 septembre 2026.
