Faille GitLab - CVE-2026-85706 - des fichiers du serveur accessibles sans authentification

La faille GitLab CVE-2026-85706 permet, sous certaines conditions, à un attaquant non authentifié de lire des fichiers arbitraires sur le serveur d’une instance GitLab. Cette faille GitLab, située dans l’API des commits, est classée critique avec un score CVSS 3.1 de 10 sur 10.

Les éditions GitLab Community Edition et Enterprise Edition sont concernées. GitLab recommande de mettre immédiatement à jour les installations auto-hébergées vers 19.1.8, 19.2.6 ou 19.3.2 selon leur branche.

L’enjeu dépasse largement la consultation du code source. Une forge auto-hébergée peut concentrer des configurations de déploiement, des jetons CI/CD, des secrets techniques, des clés d’accès et les informations nécessaires pour atteindre d’autres composants de l’infrastructure. La priorité consiste donc à corriger l’instance, puis à déterminer si des fichiers sensibles ont pu être exposés.

Une traversée de chemin dans l’API des commits

GitLab décrit CVE-2026-85706 comme un défaut de confinement des chemins associé à une absence de contrôle d’authentification dans l’API des commits des dépôts.

Une application doit normalement limiter strictement les chemins qu’une requête peut consulter. Une traversée de chemin apparaît lorsqu’une valeur fournie par le client permet de sortir du répertoire attendu et d’atteindre un autre emplacement du système de fichiers.

Dans ce cas, la requête arrive par une API GitLab légitime, mais son traitement peut conduire à lire un fichier situé en dehors du dépôt visé. Le bulletin précise que l’attaquant peut agir sans compte GitLab et sans interaction d’un utilisateur.

Le vecteur CVSS publié par GitLab confirme plusieurs caractéristiques importantes:

• l’attaque est réalisable à distance par le réseau;
• sa complexité est annoncée comme faible;
• aucun privilège préalable n’est nécessaire;
• aucune action d’une victime n’est requise;
• l’impact sur la confidentialité est élevé.

Nous ne reproduisons pas ici de charge utile ni de procédure d’exploitation. Une instance exposée à Internet doit être considérée comme prioritaire dès lors que sa version appartient aux plages vulnérables.

Quelles versions de GitLab sont vulnérables

GitLab déclare affectées les éditions CE et EE dans les plages suivantes:

• toutes les versions à partir de GitLab 18.7 et antérieures à 19.1.8;
• GitLab 19.2 avant 19.2.6;
• GitLab 19.3 avant 19.3.2.

Les versions corrigées sont:

• GitLab 19.1.8;
• GitLab 19.2.6;
• GitLab 19.3.2.

Le bulletin concerne tous les modes de déploiement lorsque GitLab n’en exclut aucun. Il faut donc vérifier les installations par paquet Linux, Docker, Helm ou code source, ainsi que les environnements de recette et de secours parfois oubliés des inventaires.

GitLab.com utilise déjà une version corrigée. Les clients GitLab Dedicated n’ont pas d’action à entreprendre selon l’éditeur. La responsabilité de la mise à jour revient en revanche aux exploitants des instances auto-hébergées.

Pourquoi une lecture de fichiers arbitraires est critique sur GitLab

Une forge logicielle n’héberge pas uniquement des dépôts. Elle se trouve souvent au centre de la chaîne de livraison et possède des relations de confiance avec les autres systèmes.

Selon l’architecture et les permissions du processus GitLab, les fichiers accessibles sur un serveur peuvent révéler:

• des paramètres internes de l’instance;
• des secrets utilisés pour chiffrer ou signer certaines données;
• des identifiants de bases de données ou de services externes;
• des jetons et variables nécessaires aux pipelines;
• la configuration des stockages, registres et environnements;
• des informations facilitant une attaque ultérieure contre l’infrastructure.

La vulnérabilité ne signifie pas que chaque secret de chaque installation a nécessairement été lu. L’étendue réelle dépend des fichiers présents, des permissions, du déploiement et d’une éventuelle exploitation. Elle interdit cependant de résumer l’incident à une simple fuite de code.

Nous présentons déjà GitLab comme un moyen de maîtriser une chaîne CI/CD en cloud privé. Cette maîtrise implique aussi d’assurer les mises à jour, la supervision, la sauvegarde et la réponse aux incidents de la forge elle-même.

Le bulletin corrige deux autres vulnérabilités majeures

Le même correctif traite dix-sept autres vulnérabilités. Deux d’entre elles méritent une attention particulière lors de la qualification d’une instance GitLab Enterprise Edition.

CVE-2026-87719 - exposition de secrets avec Duo Chat

CVE-2026-87719 est notée 9,9 sur 10. Elle concerne GitLab EE avec un accès à Duo Chat.

Sous certaines conditions, un utilisateur authentifié pouvait fournir un argument GraphQL spécialement construit afin de contourner le mécanisme de sérialisation. L’exploitation pouvait révéler des configurations d’Advanced Search et des identifiants sensibles.

Les versions GitLab EE à partir de 18.3 sont indiquées comme affectées jusqu’aux mêmes versions correctives.

CVE-2026-88765 - exécution de code lors d’un import

CVE-2026-88765, notée 8,5 sur 10, touche également GitLab EE. Un utilisateur authentifié pouvait importer un projet spécialement préparé afin de provoquer un débordement de tampon dans le composant de conversion Unicode utilisé par l’indexation Advanced Search.

Une exploitation réussie pouvait conduire à une exécution de code à distance. Les versions affectées commencent à GitLab EE 12.3 et restent vulnérables jusqu’aux versions 19.1.8, 19.2.6 et 19.3.2.

Il faut bien distinguer ces scénarios: CVE-2026-85706 permet une lecture de fichiers sans authentification, tandis que l’exécution de code documentée dans ce bulletin correspond à CVE-2026-88765 et exige un utilisateur authentifié ainsi qu’un environnement GitLab EE utilisant les fonctions concernées.

Comment vérifier la version réellement exécutée

L’inventaire doit porter sur le service actif, pas seulement sur une version déclarée dans un dépôt d’infrastructure.

Sur une installation GitLab Linux Package, les informations d’environnement peuvent être obtenues avec:

sudo gitlab-rake gitlab:env:info

Pour un déploiement Docker dont le conteneur se nomme gitlab:

docker exec gitlab gitlab-rake gitlab:env:info

Il faut également relever l’image réellement exécutée:

docker inspect --format '{{.Config.Image}}' gitlab

La valeur présente dans un fichier Compose n’est pas une preuve suffisante si l’image n’a pas été téléchargée et le conteneur recréé. De la même manière, une image portant un tag générique comme latest complique la traçabilité et le retour arrière.

L’inventaire doit inclure:

• l’instance de production;
• les nœuds secondaires et sites de reprise;
• les environnements de recette accessibles;
• les anciennes instances encore joignables;
• les images ou modèles de machines susceptibles d’être redéployés;
• les nœuds Rails, Sidekiq et Gitaly d’une architecture distribuée.

Mettre à jour sans transformer le correctif en panne

L’urgence du correctif ne dispense pas de préparer son déploiement. GitLab précise que ces versions contiennent des migrations de base de données.

Pour une instance à nœud unique, la mise à jour entraîne une interruption pendant l’exécution des migrations et le redémarrage de GitLab. Une architecture multinœud peut suivre la procédure de mise à jour sans interruption prévue par l’éditeur, à condition de respecter l’ordre des composants et les prérequis de version.

Une intervention maîtrisée doit au minimum comprendre:

1. Confirmer la version et le mode d’installation
   Vérifier l’édition, la branche, les composants distribués et les fonctionnalités comme Advanced Search ou Duo Chat.

2. Contrôler le chemin de mise à niveau
   Une instance ancienne ne doit pas sauter arbitrairement jusqu’à la dernière version. Les arrêts obligatoires indiqués par GitLab doivent être respectés.

3. Sauvegarder avant le changement
   La sauvegarde doit couvrir les données GitLab, mais aussi les fichiers de configuration et les secrets nécessaires à une restauration complète.

4. Définir l’interruption ou la procédure sans coupure
   Informer les utilisateurs, suspendre si nécessaire les opérations sensibles et vérifier la disponibilité d’un retour arrière cohérent.

5. Appliquer la version corrigée
   Utiliser la procédure correspondant au type de déploiement réel, sans remplacer une image ou un paquet à l’aveugle.

6. Attendre la fin des migrations
   Contrôler les migrations de base, les tâches post-déploiement et l’état de Sidekiq avant de conclure que la mise à jour est terminée.

7. Tester le service rendu
   Vérifier les connexions, les opérations Git, les merge requests, le registre, les runners, les webhooks et au moins un pipeline représentatif.

Cette méthode rejoint notre approche de la maintenance de serveurs sans interruption: le correctif est une modification de production qui doit être suivie jusqu’à la validation fonctionnelle.

Une sauvegarde GitLab doit pouvoir être restaurée

Une sauvegarde applicative GitLab ne suffit pas toujours à reconstruire l’instance. La configuration et les secrets sont indispensables pour relire certaines données chiffrées et retrouver le comportement du service.

Avant la mise à jour, il faut donc vérifier:

• la date et le statut de la dernière sauvegarde;
• la présence des dépôts, uploads, artefacts, registres et données applicatives nécessaires;
• la sauvegarde séparée de la configuration;
• la conservation sécurisée des secrets de l’instance;
• la compatibilité entre la sauvegarde et la version cible de restauration;
• l’existence d’un test de restauration récent.

Dans le contexte de CVE-2026-85706, ces fichiers sensibles doivent être protégés et sauvegardés, mais aussi considérés dans l’analyse d’exposition. La reprise d’une plateforme avec les mêmes secrets potentiellement compromis ne clôt pas un incident.

Que rechercher après la mise à jour

Le bulletin GitLab ne publie pas d’indicateur de compromission propre à CVE-2026-85706. L’absence d’une alerte explicite ne permet donc pas de conclure qu’une instance n’a pas été ciblée.

Une analyse proportionnée peut rechercher:

• des appels inhabituels vers l’API des commits;
• des chemins encodés ou anormalement construits dans les paramètres de requête;
• un volume soudain de réponses sur des projets rarement consultés;
• des requêtes provenant de sources nouvelles vers plusieurs projets;
• des erreurs ou traces liées à la résolution de chemins;
• une activité ultérieure utilisant des secrets ou comptes techniques associés à GitLab.

Les journaux du reverse proxy, de GitLab Workhorse, de Rails et des équipements de sécurité doivent être rapprochés sur la période précédant le correctif. Ces signaux restent des pistes d’investigation, pas une preuve automatique d’exploitation.

Si l’analyse fait apparaître une requête suspecte ou si la journalisation ne permet pas d’écarter raisonnablement une exposition, la réponse doit envisager:

• la rotation des secrets de l’instance GitLab;
• la rotation des identifiants de bases de données et stockages accessibles;
• le renouvellement des jetons CI/CD et clés de déploiement concernés;
• la revue des accès aux registres, clusters et environnements de production;
• la recherche d’actions anormales dans les pipelines et les comptes administrateurs.

La rotation doit être organisée pour éviter de casser simultanément les runners et les déploiements. Elle doit aussi être suivie jusqu’à la révocation effective des anciens secrets.

Les actions à engager maintenant

Pour traiter la faille GitLab CVE-2026-85706:

1. inventorier toutes les instances GitLab auto-hébergées;
2. identifier leur édition, leur version et leur mode de déploiement;
3. isoler temporairement les instances vulnérables qui ne peuvent pas être corrigées immédiatement;
4. préparer une sauvegarde complète et vérifier le chemin de mise à niveau;
5. installer GitLab 19.1.8, 19.2.6, 19.3.2 ou une version ultérieure maintenue;
6. suivre les migrations et valider les fonctions Git, CI/CD et registre;
7. analyser les journaux disponibles sur la période d’exposition;
8. révoquer les secrets potentiellement accessibles si un doute sérieux subsiste;
9. documenter la version, les contrôles réalisés et la date de clôture.

La détection quotidienne des bulletins n’a de valeur que si elle débouche sur une qualification et une action. Nous détaillons ce processus dans notre article sur le suivi des CVE intégré à l’exploitation.

Conclusion

La faille GitLab CVE-2026-85706 atteint une brique centrale de nombreuses chaînes de livraison. Son exploitation ne nécessite ni compte ni interaction et peut exposer des fichiers arbitraires du serveur par l’intermédiaire de l’API des commits.

Les versions GitLab 19.1.8, 19.2.6 et 19.3.2 corrigent la vulnérabilité. La mise à jour doit être prioritaire, tout en tenant compte des migrations, de l’interruption annoncée sur les installations à nœud unique et du chemin de montée de version des instances plus anciennes.

Le travail ne s’arrête pas lorsque l’interface GitLab répond de nouveau. Il faut valider les dépôts, les runners, les registres et les pipelines, puis rechercher une éventuelle exposition de secrets. Une forge auto-hébergée redonne de l’autonomie, mais elle exige une maintenance aussi rigoureuse que les systèmes auxquels elle donne accès.

Si vous avez besoin d’aide pour qualifier une instance, organiser une mise à jour urgente ou analyser son exposition, nous pouvons intervenir dans le cadre de notre offre d’infogérance de serveurs Linux.

• Découvrir notre approche du CI/CD avec GitLab en cloud privé
• Découvrir notre offre d’infogérance
• Nous contacter

Sources

• GitLab - correctif critique 19.3.2, 19.2.6 et 19.1.8
• GitLab - documentation de mise à jour
• GitLab - chemins de mise à niveau obligatoires
• GitLab - procédure de mise à jour sans interruption
• GitLab - sauvegarder une instance Linux Package