CVE-2026-85706 GitLab : correctifs 19.1.8, 19.2.6, 19.3.2 — lecture de fichiers non authentifiée

Le 11 septembre 2026, la CISA a ajouté CVE-2026-85706 à son catalogue Known Exploited Vulnerabilities avec une échéance de remédiation à trois jours. La faille est notée CVSS 10.0 et permet à un attaquant non authentifié de lire des fichiers arbitraires sur le serveur GitLab.

Versions corrigées : 19.1.8, 19.2.6 et 19.3.2.

Ce qui rend cette CVE particulièrement grave n'est pas la technique — une traversée de chemin est un grand classique — mais ce qu'un serveur GitLab contient. Ce n'est pas un serveur applicatif parmi d'autres : c'est l'endroit où une organisation stocke simultanément son code source, ses secrets de CI/CD, ses clés de déploiement et ses jetons d'accès aux registres. Une primitive de lecture arbitraire y vaut bien plus que sur n'importe quelle autre machine.

La vulnérabilité

Description de l'éditeur :

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.

Deux défauts se cumulent, et c'est leur conjonction qui produit le 10.0 :

1. Confinement de chemin insuffisant — l'API n'empêche pas correctement de sortir du répertoire du dépôt.
2. Absence de contrôle d'authentification sur cet endpoint — la traversée est atteignable sans aucun compte.

L'une sans l'autre serait sérieuse. Ensemble, elles donnent une lecture de fichiers arbitraires accessible depuis Internet par n'importe qui.

Lire le vecteur correctement

Le S:C (scope changed) est ce qui pousse le score à 10.0 : l'impact déborde du composant vulnérable. Sur un serveur GitLab, c'est littéral — lire les fichiers du serveur donne accès à des secrets qui ouvrent des systèmes tiers.

À noter, le A:N : aucun impact sur la disponibilité. La faille ne fait pas tomber GitLab, elle ne fait rien de visible. Un serveur exploité continue de fonctionner normalement. C'est précisément ce qui rend la détection tardive.

Versions affectées et corrigées

Community Edition et Enterprise Edition sont concernées. La plage de versions affectées est large — elle remonte à la 18.7 — donc une instance qui n'a pas été mise à jour depuis plusieurs cycles est très probablement vulnérable.

Vérifier ta version :

# Instance auto-hébergée
gitlab-rake gitlab:env:info | grep "GitLab information" -A 3

# Ou depuis n'importe quel navigateur, sans authentification
curl -s https://gitlab.example.com/help | grep -i "version"

# Docker / Omnibus
docker exec <conteneur> gitlab-rake gitlab:env:info

GitLab.com n'est pas concerné — l'instance SaaS est gérée par l'éditeur. Cette CVE vise les instances auto-hébergées, qui sont précisément celles que les organisations déploient pour garder leur code chez elles.

Ce qu'un attaquant obtient

C'est là que le raisonnement doit dépasser « lecture de fichiers ». Sur un serveur GitLab, voici ce qui est lisible :

Secrets d'application

/etc/gitlab/gitlab.rb
/etc/gitlab/gitlab-secrets.json

gitlab-secrets.json contient les clés qui chiffrent les variables de CI/CD stockées en base. Un attaquant qui l'obtient, combiné à un accès base de données ou à une sauvegarde, déchiffre l'intégralité des secrets de tous les pipelines : identifiants cloud, jetons de registre, clés de signature, accès production.

Clés SSH du serveur

/etc/ssh/ssh_host_*_key
/var/opt/gitlab/.ssh/authorized_keys

Configuration base de données

/var/opt/gitlab/gitlab-rails/etc/database.yml

Code source, évidemment — y compris celui des dépôts privés, puisque la traversée s'affranchit du contrôle d'accès.

Fichiers d'environnement des runners, qui contiennent fréquemment des jetons d'enregistrement permettant d'attacher un runner malveillant au projet — et donc d'exécuter du code dans les pipelines.

Pourquoi c'est une compromission de chaîne d'approvisionnement

Un serveur GitLab compromis ne reste pas un incident GitLab. Les secrets qui s'y trouvent ouvrent l'accès aux environnements de production, aux comptes cloud et aux registres d'artefacts. Et un attaquant qui obtient la capacité de modifier un pipeline peut injecter du code dans des livrables signés — c'est le motif d'attaque de chaîne d'approvisionnement dans sa forme la plus directe.

Détection

L'exploitation ne provoque aucune erreur visible, donc il faut chercher dans les journaux d'accès.

Journaux applicatifs

# Requêtes vers l'API commits — chercher les séquences de traversée
grep -E "commits" /var/log/gitlab/gitlab-rails/production_json.log \
  | grep -E "\.\.|%2e%2e|%252e"

# Accès non authentifiés ayant renvoyé un 200 sur des endpoints de dépôt
jq 'select(.status == 200 and (.username == null or .username == "")) | {time, path, remote_ip}' \
  /var/log/gitlab/gitlab-rails/production_json.log

Les formes d'encodage à surveiller : ../, %2e%2e%2f, %252e%252e%252f (double encodage), et les variantes avec des séparateurs Windows.

Journaux nginx

grep -E "%2e|\.\./" /var/log/gitlab/nginx/gitlab_access.log

Indices post-exploitation

Ces signaux sont plus fiables que la détection de l'exploitation elle-même :

• Nouveaux jetons d'accès personnels ou jetons de projet non corrélés à une demande
• Runners enregistrés que personne ne reconnaît : Admin → CI/CD → Runners
• Clés SSH ou clés de déploiement ajoutées sur des comptes ou des projets
• Connexions réussies depuis des adresses inhabituelles, en particulier sur des comptes de service
• Modifications de pipeline (.gitlab-ci.yml) hors des flux de revue habituels
• Trafic sortant du serveur GitLab vers des destinations non liées à ses miroirs et registres déclarés

Mitigation

1. Mettre à jour — c'est urgent, pas planifiable

# Omnibus (Debian/Ubuntu)
apt-get update && apt-get install gitlab-ce   # ou gitlab-ee

# Vérifier après redémarrage
gitlab-rake gitlab:env:info | head -20

Vu l'échéance CISA à trois jours et l'exploitation confirmée, cela ne relève pas de la fenêtre de maintenance mensuelle.

2. Si la mise à jour ne peut pas être immédiate

Retire l'exposition Internet. La faille étant non authentifiée, couper l'accès public est une mitigation réelle, pas un palliatif cosmétique : elle ramène la population d'attaquants au réseau interne.

# nginx en amont — restreindre l'API aux réseaux de confiance
location /api/ {
    allow 10.0.0.0/8;
    deny  all;
}

Teste avant d'appliquer : couper /api/ casse les runners et les intégrations.

3. Si tu conclus à une compromission

L'ordre compte ici, parce que les secrets lisibles ouvrent des systèmes tiers.

1. Fais tourner les secrets applicatifs — régénère gitlab-secrets.json en suivant la procédure de l'éditeur (attention : cela invalide les variables CI/CD chiffrées, qui devront être resaisies)
2. Révoque tous les jetons : jetons d'accès personnels, jetons de projet et de groupe, jetons d'enregistrement de runner
3. Fais tourner les secrets exposés dans les pipelines — identifiants cloud, clés de registre, clés de signature. C'est le point le plus important : ce sont eux qui donnent accès à autre chose que GitLab
4. Audite les runners enregistrés et supprime ceux qui ne correspondent à rien
5. Vérifie l'intégrité des dépôts : compare les empreintes des commits récents sur les branches protégées avec les clones locaux de l'équipe
6. Remplace les clés SSH hôtes du serveur

Ne considère pas la mise à jour comme suffisante : elle ferme la porte, elle ne révoque pas ce qui est déjà sorti.

Pourquoi surveiller en continu vos outils de développement

GitLab, Jenkins, Artifactory, les registres de conteneurs : cette catégorie d'outils est mal couverte par les inventaires de vulnérabilités parce qu'elle est gérée par les équipes de développement plutôt que par la DSI, et qu'elle ne figure pas dans les scans de parc classiques. Or c'est précisément la catégorie où une lecture de fichiers se transforme en accès production.

Avec cveo.tech, inventorie tes outils de développement et d'intégration continue avec leur version exacte, et reçois une alerte automatique dès qu'une CVE critique en concerne une — pour que trois jours d'échéance CISA soient trois jours d'action, pas trois jours d'ignorance.