GitLab corrige une faille CVSS 10 de lecture de fichiers, exploitée sous 24 heures

11 septembre 2026. GitLab publie une mise à jour de sécurité hors cycle pour corriger CVE-2026-85706, une traversée de chemin notée CVSS 10.0 dans l’API des commits du dépôt. La faille permet à un attaquant non authentifié de lire n’importe quel fichier du serveur GitLab en une seule requête HTTP — y compris les clés de chiffrement de la base. Moins de 24 heures plus tard, la société de gestion de surface d’attaque WatchTowr observe des sondes en conditions réelles.

L’enjeu est à la hauteur de la note : GitLab déclare plus de 30 millions d’utilisateurs enregistrés et équipe plus de la moitié du Fortune 100, dont Nvidia, Airbus et Goldman Sachs. Une faille de lecture arbitraire sur cette base installée, c’est un risque de chaîne d’approvisionnement potentiel pour le logiciel que ces organisations construisent et livrent.

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

La vulnérabilité a été signalée par un chercheur du programme de bug bounty HackerOne de GitLab, sous le pseudonyme s3ntago. Elle se loge dans l’API des commits, l’endpoint que les pipelines CI/CD, les scripts d’automatisation et les intégrations tierces utilisent pour interagir avec les données de contrôle de version.

Le fonctionnement normal : quand un appel arrive pour récupérer des données de commit ou des diffs de fichiers, le backend Ruby on Rails transmet le chemin demandé à Gitaly, le wrapper RPC maison autour de Git. Les routines d’assainissement sont censées confiner ce chemin à l’arborescence du dépôt. Dans les versions affectées, l’API des commits ne neutralise pas les séquences de traversée comme ../ ou leurs variantes encodées en URL. Selon l’avis de sécurité de GitLab, la faille combine une restriction de chemin incorrecte et une application d’authentification manquante — sous certaines conditions non documentées, le contrôle d’accès est contourné, si bien qu’aucun identifiant, jeton privé ni interaction préalable n’est nécessaire.

De la lecture de fichiers à la prise de contrôle

Lire des fichiers arbitraires sur un serveur GitLab auto-hébergé n’est pas un simple vol de données : c’est le premier pas vers une compromission complète. Les cibles logiques sont /etc/passwd, mais surtout secrets.yml et gitlab.rb — les fichiers qui contiennent les clés de chiffrement des colonnes de base et des cookies de session, ainsi que les identifiants de la base PostgreSQL.

Une fois secrets.yml exfiltré, l’attaquant accède directement à la base, s’octroie les droits d’administrateur, puis injecte du code malveillant dans les pipelines CI/CD — le vecteur classique d’une attaque de chaîne d’approvisionnement. Pour toute organisation qui stocke du code propriétaire, des modèles d’IA ou des templates d’infrastructure sur un serveur affecté, la faille est une voie directe vers le vol de propriété intellectuelle. La technique n’est pas nouvelle : CVE-2023-2825, une traversée de chemin similaire, visait déjà secrets.yml.

CVE-2026-87719, le second correctif du lot

L’avis hors cycle corrige aussi CVE-2026-87719, une désérialisation non sécurisée notée CVSS 9.9 qui touche les instances Enterprise Edition utilisant Duo Chat, l’assistant de code génératif. Le défaut se loge dans le sérialiseur de souscriptions GraphQL : un attaquant authentifié soumet un argument de souscription forgé qui contourne les contrôles de sérialisation, et force le backend à résoudre une référence d’objet hors périmètre.

La cible principale est la configuration d’Advanced Search et les identifiants des moteurs d’indexation (Elasticsearch ou OpenSearch). En manipulant le sérialiseur, un utilisateur disposant d’un simple accès Duo Chat peut amener le backend à vidanger ces identifiants, ouvrant un accès à l’ensemble de la base de code indexée, aux wikis internes et aux trackers d’issues — indépendamment des permissions au niveau des dépôts. Moins médiatisée que CVE-2026-85706 parce qu’elle exige une authentification, elle n’en est pas moins critique pour qui active Duo Chat.

Exploitée en 24 heures, et ce que ça change

Le délai entre divulgation et exploitation est le fait marquant de l’affaire. WatchTowr signale des sondes actives dès le lendemain de la publication, et CISA inscrit la faille au catalogue KEV. Ce rythme — divulguer, armer, sonder en moins d’une journée — est devenu la norme pour les failles CVSS 10 sur des produits aussi répandus : le correctif ne rattrape plus l’attaquant, il le suit de quelques heures.

Pour un RSSI ou un SRE, la conséquence est directe : une instance GitLab auto-hébergée exposée le 11 septembre au soir sans correctif est à traiter comme potentiellement déjà lue. Le correctif élimine la faille, pas l’accès éventuellement acquis entre-temps.

Verdict

Si vous auto-hébergez GitLab, appliquez immédiatement 19.1.8, 19.2.6 ou 19.3.2 — la faille touche toutes les versions 18.7 à 19.1.7, 19.2 à 19.2.5 et 19.3 à 19.3.1. Vérifiez votre version et, tant que vous n’avez pas confirmé que l’instance n’était pas exposée, faites tourner les clés de secrets.yml, les identifiants de la base et les jetons d’intégration. Si l’instance était joignable depuis Internet le jour de la divulgation, lancez une revue d’incident : journaux d’accès, comptes créés, pipelines modifiés.

Si vous utilisez GitLab.com, la plateforme gérée a été corrigée côté serveur et vous n’avez rien à faire — mais vos miroirs auto-hébergés, vos runners et vos intégrations ne le sont pas. La leçon vaut pour tout l’écosystème DevSecOps : une faille de lecture arbitraire sur un forge logiciel n’est pas un incident isolé, c’est le point d’entrée d’une compromission de chaîne d’approvisionnement. Corrigez avant de compter les jours.

Références

• The Hacker News — GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure, 11 septembre 2026
• SecurityWeek — GitLab Vulnerability Exploited One Day After Disclosure
• The CyberSec Guru — GitLab CVE-2026-85706: Critical CVSS 10.0 Path Traversal Flaw, 11 septembre 2026
• NVD — CVE-2026-85706
• NVD — CVE-2026-87719