veilletech.fr
12 sept. Feed du jour
#01 SÉCURITÉ Faille

GitLab : dix sur dix, vos secrets sont lisibles

Un serveur qui lit ses propres journaux à un inconnu n'a plus de secrets.

CVE-2026-85706 (CVSS 10.0) permet à un utilisateur non authentifié de lire n'importe quel fichier d'un serveur GitLab via l'API des commits. watchTowr a observé les premières sondes à 06:00 UTC le 11 septembre, quelques heures après la publication. La CISA a inscrit la faille à son catalogue des vulnérabilités exploitées le même jour.

2 min de lectureintermédiairevidéo 1:13
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Pourquoi ça compte
  3. Comment s'y prendre
  4. À retenir

Ce qui se passe

GitLab a publié le 10 septembre trois versions correctives — 19.3.2, 19.2.6 et 19.1.8 — qui ferment dix-neuf failles, dont deux critiques.

La première, CVE-2026-85706, est notée 10.0 sur l'échelle CVSS, le maximum. C'est une traversée de chemin dans l'API des commits d'un dépôt : le chemin demandé n'était pas confiné au dépôt, et l'API ne vérifiait pas l'authentification. Un utilisateur non authentifié peut donc lire n'importe quel fichier du serveur.

Sont touchées les éditions Community et Enterprise, de la 18.7 à la 19.3.1 incluse. La faille a été signalée par s3ntago via HackerOne.

La seconde critique, CVE-2026-87719 (CVSS 9.9), ne touche que l'édition Enterprise depuis la 18.3 : une désérialisation non sécurisée dans le sérialiseur des abonnements GraphQL livre à tout utilisateur ayant accès à Duo Chat la configuration d'Advanced Search et des identifiants.

Pourquoi ça compte

Elle est déjà sondée. watchTowr dit observer une activité réelle depuis 06:00 UTC le 11 septembre, soit quelques heures après la publication de l'avis, et la CISA a inscrit la CVE à son catalogue des vulnérabilités exploitées le même jour.

La condition d'exploitation est dérisoire : il suffit qu'au moins un projet public existe sur l'instance. Or ce que l'attaquant lit en premier, ce sont les journaux et les fichiers de configuration de GitLab — donc les identifiants, les jetons, les secrets de CI/CD. Jake Knott, de watchTowr, rappelle la suite logique : l'accès au code source, puis l'injection de code dans les chaînes de compilation, et tout ce qui est en aval.

Comment s'y prendre

Passez à la version corrigée de votre branche — 19.1.8, 19.2.6 ou 19.3.2 —, en commençant par les instances exposées sur Internet. Puis cherchez dans vos journaux les requêtes vers l'API des commits qui portent un paramètre file.Path :

Terminal
grep -E 'POST /api/v4/projects/[0-9]+/repository/commits/' \
  /var/log/gitlab/gitlab-rails/production.log | grep 'file.Path'

Si vous en trouvez, ou si l'instance était exposée avant le correctif, traitez les secrets comme lus et faites-les tourner : jetons personnels, jetons de CI/CD, clés de déploiement, identifiants de base.

Source : The Hacker News, avis officiel : patch release GitLab 19.3.2.