GitLab a publié en urgence plusieurs correctifs après la découverte d’une vulnérabilité critique permettant à un attaquant non authentifié de lire des fichiers arbitraires sur un serveur GitLab. Référencée CVE-2026-85706, la faille obtient la note maximale de 10 sur 10 sur l’échelle CVSS.
La société de cybersécurité watchTowr indique avoir détecté des tentatives d’exploitation sur Internet dès le 11 septembre 2026, quelques heures seulement après la publication des informations techniques. La CISA américaine a également ajouté CVE-2026-85706 à son catalogue des vulnérabilités activement exploitées.
GitLab au cœur des chaînes de développement
GitLab est une plateforme largement utilisée par les entreprises et les développeurs pour héberger du code source, gérer des projets et automatiser les phases de compilation et de déploiement avec des pipelines CI/CD.
Une instance GitLab peut ainsi concentrer des informations particulièrement sensibles : dépôts de code privés, configurations internes, clés d’accès, jetons d’API ou encore secrets nécessaires aux déploiements. La capacité de lire des fichiers directement sur le serveur représente donc un risque qui dépasse largement la simple exposition d’un document.
Une faille critique exploitable sans compte
Selon GitLab, CVE-2026-85706 se situe dans l’API des commits de dépôts. La vulnérabilité combine un mauvais contrôle des chemins de fichiers avec une absence de vérification correcte de l’authentification.
Dans certaines conditions, un attaquant externe peut donc provoquer une traversée de répertoires, ou path traversal, afin de demander au serveur un fichier situé en dehors de l’emplacement auquel l’API devrait normalement être limitée.
Le point particulièrement critique est qu’aucun compte GitLab ni mot de passe n’est nécessaire pour exploiter la vulnérabilité. watchTowr indique que la présence d’au moins un projet public sur l’instance peut suffire à rendre le scénario exploitable.
Des secrets et identifiants peuvent être récupérés
L’exploitation permet de lire des fichiers auxquels un visiteur externe ne devrait jamais avoir accès. Selon les recherches de watchTowr, cela peut notamment concerner des journaux, fichiers de configuration et autres informations sensibles présentes sur le serveur.
Le risque devient particulièrement important lorsque ces fichiers contiennent des identifiants, jetons d’accès, secrets applicatifs ou informations de configuration. La récupération d’un premier secret peut ensuite permettre à un attaquant de chercher à étendre son accès vers d’autres composants de l’environnement.
Dans une infrastructure de développement, de telles informations peuvent également ouvrir la voie à l’accès à des dépôts privés ou à des systèmes connectés à la chaîne CI/CD.
Les premières tentatives détectées quelques heures après la publication
watchTowr affirme avoir reproduit la vulnérabilité puis observé des sondes correspondant à CVE-2026-85706 sur son réseau de systèmes leurres. L’activité aurait commencé dès 6 heures UTC le 11 septembre.
Cette rapidité montre à quel point la fenêtre entre la publication d’un correctif et les premières recherches de serveurs vulnérables est désormais réduite. Des attaquants analysent les correctifs et les informations publiques afin de reconstituer rapidement la vulnérabilité puis scanner Internet à la recherche d’instances non mises à jour.
La CISA classe déjà la faille parmi les vulnérabilités exploitées
Le 11 septembre, la CISA a ajouté CVE-2026-85706 à son Known Exploited Vulnerabilities Catalog, qui recense les vulnérabilités pour lesquelles des éléments d’exploitation réelle ont été établis.
L’agence américaine demande aux organismes concernés d’appliquer les mesures recommandées par GitLab. Le Centre canadien pour la cybersécurité a lui aussi publié une alerte et le CERT-FR a référencé la vulnérabilité dans son avis consacré aux multiples failles corrigées par GitLab.
Quelles versions de GitLab sont vulnérables ?
La faille touche à la fois GitLab Community Edition et Enterprise Edition. Les branches suivantes sont concernées :
- toutes les versions à partir de 18.7 et antérieures à 19.1.8 ;
- les versions 19.2 antérieures à 19.2.6 ;
- les versions 19.3 antérieures à 19.3.2.
GitLab demande aux administrateurs d’instances auto-hébergées de passer immédiatement vers les versions 19.1.8, 19.2.6 ou 19.3.2, selon la branche utilisée.
GitLab.com est déjà corrigé. Les clients utilisant GitLab Dedicated n’ont également aucune intervention particulière à effectuer selon l’éditeur. L’urgence concerne donc principalement les instances GitLab autogérées, notamment lorsqu’elles sont directement accessibles depuis Internet.
Une deuxième faille critique notée 9,9 sur 10
Le correctif publié par GitLab ne concerne pas uniquement CVE-2026-85706. Une seconde vulnérabilité critique, référencée CVE-2026-87719 et notée 9,9 sur 10, touche GitLab Enterprise Edition.
Cette faille de désérialisation peut permettre, dans certaines conditions, à un utilisateur authentifié disposant d’un accès à GitLab Duo Chat d’obtenir des configurations d’Advanced Search et des identifiants sensibles à l’aide d’une requête GraphQL spécialement conçue.
Une autre vulnérabilité, CVE-2026-88765, notée 8,5, peut également conduire à une exécution de code à distance dans GitLab Enterprise Edition lorsqu’un utilisateur authentifié importe un projet spécialement préparé.
Une course contre la montre pour les serveurs GitLab exposés
Les administrateurs d’instances GitLab accessibles depuis Internet doivent désormais considérer la mise à jour comme prioritaire. Lorsqu’un serveur vulnérable a été publiquement exposé depuis la divulgation de la faille, installer le correctif ne suffit pas nécessairement à exclure une compromission antérieure.
watchTowr recommande également de vérifier les journaux de l’API des commits à la recherche de requêtes inhabituelles pouvant correspondre à des tentatives d’exploitation. En présence d’indices suspects, les secrets, jetons et identifiants accessibles depuis l’instance doivent être considérés avec une attention particulière.
Cette nouvelle faille intervient quelques semaines seulement après une précédente vulnérabilité critique de GitLab rapidement ciblée par des attaquants. Avec CVE-2026-85706, le scénario se répète : un correctif est disponible, mais les recherches de serveurs vulnérables ont commencé presque immédiatement.