La réponse courte
GitLab auto-hébergé contient une faille de lecture de fichier non authentifiée de gravité maximale — CVE-2026-85706, CVSS 10.0 — qui permet à un attaquant distant sans aucun compte de lire n’importe quel fichier sur le serveur. La cause profonde est un mauvais confinement des chemins et l’absence de contrôle d’authentification dans l’API des commits du dépôt : une seule requête HTTP POST vers /api/v4/projects/{id}/repository/commits/ avec un paramètre de chemin forgé sort du répertoire prévu et renvoie des fichiers arbitraires. GitLab CE et EE de 18.7 à 19.1.7, ainsi que 19.2.0–19.2.5 et 19.3.0–19.3.1, sont concernés. Les correctifs arrivent dans 19.3.2, 19.2.6 et 19.1.8.
Concrètement : toute instance GitLab auto-hébergée joignable depuis un réseau non fiable et comportant ne serait-ce qu’un projet public est exposée — et les attaquants la sondent déjà. Passez à une version corrigée en changement d’urgence, puis renouvelez chaque secret que l’instance pouvait contenir. Traiter votre serveur de code source comme une infrastructure cloud et DevOps sécurisée par défaut et segmentée est le correctif durable derrière le patch immédiat.
Qu’est-ce que CVE-2026-85706 ?
GitLab est l’endroit où la plupart des équipes conservent leurs joyaux : code source, merge requests, pipelines CI/CD et les secrets dont ces pipelines ont besoin pour atteindre la production. Le 10 septembre 2026, GitLab a publié une version de sécurité corrigeant CVE-2026-85706, une vulnérabilité critique de traversal de chemin dans l’API des commits, notée au maximum CVSS 10.0. Elle touche à la fois la Community Edition gratuite et l’Enterprise Edition payante sur une large plage de versions récentes.
La faille se situe dans l’API qui sert les données de commit du dépôt. En raison d’un mauvais confinement des chemins et de l’absence de contrôle d’authentification, un attaquant peut envoyer un unique POST HTTP vers /api/v4/projects/{id}/repository/commits/ avec un paramètre de chemin qui sort du dépôt et pointe vers n’importe quel fichier lisible par le processus GitLab. Pas de connexion, pas de jeton, pas d’interaction — la requête reçoit une réponse avant que l’authentification ne soit appliquée. La seule condition est qu’au moins un projet public existe sur l’instance, ce qui est vrai pour la grande majorité des déploiements réels. Comme il s’agit d’infrastructure côté serveur, la durcir relève autant du DevOps et de la plateforme que de l’applicatif.
GitLab.com, le SaaS hébergé par l’éditeur, est déjà corrigé ; le danger se concentre donc sur les quelque 20 000 instances GitLab auto-hébergées en service dans le monde — les serveurs on-premise et auto-hébergés que les entreprises exploitent elles-mêmes. GitLab a corrigé le problème dans les versions 19.3.2, 19.2.6 et 19.1.8, qui imposent un confinement des chemins et une authentification corrects sur le point d’entrée des commits.
Comment une requête lit n’importe quel fichier
Le traversal de chemin est l’une des plus anciennes classes de bugs web, et CVE-2026-85706 en est un exemple d’école au rayon d’impact moderne. Une API est censée confiner l’accès aux fichiers à un répertoire précis — ici, les données d’un dépôt donné. Lorsque le code qui résout un chemin fourni par l’appelant ne le normalise ni ne le confine, des séquences qui remontent l’arborescence permettent à la requête de sortir du dossier prévu et de référencer des fichiers ailleurs sur le disque. L’API des commits recevait un paramètre de chemin et l’utilisait sans confiner suffisamment sa destination.
Ce qui transforme un bug courant en urgence CVSS 10.0, c’est la combinaison des facteurs. Le point d’entrée répond avant l’application de l’authentification, donc aucun identifiant n’est requis. Il ne faut qu’une seule requête POST, ce qui rend l’attaque triviale à automatiser à l’échelle d’Internet. Et il s’exécute avec les privilèges du processus GitLab, capable de lire les fichiers de logs et de configuration du serveur. C’est exactement là que se trouve le précieux : chaînes de connexion à la base de données, clés de stockage objet, le secret d’instance servant à signer les jetons et des fragments d’identifiants qui fuient dans les logs. Les lire, et l’attaquant n’a plus besoin de la faille — il détient des clés valides.
Ce n’est pas théorique. Un réseau de honeypots watchTowr a observé des tentatives d’exploitation dès ~06h00 UTC le 11 septembre 2026, environ six heures après la divulgation. Le même jour, la CISA a ajouté CVE-2026-85706 à son catalogue Known Exploited Vulnerabilities au titre de la Binding Operational Directive 26-04, laissant aux agences fédérales civiles américaines jusqu’au 14 septembre 2026 pour corriger. Quand une faille de gravité maximale passe de l’avis au balayage actif en une matinée, la fenêtre pour patcher sereinement est déjà fermée.
Ce que cela signifie pour les équipes logicielles en France
Retirez le numéro de CVE et trois leçons durables demeurent. Premièrement, votre serveur de code source est une infrastructure de production, pas un confort de développeur. Les équipes accumulent authentification, WAF et limitation de débit sur les applications exposées aux clients, puis font tourner un GitLab auto-hébergé sur un réseau permissif parce que « ce ne sont que nos dépôts ». Or cette machine détient les identifiants de votre cloud et le code qui devient la production. Elle mérite le même modèle de menace que votre périphérie — et la même urgence de patch.
Deuxièmement, une lecture de fichier est une lecture de secret, et une lecture de secret est un événement de chaîne d’approvisionnement. Si cette faille est notée aussi haut qu’une exécution de code à distance, c’est que les fichiers qu’elle expose contiennent les clés de tout ce qui se trouve en aval. Une fois les variables CI/CD, les jetons de déploiement ou le matériel de signature divulgués, un attaquant peut pénétrer vos comptes cloud ou altérer les artefacts livrés aux clients. C’est pourquoi patcher ne suffit pas ici : si l’instance était joignable, vous devez supposer que les secrets sont sortis et les renouveler.
Troisièmement, l’exposition réseau est le multiplicateur, et le temps est l’ennemi. La différence entre « CVE critique corrigé sereinement » et « incident » tient presque toujours à savoir si le service vulnérable était joignable depuis l’endroit où se trouve l’attaquant, et à quelle vitesse vous avez réagi. Savoir précisément quels services internes sont joignables depuis Internet, et pouvoir les corriger en quelques heures, est le contrôle le plus rentable dans lequel investir.
Que faire maintenant
- Passez immédiatement à une version corrigée. Faites évoluer tout GitLab auto-hébergé sur une version concernée — 18.7–19.1.7, 19.2.0–19.2.5 ou 19.3.0–19.3.1 — vers 19.3.2, 19.2.6 ou 19.1.8. Traitez-le comme un changement d’urgence, pas une maintenance de routine.
- Renouvelez les secrets en supposant l’exposition. Si l’instance était joignable depuis Internet, renouvelez les variables CI/CD, les jetons de déploiement et d’accès, les identifiants de base de données et de stockage objet, le secret d’instance GitLab et toute clé cloud stockée dans les pipelines. Patcher arrête les lectures futures ; cela n’annule pas ce qui a déjà été pris.
- Sortez GitLab des réseaux non fiables. Un serveur de code source ne devrait être joignable que depuis des sous-réseaux de confiance ou derrière un VPN ou un proxy zero-trust. Si l’accès public à Internet n’est pas une exigence stricte, supprimez-le — cela seul neutralise cette classe d’attaque.
- Recherchez les signes d’exploitation. Examinez les logs d’accès pour les requêtes
POSTvers/api/v4/projects/{id}/repository/commits/avec des paramètres de chemin inhabituels ou de type traversal, et cherchez des clones de dépôt inattendus ou des jetons nouvellement créés. Préservez les logs avant leur rotation. - Intégrez votre couche DevOps aux tests de sécurité. GitLab auto-hébergé, registres et runners CI sont souvent laissés hors périmètre alors qu’ils détiennent les actifs les plus sensibles. Incluez-les dans votre prochain test d’intrusion et auditez les services internes voisins à la recherche de chemins pré-authentification similaires.
Questions fréquentes
Qu’est-ce que CVE-2026-85706 dans GitLab ?
CVE-2026-85706 est une vulnérabilité critique de traversal de chemin dans l’API des commits de GitLab, notée CVSS 10.0. En raison d’un mauvais confinement des chemins et de l’absence d’authentification, une seule requête HTTP POST non authentifiée vers /api/v4/projects/{id}/repository/commits/ peut lire des fichiers arbitraires sur le serveur — logs et fichiers de configuration contenant identifiants, secrets et jetons. Il suffit qu’un projet public existe sur l’instance pour que le point d’entrée soit joignable.
Quelles versions sont concernées et quels sont les correctifs ?
La Community et l’Enterprise Edition sont concernées : GitLab 18.7 à 19.1.7, 19.2.0 à 19.2.5 et 19.3.0 à 19.3.1. GitLab a publié les versions corrigées 19.3.2, 19.2.6 et 19.1.8. GitLab.com est déjà corrigé, donc l’exposition concerne les quelque 20 000 instances auto-hébergées. Mettez à jour immédiatement le GitLab auto-hébergé concerné ; à défaut, restreignez l’accès réseau public.
CVE-2026-85706 est-elle exploitée activement ?
Oui. Des réseaux de honeypots ont observé des tentatives d’exploitation dès ~06h00 UTC le 11 septembre 2026 — en quelques heures après la divulgation. La CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities le même jour au titre de la BOD 26-04, avec une échéance au 14 septembre 2026 pour les agences fédérales civiles américaines. Supposez un balayage opportuniste de toute instance exposée.
Nous avons patché — est-ce terminé ?
Pas nécessairement. Une lecture de fichier non authentifiée signifie que des secrets ont pu être exfiltrés avant la mise à jour. Après le patch, supposez une compromission sur toute instance joignable depuis Internet et renouvelez les variables CI/CD, les jetons de déploiement et d’accès, les identifiants de base de données et de stockage objet, le secret d’instance GitLab et les clés cloud. Examinez les logs d’accès de l’API des commits à la recherche de paramètres de chemin suspects et de clones ou jetons inattendus.
Pourquoi une faille de lecture de fichier est-elle notée CVSS 10.0 ?
Le vecteur CVSS est joignable par le réseau, de faible complexité, sans privilège ni interaction, avec un fort impact sur la confidentialité et des conséquences sur l’intégrité et la disponibilité. Sur un serveur GitLab, les fichiers lisibles incluent des identifiants et le secret d’instance — des clés qui permettent à un attaquant de pivoter vers votre cloud, d’empoisonner votre pipeline ou d’injecter du code malveillant. Un accès trivial et un impact aval catastrophique justifient le score maximal.
Sources
The Hacker News — GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure
Forkast — GitLab’s CVSS 10 Commits-API Flaw Hits Active Exploitation Within Hours
CISA — Known Exploited Vulnerabilities Catalog