GitLab CVE-2026-85706 : pourquoi une faille critique menace toute la chaîne CI/CD

Faits, analyse et incertitudes

L'essentiel de la vulnérabilité

Ce qu'est une traversée de répertoire, et ce qu'elle vaut ici

Une traversée de répertoire survient lorsqu'une application construit un chemin de fichier à partir d'une donnée fournie par l'utilisateur sans vérifier que le chemin obtenu reste bien à l'intérieur du répertoire prévu. L'application croit servir un fichier d'un dépôt ; elle sert en réalité un fichier du système.

Prise isolément, cette classe de vulnérabilité est banale et généralement notée moyenne : elle expose des fichiers, sans donner de contrôle. Ce qui change tout ici, ce sont deux éléments cumulés. D'abord l'absence d'authentification : n'importe qui, depuis le réseau, peut formuler la requête. Ensuite la nature du serveur visé.

Ce que contient un serveur GitLab

• Le code source de l'organisation, y compris les dépôts privés et l'historique complet
• Les fichiers de configuration des pipelines, qui décrivent la façon dont les artefacts sont construits et déployés
• Des variables d'intégration continue, dont des identifiants de services tiers, des clés d'accès à des environnements cloud et des jetons de registre
• Des clés de déploiement et des jetons d'accès personnels ou de groupe
• L'état des exécuteurs (runners) et les jetons qui leur permettent de s'enregistrer
• Des registres de paquets et d'images de conteneurs
• Du code d'infrastructure, qui décrit l'infrastructure réelle et parfois les moyens d'y accéder

Rapid7 souligne que les fichiers exposés peuvent contenir des identifiants, des jetons, des clés de déploiement, de la configuration CI/CD ou des secrets de base de données susceptibles d'alimenter des attaques ultérieures. La vulnérabilité ne donne pas la main sur la machine : elle donne de quoi obtenir la main ailleurs.

Si mon GitLab a été vulnérable, dois-je seulement installer le correctif ?

Non, et c'est le point le plus important de ce dossier. Le correctif et l'investigation répondent à deux questions différentes. Le correctif répond à « est-ce que cela peut encore arriver ? ». L'investigation répond à « est-ce que cela est arrivé, et qu'est-ce qui est sorti ? ». Installer le premier sans conduire la seconde revient à fermer une porte sans savoir si quelqu'un est passé.

Rechercher des traces d'exploitation

Les journaux d'accès HTTP du serveur, ceux du reverse proxy placé devant et ceux de l'application sont les seules sources qui permettent de répondre. La période à couvrir démarre non pas à la publication du correctif mais à la première version affectée réellement installée sur l'instance. Sur une instance restée en 19.1.x pendant plusieurs mois, cette période peut être longue.

Faire tourner les secrets, dans le bon ordre

La rotation est l'opération qui rend sans valeur ce qui a pu être lu. Elle est désagréable parce qu'elle casse des automatismes : c'est le prix, et c'est aussi la seule mesure qui agit sur le passé. L'ordre compte, parce qu'une rotation partielle laisse à l'attaquant le moyen de récupérer ce qui a été régénéré.

1. D'abord les jetons d'accès au serveur lui-même

   Jetons personnels, jetons de groupe et de projet, jetons d'impersonation. Ce sont eux qui permettraient de reconstituer un accès après la mise à jour.

2. Ensuite les secrets des pipelines

   Variables d'intégration continue, clés d'accès aux environnements cloud, identifiants de registres, jetons de services tiers utilisés par les chaînes de construction.

3. Puis les clés de déploiement et les clés SSH

   Y compris celles enregistrées sur des serveurs cibles, qui survivent silencieusement à la rotation côté GitLab.

4. Enfin les jetons d'enregistrement des exécuteurs

   Un exécuteur est une machine qui exécute du code sur demande du serveur. Un exécuteur pirate est un point de persistance discret, et il se déclare lui-même légitime.

5. Vérifier l'intégrité des artefacts publiés

   Comparer les artefacts et les images produits pendant la période d'exposition avec ce que les définitions de pipelines auraient dû produire.

Réduire durablement le risque

• Traiter GitLab comme un actif critique

  Au même niveau qu'un contrôleur de domaine ou qu'un coffre-fort de secrets. Cela implique une fenêtre de mise à jour d'urgence documentée, et un décideur identifié capable de l'ouvrir en quelques heures.

• Ne pas exposer l'interface sans nécessité

  Une instance accessible depuis Internet est exploitable depuis Internet. Un accès restreint aux réseaux de l'organisation et à un VPN ne supprime pas la vulnérabilité, mais divise le nombre d'attaquants potentiels par plusieurs ordres de grandeur.

• Réduire la valeur de ce qui est stocké

  Des secrets à durée de vie courte, délivrés à la demande par un coffre-fort dédié plutôt que stockés en variables permanentes, rendent une lecture de fichiers beaucoup moins rentable.

• Préparer la rotation avant d'en avoir besoin

  Une rotation improvisée prend des jours et casse la production. Une procédure écrite, avec un inventaire des secrets et de leurs consommateurs, la ramène à quelques heures.

• Isoler les exécuteurs

  Un exécuteur partagé entre des projets de sensibilités différentes propage toute compromission. La séparation par environnement coûte des ressources et évite un effet domino.

• Journaliser hors de l'instance

  Les journaux HTTP et applicatifs doivent être centralisés ailleurs, avec une rétention suffisante pour couvrir une période d'exposition de plusieurs mois. C'est ce qui rend l'investigation possible.