Une faille critique de lecture de fichiers dans GitLab exploitée dans les 24 heures suivant la publication du correctif

Des acteurs malveillants ont commencé à sonder une vulnérabilité critique de GitLab dès le lendemain de l’annonce par l’entreprise de ses mises à jour de sécurité, selon des chercheurs qui surveillent les activités d’exploitation.

La faille, référencée sous le nom de CVE-2026-85706, permet à un attaquant non authentifié de lire des fichiers arbitraires sur un serveur GitLab auto-hébergé. Son exploitation nécessite une seule requête HTTP spécialement conçue, ce qui fait des installations exposées et non corrigées des cibles idéales pour les scans automatisés.

CVE-2026-85706 affiche un score CVSS de 10 et figure déjà dans le catalogue des vulnérabilités exploitées connues de la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis. La CISA l’a ajoutée le 11 septembre 2026 et a accordé aux agences fédérales jusqu’au 14 septembre 2026 pour corriger les systèmes concernés.

La version de GitLab associée corrige également 17 autres vulnérabilités, dont une deuxième faille critique et six failles de gravité élevée. Les administrateurs doivent donc déployer l’intégralité de la mise à jour plutôt que de traiter l’incident comme une simple faille isolée de traversée de chemin.

Une traversée de chemin sans authentification permet d’accéder aux fichiers du serveur

CVE-2026-85706 est une vulnérabilité de traversée de chemin dans l’API des commits de dépôt de GitLab. Le confinement incorrect des chemins de fichiers, combiné à l’absence de contrôle d’authentification, permet aux requêtes de sortir du chemin prévu et d’accéder à des fichiers situés ailleurs sur le serveur.

Aucun compte GitLab valide n’est nécessaire. L’attaque peut être menée au moyen d’une seule requête HTTP.

Son vecteur CVSS est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Il s’agit d’une vulnérabilité exploitable à distance, de faible complexité, qui ne nécessite ni privilèges ni interaction de l’utilisateur et qui présente un impact élevé sur la confidentialité.

Selon ce vecteur de calcul, la vulnérabilité n’a pas d’impact direct sur la disponibilité. Toutefois, l’accès à des fichiers arbitraires peut révéler des informations permettant de mener d’autres attaques. Les fichiers présents sur un hôte GitLab peuvent contenir la configuration de l’application, des identifiants, des jetons d’accès, du code source, des secrets d’intégration ou des informations sur l’infrastructure connectée.

Les conséquences dépendent des fichiers accessibles et de la configuration de chaque installation. Les informations publiées à ce jour n’ont pas permis d’identifier précisément les fichiers récupérés lors des tentatives d’exploitation observées, ni de confirmer des compromissions ultérieures imputables à ces tentatives.

WatchTowr a observé des tentatives d’exploitation dans la nature le lendemain de l’annonce des correctifs par GitLab et s’attend à une intensification des attaques. Le délai très court entre la divulgation de la vulnérabilité, la rétro-ingénierie, les scans et les tentatives de compromission laisse très peu de temps pour réagir.

Versions exactes de GitLab CE et EE concernées

La vulnérabilité touche les installations auto-hébergées de GitLab Community Edition et Enterprise Edition dans les plages de versions suivantes :

• GitLab CE et EE à partir de la version 18.7 et avant la 19.1.8
• GitLab CE et EE à partir de la version 19.2 et avant la 19.2.6
• GitLab CE et EE à partir de la version 19.3 et avant la 19.3.2

Les administrateurs doivent effectuer la mise à niveau vers la version corrigée correspondant à leur branche :

• 19.1.8 ou ultérieure
• 19.2.6 ou ultérieure
• 19.3.2 ou ultérieure

Les organisations utilisant des branches antérieures ou maintenues séparément doivent obtenir la version corrigée correspondante prise en charge par l’éditeur. Aucune version concernée propre aux services cloud ni aucune instruction de mitigation n’a été communiquée.

Les instances auto-hébergées accessibles depuis Internet présentent le risque de scan le plus immédiat, mais l’exposition interne ne doit pas être négligée. Un attaquant ayant déjà accès au réseau de l’entreprise pourrait cibler un serveur GitLab accessible en interne au moyen de la même requête non authentifiée.

Les systèmes GitLab occupent également une position sensible dans les environnements de développement. Ils sont souvent connectés aux runners, aux plateformes de déploiement, aux registres, aux fournisseurs d’identité, aux systèmes de gestion des tickets et aux infrastructures cloud. L’accès aux fichiers de l’hôte pourrait donc exposer des identifiants permettant d’atteindre des ressources au-delà de GitLab.

Les recherches dans les journaux peuvent révéler des tentatives d’exploitation

Les administrateurs GitLab doivent examiner les journaux HTTP à la recherche de requêtes POST envoyées à l’API des commits de dépôt :

/api/v4/projects/{id}/repository/commits/

Les requêtes contenant un paramètre file.path doivent faire l’objet d’une investigation, car elles peuvent correspondre à des tentatives d’exploitation de CVE-2026-85706.

Ce seul indicateur ne doit toutefois pas être automatiquement considéré comme une preuve de compromission. Les enquêteurs doivent corréler les requêtes correspondantes avec les adresses IP sources, les horodatages, les codes de réponse, les accès inhabituels à des fichiers, l’activité des comptes et les modifications ultérieures apportées aux dépôts ou aux pipelines.

L’analyse doit également porter sur les éléments suivants :

• Les commits et modifications de dépôts autour de la requête suspecte
• L’accès aux variables CI/CD et aux secrets des projets
• Les définitions de pipelines et les tâches récemment déclenchées
• L’activité des runners et les opérations de build inattendues
• Les clés de déploiement, les jetons d’accès personnels ou de projet et les intégrations
• Les modifications concernant les utilisateurs, les autorisations, les webhooks ou les branches protégées
• Les artefacts de build nouvellement générés ou modifiés
• L’authentification au moyen d’identifiants stockés sur l’hôte GitLab
• L’activité dans les environnements de déploiement et de gestion de paquets en aval

Les identifiants et secrets potentiellement exposés doivent être renouvelés. Les équipes doivent valider les définitions des pipelines et reconstruire les artefacts sensibles à partir d’états sources de confiance lorsqu’une compromission ne peut pas être exclue.

L’application du correctif comble la faille connue, mais ne déloge pas un attaquant qui aurait déjà obtenu des identifiants ou modifié des ressources de développement. Les systèmes ayant reçu des requêtes suspectes nécessitent une analyse forensique en plus de la mise à niveau.

La CISA fixe au 14 septembre l’échéance pour les agences fédérales

La CISA a inscrit CVE-2026-85706 dans son catalogue KEV le 11 septembre 2026. Cette inscription confirme que la vulnérabilité est exploitée en dehors d’environnements de recherche contrôlés et fait passer le problème du stade de risque théorique à celui de priorité opérationnelle active.

Les agences civiles fédérales américaines doivent avoir achevé la remédiation avant le 14 septembre 2026.

La CISA exige des organisations concernées qu’elles appliquent les mesures de mitigation fournies par l’éditeur tout en respectant les recommandations de la directive BOD 26-04 pour hiérarchiser les mises à jour de sécurité en fonction des risques. Les agences doivent également appliquer les CISA’s Forensics Triage Requirements.

Pour les services cloud, les organisations sont invitées à suivre les recommandations applicables de la BOD 26-04 ou à cesser de les utiliser lorsqu’aucune mesure de mitigation efficace n’est disponible. Chaque partie prenante reste responsable de l’évaluation de l’exposition Internet d’un actif et de l’application des exigences de correction correspondantes.

Aucune solution de contournement offrant une protection équivalente n’a été identifiée. L’installation immédiate de la version corrigée de GitLab constitue donc la principale mesure défensive.

La mise à jour corrige une autre faille critique de GitLab

La même version de sécurité corrige CVE-2026-87719, une vulnérabilité de désérialisation non sécurisée dans le sérialiseur des abonnements GraphQL de GitLab.

Elle affiche un score CVSS de 9,9 et le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Contrairement à CVE-2026-85706, son exploitation nécessite des privilèges de faible niveau, mais ses effets potentiels concernent la confidentialité, l’intégrité et la disponibilité.

Un attaquant pourrait accéder aux configurations d’instance d’Advanced Search ainsi qu’à des identifiants sensibles. Les versions 19.1.8, 19.2.6 et 19.3.2 de GitLab CE et EE corrigent ce problème.

La mise à jour corrige également six vulnérabilités de gravité élevée susceptibles de permettre l’exécution de code à distance, l’accès à des variables CI/CD protégées, des attaques XSS ou un déni de service. Les informations détaillées sur les autres failles corrigées et l’ensemble de leurs plages de versions concernées ne sont pas disponibles ici.

Il est important de déployer la version complète. Un système corrigé uniquement contre la faille de traversée de chemin pourrait rester exposé par l’intermédiaire de l’un des autres composants corrigés.

Une exploitation rapide après un précédent incident chez GitLab

L’activité récente n’est pas le seul cas récent d’exploitation quasi immédiate auquel GitLab a été confronté. Des chercheurs avaient déjà observé des attaques rapides visant CVE-2026-19478, une vulnérabilité critique d’injection de code dans GraphQL.

CVE-2026-19478 affiche un score CVSS de 9,4 et est classée CWE-94. Dans certaines conditions, un attaquant non authentifié pouvait exploiter une directive GraphQL pour modifier ou supprimer à distance des projets publics et des données utilisateur.

Les plages de versions concernées étaient les suivantes :

• GitLab CE et EE à partir de la version 18.2 et avant la 18.11.11
• À partir de la version 19.0 et avant la 19.0.8
• À partir de la version 19.1 et avant la 19.1.6
• À partir de la version 19.2 et avant la 19.2.4

La répétition de ces incidents montre à quelle vitesse les attaquants peuvent exploiter concrètement les failles de GitLab, en particulier celles qui sont accessibles sans authentification. Les plateformes de développement concentrent au même endroit du code précieux, des secrets et des mécanismes d’automatisation.

Les administrateurs doivent corriger immédiatement CVE-2026-85706, conserver les journaux pertinents et rechercher toute activité suspecte visant l’API des commits de dépôt. Tout indice d’accès à des fichiers doit entraîner le renouvellement des identifiants ainsi qu’un examen plus large des pipelines, des runners, des intégrations, des artefacts et des déploiements en aval.