GitLab héberge le code source, les identifiants de déploiement et les pipelines de nombreuses entreprises. Le 10 septembre 2026, l’éditeur a publié un correctif critique pour la CVE-2026-85706, une faille notée 10 sur 10 en CVSS qui permet à un attaquant non authentifié de lire des fichiers du serveur. Cet article a un but de sensibilisation et d’aide au correctif : il explique ce que la faille permet, comment savoir si vous êtes concerné, comment corriger, quoi renouveler et comment chercher des traces d’exploitation. Il ne contient aucun mode opératoire d’attaque.
Avertissement : ForenShield n’est pas responsable de l’usage que vous faites de ces informations. Tester ou attaquer un serveur qui ne vous appartient pas, sans autorisation écrite, est une infraction pénale dans la plupart des pays.
La CVE-2026-85706 en bref #
Selon l'avis de sécurité de GitLab, il s’agit d’une traversée de chemin (path traversal) dans l’API des commits d’un dépôt : un contrôle insuffisant du chemin de fichier et l’absence d’authentification exigée permettent, dans certaines conditions, de lire des fichiers arbitraires du serveur.
| Élément | Valeur |
|---|---|
| Type | Traversée de chemin, lecture arbitraire de fichiers |
| Authentification requise | Aucune |
| Score CVSS 3.1 | 10.0 (critique) |
| Éditions | Community Edition (CE) et Enterprise Edition (EE) |
| Correctif publié le | 10 septembre 2026 |
Le score est maximal parce que l’attaque est faisable à distance, sans compte, sans interaction, et que les fichiers lisibles contiennent des secrets qui ouvrent d’autres accès (le vecteur CVSS indique un changement de périmètre). Pour comprendre comment se lit ce score, consultez notre guide sur le score CVSS.
Selon l'analyse de Rapid7, la faille est déjà exploitée dans la nature. Considérez donc qu’une instance exposée et non corrigée est une cible.
À retenir : ce n’est pas une faille XSS (injection de script dans le navigateur d’une victime). C’est une lecture de fichiers côté serveur, sans authentification, ce qui change complètement la réponse à apporter : il faut corriger, puis renouveler les secrets.
Versions concernées et versions corrigées #
| Branche | Versions vulnérables | Version corrigée |
|---|---|---|
| 18.x | 18.7 à 19.1.7 | 19.1.8 |
| 19.2 | 19.2.0 à 19.2.5 | 19.2.6 |
| 19.3 | 19.3.0 à 19.3.1 | 19.3.2 |
GitLab.com et GitLab Dedicated sont déjà corrigés par l’éditeur. Seules les instances auto-hébergées (self-managed) doivent agir.
Ce qu’un attaquant peut espérer lire #
Le risque dépend des fichiers accessibles au processus GitLab. Les analyses publiées listent notamment :
- les identifiants de base de données et les secrets applicatifs ;
- le fichier de secrets qui contient les clés de chiffrement de Rails ;
- les jetons d’intégration, clés de déploiement et variables CI/CD ;
- les données de dépôts hébergés sur le serveur.
La conséquence pratique dépasse le serveur lui-même : un secret lu peut être réutilisé plus tard pour se connecter ailleurs, ce qui rend l’incident silencieux.
Comment corriger et se protéger #
Voici l’ordre d’action recommandé :
- Isoler l’instance si elle est exposée. Retirez l’accès depuis Internet ou limitez-le aux réseaux de confiance (VPN, liste d’adresses autorisées) le temps du correctif.
- Conserver les journaux avant la mise à jour. Copiez les journaux d’API, de Rails et du serveur web : ils serviront à l’enquête.
- Mettre à jour vers 19.1.8, 19.2.6 ou 19.3.2 (ou plus récent). Les installations sur un seul nœud subissent une interruption pendant les migrations ; les déploiements multi-nœuds peuvent suivre la procédure sans interruption de GitLab.
- Analyser les traces d’exploitation (voir ci-dessous).
- Renouveler les secrets une fois que vous savez ce qui a pu être lu : mots de passe de base de données, jetons d’accès personnels, jetons de runners, clés de déploiement, secrets d’intégration, identifiants SMTP et de stockage objet, sessions actives.
- Vérifier l’activité CI/CD : tâches inattendues, nouveaux runners enregistrés, nouveaux utilisateurs ou clés.
Une précaution s’impose pour les clés de chiffrement de Rails : les renouveler de manière incorrecte peut rendre illisibles les valeurs chiffrées en base. Suivez uniquement la procédure de rotation documentée par GitLab.
Détecter une tentative d’exploitation #
Cherchez, dans les journaux d’API, de Rails, du serveur web et du pare-feu applicatif :
- des requêtes non authentifiées vers l’API des commits d’un projet ;
- des paramètres contenant des chemins de fichiers inhabituels ou des séquences de remontée de répertoire ;
- des réponses de taille inhabituelle pour des appels sans compte ;
- une même adresse source qui interroge de nombreux projets.
GitLab a publié trois règles de détection décrivant des tentatives de lecture de fichiers locaux ; reportez-vous à son avis pour les récupérer. Corrélez ensuite ces événements avec toute utilisation tardive d’un jeton ou d’une clé, qui indiquerait qu’un secret a servi.
Quand est-il légitime de tester la vulnérabilité ? #
Un dépôt public, CVE-2026-85706, publie une démonstration de cette faille. Son auteur précise qu’elle est réservée aux tests d’intrusion autorisés et aux laboratoires isolés. Tester est acceptable uniquement dans l’un de ces cas :
- Votre propre instance GitLab, dans un laboratoire isolé, sans données réelles et sans lien avec Internet.
- Un test d’intrusion contractualisé, avec un périmètre écrit, des dates précises et l’accord signé du propriétaire du serveur.
- Un exercice de formation (CTF, plateforme de laboratoire) conçu pour cela.
Dans tous les autres cas, n’essayez pas. Lire des fichiers sur le serveur d’un tiers, même « pour vérifier », constitue un accès frauduleux à un système d’information. Si vous constatez qu’une instance tierce est vulnérable, prévenez son propriétaire ou le CERT compétent, sans tenter d’y accéder.
Pour contrôler votre propre exposition sans exploiter quoi que ce soit, comparez la version de GitLab installée avec le tableau ci-dessus (page d’aide de l’interface, section version) et vérifiez si l’instance répond depuis Internet.
Ce que cette faille rappelle #
- Ne pas exposer inutilement un GitLab auto-hébergé : un accès par VPN réduit fortement le risque.
- Considérer les secrets comme jetables : plus ils sont faciles à renouveler, moins un incident coûte.
- Suivre les avis de l’éditeur, avec une adresse d’équipe abonnée aux annonces de sécurité GitLab, et un délai de correction court pour les failles critiques.
Pour retrouver le détail d’une vulnérabilité par identifiant, la base CVE de ForenShield est disponible, et le calculateur CVSS aide à qualifier la criticité selon votre contexte.