Ce qu'il s’est passé
Le 10 septembre 2026, GitLab a publié une mise à jour de sécurité critique corrigeant CVE-2026-85706, une vulnérabilité affectant l’API des commits de dépôts.
Le défaut combine :
- un confinement incorrect des chemins ;
- une absence de contrôle d’authentification dans certaines conditions ;
- la possibilité, pour un attaquant distant non authentifié, de lire des fichiers arbitraires présents sur le serveur GitLab.
GitLab a attribué à cette vulnérabilité un score CVSS de 10,0.
Une entrée KEV en moins de 24 heures
Le 11 septembre, soit le lendemain de la publication des correctifs, la CISA a ajouté CVE-2026-85706 à son catalogue Known Exploited Vulnerabilities (KEV).
La date limite de remédiation fixée pour les agences fédérales américaines est le 14 septembre 2026. La fiche KEV indique également qu’un forensic triage est requis dans le cadre de la BOD 26-04.
Cette séquence est importante : le risque n’est pas seulement théorique ou déduit du score CVSS. Des observations de terrain ont été rapportées très rapidement après la publication du correctif.
Des tentatives d'exploitation ont été observées dès le 11 septembre à 06:00 UTC. Cela suggère que des attaquants avaient déjà reproduit le mécanisme d’exploitation.
Pourquoi cette vulnérabilité est-elle critique pour les équipes DevOps et SOC ?
CVE-2026-85706 n’est pas une simple vulnérabilité de lecture dans un composant isolé. GitLab est souvent situé au centre de la chaîne de livraison logicielle et dispose d’un accès privilégié à de nombreux systèmes.
Des fichiers potentiellement très sensibles
Une lecture arbitraire peut exposer, selon la configuration et les permissions du processus GitLab :
- des fichiers .env susceptibles de contenir des secrets ;
- des clés SSH ;
- des tokens de déploiement ;
- des variables ou secrets CI/CD ;
- des informations utiles à une compromission ultérieure, notamment via la compromission du code source.
La vulnérabilité est décrite comme une lecture de fichiers arbitraires, et non comme une exécution de code à distance directe. Elle ne transforme donc pas automatiquement l’instance en ver informatique. Mais les secrets récupérés peuvent permettre d’atteindre les runners, les dépôts, les environnements cloud ou les systèmes de production.
Pourquoi les instances self-managed ?
Le périmètre prioritaire concerne les instances GitLab CE/EE self-managed, notamment lorsqu’elles sont accessibles depuis Internet.
À distinguer :
- GitLab.com : déjà corrigé selon GitLab, aucune action client spécifique n’est attendue ;
- GitLab Dedicated : GitLab indique également qu’aucune action n’est requise de la part des clients ;
- GitLab CE/EE self-managed : vérification de version et correction immédiates requis.
Une organisation peut donc avoir corrigé ses postes et ses scanners tout en laissant exposée une instance GitLab interne devenue accessible depuis Internet, un endpoint d’administration, un VPN ou un proxy mal configuré.
Une fenêtre d’exploitation particulièrement courte
Le calendrier rappelle un schéma désormais classique :
- publication d’un correctif fournisseur ;
- analyse rapide du patch ;
- reproduction de la vulnérabilité ;
- sondes sur Internet ;
- exploitation opportuniste.
Le délai observé ici — environ une journée — doit inciter les équipes à traiter les correctifs critiques de produits exposés comme des événements opérationnels, avec mobilisation du SOC et de la plateforme.
Quelles sont les versions affectées et quels correctifs appliquer ?
La CVE-2026-85706 est corrigée avec les releases de GitLab CE et EE suivantes :
- Branche 19.1 : corrigée dans 19.1.8 ;
- Branche 19.2 : corrigée dans 19.2.6 ;
- Branche 19.3 : corrigée dans 19.3.2.
La plage affectée commence avec GitLab 18.7. Les versions 18.7.x jusqu’aux versions non corrigées de la branche 19.3 sont donc à traiter selon leur situation de support et leur chemin de mise à niveau.
Une autre vulnérabilité importante dans la même release
La même mise à jour corrige également CVE-2026-87719, une vulnérabilité EE de désérialisation GraphQL évaluée à CVSS 9,9.
Elle n’est pas, à ce stade, connue pour être activement exploitée. Elle constitue néanmoins un argument supplémentaire pour appliquer la release complète plutôt que chercher un correctif partiel.
Que faire concrètement ?
1. Inventorier les instances GitLab
Commencez par identifier :
- toutes les instances GitLab CE/EE déployées dans votre système d'information;
- leur édition et leur version exacte ;
- leur exposition Internet ;
- les reverse proxies et WAF placés devant elles ;
- les runners associés ;
- les environnements accessibles via les pipelines ;
- les comptes de service et secrets présents sur l’instance.
Ne vous limitez pas à l’inventaire cloud ou aux actifs officiellement déclarés. Les instances de test, de développement ou acquises par une équipe peuvent contenir des secrets réutilisables en production.
2. Corriger immédiatement
Priorisez les instances :
- accessibles depuis Internet ;
- utilisées pour les pipelines de production ;
- hébergeant des dépôts sensibles ;
- disposant de runners privilégiés ;
- contenant des intégrations cloud, registry ou déploiement.
Si le correctif ne peut pas être appliqué immédiatement, limitez temporairement l’accès réseau à l’instance. Cette mesure ne remplace pas la mise à niveau, mais peut réduire la fenêtre d’exposition.
3. Rechercher les tentatives d’exploitation
Le correctif ne permet pas de déterminer si l’instance a été consultée avant la mise à jour. Il faut donc examiner les journaux disponibles, notamment :
- logs du reverse proxy ;
- logs GitLab Rails et NGINX ;
- journaux WAF ;
- logs d’authentification ;
- logs réseau ;
- journaux d’accès aux endpoints API.
Recherchez des requêtes HTTP POST vers des URI de type :
/api/v4/projects/{id}/repository/commits/
avec des paramètres liés à :
file.path
Les éléments à corréler comprennent :
- requêtes non authentifiées ;
- chemins anormaux ou tentatives de sortie du répertoire attendu ;
- répétition de requêtes sur plusieurs projets ;
- réponses inhabituelles ou volumineuses ;
- accès survenus entre la publication de l’exploitabilité et le patch ;
- récupération ultérieure de secrets ou utilisation de tokens.
L’absence de traces ne prouve pas l’absence d’exploitation, particulièrement si la rétention des logs est courte ou si un proxy a supprimé certains paramètres.
4. Faire un triage forensique
Si une instance vulnérable était exposée ou si des attaques sont détectées :
- conservez les journaux avant rotation ;
- exportez les événements pertinents ;
- préservez les métadonnées de l’instance ;
- comparez les fichiers sensibles avec une référence connue ;
- recherchez les nouveaux comptes, clés ou tokens ;
- examinez l’activité des runners ;
- vérifiez les jobs CI/CD lancés après l’exposition ;
- contrôlez les connexions sortantes inhabituelles ;
- documentez la chronologie : exposition, sondes, patch, rotation.
Il est important de mener cette analyse forensique afin de déterminer si une exploitation a eu lieu et de générer de nouveaux secrets si une exploitation réussie est détectée. Tout particulièrement si l'instance n'a pas été corrigée au terme de la première journée de publication.
5. Faire tourner les secrets potentiellement exposés
Si une compromission est plausible, faites tourner les secrets susceptibles d’avoir été lus :
- clés SSH ;
- jetons GitLab ;
- jetons de déploiement ;
- variables CI/CD ;
- secrets cloud ;
- certificats et clés privées ;
- identifiants utilisés par les runners.
La rotation doit être accompagnée d’une recherche d’utilisation abusive : un secret volé peut rester exploitable après le patch.
Pourquoi prioriser cette vulnérabilité?
La CVE-2026-85706 cumule plusieurs signaux forts :
- accès possible depuis Internet ;
- absence de prérequis concernant les privilèges ;
- faible complexité ;
- lecture de fichiers sensibles ;
- produit central dans la chaîne DevOps ;
- observations de tentatives in-the-wild ;
- ajout au catalogue CISA KEV ;
- échéance de remédiation immédiate ;
- nécessité d’un triage forensique.
C’est précisément le type de cas où la priorisation doit combiner CVE, KEV, exposition des actifs et télémétrie réelle.
Conclusion
CVE-2026-85706 doit être traitée en urgence en considérant à la fois l'application du correctif et la détection de tentatives d'exploitation pour toute organisation opérant GitLab CE/EE en self-managed.
La priorité est claire :
- identifier les instances concernées ;
- confirmer leur exposition ;
- appliquer 19.1.8, 19.2.6 ou 19.3.2 ;
- rechercher les requêtes suspectes sur l’API commits ;
- effectuer un triage forensique si l’exposition est avérée ;
- faire tourner les secrets en cas de compromission possible.
L’entrée dans le KEV et l’échéance du 14 septembre 2026 rappellent surtout une réalité opérationnelle : le score CVSS ne suffit plus pour décider. La vitesse d’exploitation, la criticité de GitLab dans la chaîne CI/CD et la présence de signaux in-the-wild doivent guider la réponse.