GitLab CVE-2026-85706 : lecture de fichiers CVSS 10

Qu'est-ce que CVE-2026-85706 ?

C'est une traversée de chemin dans l'API des commits (/api/v4/projects/{id}/repository/commits/). GitLab décrit un « confinement de chemin impropre » et une « application de l'authentification manquante ». Le résultat est une lecture de fichiers arbitraires sans compte. La faille donne un accès aux fichiers et non une exécution de code directe : ce sont les secrets contenus dans ces fichiers qui ouvrent la suite.

Selon watchTowr, la seule condition est qu'au moins un projet public existe sur l'instance. C'est le cas de la plupart des instances auto-hébergées qui publient de la documentation, un miroir ou un projet open source. Le signalement vient du chercheur s3ntago via HackerOne.

Quelles versions sont concernées ?

GitLab CE et EE de la version 18.7 à 19.1.7, de 19.2.0 à 19.2.5 et de 19.3.0 à 19.3.1. Les correctifs sont les versions 19.1.8, 19.2.6 et 19.3.2. Il n'existe pas de correctif pour les branches 18.x et 19.0 : il faut passer à 19.1.8 au minimum. GitLab ne propose pas de contournement. GitLab.com est déjà corrigé et les clients GitLab Dedicated n'ont rien à faire. La même livraison corrige aussi CVE-2026-87719 (CVSS 9,9, désérialisation dans GitLab EE : un utilisateur authentifié ayant accès à Duo Chat peut obtenir des configurations de recherche avancée et des identifiants via un argument de souscription GraphQL forgé).

Comment est-elle exploitée ?

Les attaquants ciblent les fichiers de configuration et les journaux, qui contiennent des clés d'application, des identifiants de base de données, des jetons d'intégration et des fragments de sessions. watchTowr a vu des sondes dès 06h00 UTC le 11 septembre, soit un jour après la publication des correctifs, puis des extractions de fichiers de configuration et de configurations SSH système. Un code d'exploitation public existe. Un second épisode critique après l'injection GraphQL CVE-2026-19478 : le délai entre divulgation et exploitation se compte en heures.

Comment détecter une exploitation ?

La réponse courte : cherchez des requêtes POST vers l'API des commits contenant un paramètre file.Path.

• Dans les journaux HTTP et ceux de GitLab, recherchez POST /api/v4/projects/{id}/repository/commits/ avec file.Path contenant des chemins absolus ou des séquences de remontée de répertoires.
• Toute occurrence avant l'installation du correctif doit être traitée comme une fuite potentielle de secrets.
• Surveillez les accès inhabituels aux ressources que ces secrets protègent : base de données, registre de conteneurs, intégrations CI, dépôts d'artefacts.

Comment corriger et contenir ?

1. Mettre à jour vers 19.1.8, 19.2.6 ou 19.3.2.
2. Faire tourner les secrets lisibles : le correctif empêche de nouvelles lectures, il ne reprend pas ce qui a déjà été copié. Concernés : secrets d'application, identifiants de base, jetons d'intégration, variables CI exposées, clés SSH.
3. Réduire l'exposition : une instance auto-hébergée n'a pas à être accessible depuis Internet sans besoin métier. Placez-la derrière un VPN ou une passerelle d'administration.
4. Réduire la valeur des fichiers lisibles : secrets de pipeline dans un gestionnaire externe, journaux sans identifiants, rotation régulière des jetons d'instance.
5. Appliquer aussi le correctif de CVE-2026-87719 si vous utilisez GitLab EE.

Notre article sur les secrets oubliés dans l'historique Git détaille la chasse aux clés exposées dans les dépôts.

Qu'est-ce qui change quand un agent IA a accès à GitLab ?

Un agent IA qui lit ou écrit dans GitLab dispose de jetons dont la fuite donne les mêmes droits que ses outils, et son contexte contient du contenu venu du dépôt. Quatre conséquences.

Les jetons de l'agent sont des cibles de choix. Les agents de revue de code, de tri de tickets ou de génération de correctifs utilisent des jetons d'accès personnels ou de projet, parfois avec des droits d'écriture et de déclenchement de pipelines. Une lecture de configuration ou de variables CI les expose. Notre article sur la clé d'API exposée à tous les reporters dans le GitLab AI Gateway illustre ce risque.

Le contenu du dépôt est une entrée non fiable. Une description de merge request, un commentaire ou un fichier peut contenir des instructions que l'agent lit comme consigne. C'est l'injection de prompt indirecte (page dédiée). Associée à des droits d'écriture, elle peut modifier du code, un pipeline ou des variables.

L'agent amplifie un accès en lecture. Avec un jeton volé, un attaquant peut demander à un agent compromis de parcourir des centaines de projets et de résumer les secrets qu'il trouve, plus vite qu'un humain.

L'automatisation transforme l'erreur en incident. Un agent autorisé à fusionner ou à déployer sans validation propage un changement malveillant dans le pipeline.

Mesures utiles : jetons à portée minimale et à courte durée, lecture seule par défaut, pas de secrets dans les variables accessibles à l'agent, validation humaine avant fusion ou déploiement, et journalisation de chaque appel d'outil. Cela correspond à LLM06 (Excessive Agency) du Top 10 OWASP pour les applications LLM. Voir aussi notre page sur la sécurité des agents IA.

Comment tester votre exposition ?

Inventoriez les instances GitLab joignables, les jetons détenus par vos agents et les droits associés. Notre Red Team Agent Express (1 900 €, 5 jours) attaque un agent réel avec ses outils et ses identifiants, y compris l'accès à un dépôt de code, et livre un rapport avec preuves reproductibles.