Une faille de traversée de répertoires dans GitLab fait son entrée dans le catalogue KEV de la CISA, avec un délai de trois jours pour appliquer le correctif

GitLab exhorte les administrateurs d’installations autogérées à corriger une vulnérabilité de gravité maximale susceptible d’exposer des fichiers arbitraires via l’API des commits de dépôt.

Référencée sous le numéro CVE-2026-85706, cette faille de traversée de répertoires affecte GitLab Community Edition et Enterprise Edition. Dans certaines conditions, un attaquant non authentifié peut l’exploiter à distance au moyen d’une seule requête HTTP.

La CISA a ajouté la vulnérabilité à son catalogue des vulnérabilités exploitées connues le 11 septembre 2026. Les agences fédérales américaines doivent avoir terminé la remédiation avant le 14 septembre 2026, ce qui leur laisse un délai exceptionnellement court de trois jours.

GitLab a indiqué ne pas avoir confirmé d’exploitation dans la nature. Toutefois, la société de sécurité watchTowr a observé des sondages à l’échelle d’Internet visant des serveurs GitLab non corrigés. L’inscription au catalogue KEV signifie également que les défenseurs doivent considérer cette faille comme une menace active, et non comme une faiblesse théorique.

Un accès API non authentifié peut exposer des fichiers du serveur

CVE-2026-85706 est due à un cloisonnement insuffisant des chemins et à l’absence de contrôle d’authentification dans la fonctionnalité des commits de dépôt exposée par l’API GitLab. La vulnérabilité est classée CWE-22, soit une restriction incorrecte d’un chemin d’accès à un répertoire limité.

Un attaquant peut manipuler le traitement des chemins de fichiers au niveau du point de terminaison des commits de dépôt afin que le serveur GitLab accède à du contenu situé en dehors du répertoire prévu. Aucun compte valide ni aucune interaction de l’utilisateur ne sont nécessaires, et l’attaque signalée peut être menée au moyen d’une seule requête.

Une exploitation réussie peut révéler tous les fichiers lisibles par le service GitLab dans la configuration particulière du serveur. Parmi les cibles potentielles figurent :

• Les fichiers de configuration de l’application et de l’infrastructure
• Les identifiants et les jetons d’accès
• Les clés API et autres secrets
• Le code source propriétaire
• Les données des dépôts
• Les fichiers contenant des informations sur les services connectés

Les informations techniques disponibles établissent la possibilité de lire des fichiers arbitraires. Elles ne montrent pas que CVE-2026-85706 permette à elle seule une exécution de code à distance ou la modification directe de fichiers du serveur.

La vulnérabilité obtient un score CVSS 3.1 de 10,0 et le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Cette note décrit une attaque accessible par le réseau, de faible complexité, ne nécessitant ni privilèges ni intervention de l’utilisateur. Le vecteur enregistré attribue un impact élevé sur la confidentialité et l’intégrité, sans impact sur la disponibilité.

Le chercheur « s3ntago » a signalé la vulnérabilité dans le cadre du programme de chasse aux bugs HackerOne de GitLab.

Versions exactement concernées et versions sûres vers lesquelles effectuer la mise à niveau

La vulnérabilité affecte GitLab CE et EE dans trois plages de versions :

• Versions à partir de 18.7 et antérieures à 19.1.8
• Versions à partir de 19.2 et antérieures à 19.2.6
• Versions à partir de 19.3 et antérieures à 19.3.2

Les opérateurs doivent donc effectuer la mise à niveau vers 19.1.8, 19.2.6 ou 19.3.2, selon la branche de publication déployée.

Certaines communications ont décrit plus généralement le correctif comme s’appliquant à la branche 19.1. Les administrateurs doivent prendre 19.1.8 comme limite corrigée de référence, plutôt que de supposer que n’importe quelle version 19.1 est sûre.

L’exposition immédiate concerne les installations autogérées, en particulier les serveurs accessibles depuis Internet. GitLab.com utilisait déjà une version corrigée, tandis que les clients de GitLab Dedicated ont été informés qu’aucune action n’était nécessaire de leur part.

Les organisations doivent néanmoins vérifier leur modèle de déploiement au lieu de se fier uniquement à la marque GitLab associée à un service interne. Les instances hébergées en interne et gérées par des unités opérationnelles, des équipes de développement, des filiales ou des prestataires externes peuvent échapper aux processus centralisés de gestion des correctifs.

Le statut KEV de la CISA renforce la priorité de la réponse

La CISA a inscrit CVE-2026-85706 au catalogue KEV le 11 septembre 2026, avec une échéance de remédiation fixée au 14 septembre 2026 pour les agences fédérales.

La réponse requise demande aux agences d’appliquer les mesures d’atténuation du fournisseur tout en respectant la BOD 26-04, « Prioritizing Security Updates Based on Risk », ainsi que les exigences de la CISA en matière de triage forensique. Les agences qui utilisent des services cloud doivent suivre les dispositions applicables de la BOD 26-04 ou cesser de les utiliser lorsqu’aucune mesure d’atténuation efficace n’est disponible. Les responsables des actifs doivent également évaluer leur exposition à Internet et respecter les exigences de la directive en matière de correction fondée sur les risques.

Il existe une distinction entre les déclarations publiques concernant l’exploitation. GitLab n’avait pas identifié de compromission confirmée, tandis que watchTowr a fait état d’analyses et de sondages, et non d’attaques réussies vérifiées. Parallèlement, l’inscription au catalogue KEV indique que la CISA considère que la vulnérabilité répond à ses critères d’exploitation avérée.

Aucun acteur malveillant, aucune campagne, aucune organisation victime, aucune adresse IP malveillante, aucune charge utile, aucun user-agent ni aucun chemin de fichier ciblé n’a été identifié publiquement. L’absence de ces éléments limite l’attribution, mais elle ne doit pas retarder la remédiation.

Les opérations de reconnaissance à l’échelle d’Internet précèdent souvent l’exploitation dès que le point de terminaison et la structure des requêtes d’une vulnérabilité sont connus. Dans le cas présent, l’absence d’authentification et la possibilité de mener l’attaque en une seule requête réduisent le coût opérationnel pour les attaquants.

Ce que les défenseurs doivent rechercher

Les administrateurs doivent examiner les journaux de l’application GitLab ainsi que les enregistrements des reverse proxies, des répartiteurs de charge, des pare-feu applicatifs ou des passerelles API placés en amont du service.

Le schéma le plus pertinent est une requête HTTP POST visant un URI de la forme suivante :

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

Les requêtes contenant un paramètre file.path nécessitent une analyse plus approfondie. Cette combinaison peut signaler une activité d’exploitation, même si les informations disponibles ne permettent pas de considérer comme malveillante de manière certaine toute requête correspondante.

Aucune chaîne de charge utile ni séquence de traversée particulière n’a été divulguée. Les défenseurs doivent conserver l’intégralité des données des requêtes lorsque la législation et les contraintes opérationnelles le permettent, notamment les horodatages, les adresses sources, les en-têtes, les paramètres, les codes de réponse et la taille des réponses.

Si des requêtes suspectes sont découvertes, les équipes d’intervention doivent déterminer quels fichiers le compte de service GitLab pouvait lire. L’analyse doit couvrir les répertoires de configuration, le stockage des dépôts, les fichiers d’environnement, les paramètres d’intégration, les sauvegardes, les identifiants, les jetons et les secrets utilisés pour accéder à des systèmes externes.

Lorsque les éléments disponibles indiquent un accès à des fichiers arbitraires, les secrets concernés doivent être considérés comme exposés et faire l’objet d’une rotation. Les équipes doivent également examiner les services en aval accessibles au moyen de ces identifiants. L’application du correctif ferme la vulnérabilité, mais n’invalide pas les informations déjà obtenues par un attaquant.

Une seconde faille critique affecte GitLab Enterprise Edition

Les mêmes mises à jour de sécurité corrigent CVE-2026-87719, une vulnérabilité distincte de désérialisation non sécurisée dans GitLab Enterprise Edition.

Cette faille nécessite un utilisateur authentifié disposant d’un accès à Duo Chat. Dans certaines conditions, cet utilisateur peut fournir un argument d’abonnement GraphQL spécialement conçu qui contourne le traitement de sérialisation attendu et déclenche une recherche d’objet sur le serveur.

L’accès ainsi obtenu peut exposer les configurations d’instance d’Advanced Search ainsi que des identifiants sensibles. Contrairement à CVE-2026-85706, cette vulnérabilité nécessite des privilèges de faible niveau et ne permet pas une attaque anonyme.

CVE-2026-87719 obtient un score CVSS 3.1 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. Elle est classée CWE-502, soit une désérialisation de données non fiables.

Les plages de versions Enterprise Edition concernées sont les suivantes :

• Versions à partir de 18.3 et antérieures à 19.1.8
• Versions à partir de 19.2 et antérieures à 19.2.6
• Versions à partir de 19.3 et antérieures à 19.3.2

CVE-2026-87719 ne figure pas dans le catalogue KEV de la CISA. Les organisations qui utilisent Duo Chat et Advanced Search doivent néanmoins l’inclure dans leur analyse, en particulier lorsqu’elles enquêtent sur une activité authentifiée suspecte.

GitLab a déjà été confronté à plusieurs failles côté serveur inscrites au catalogue KEV

Cette nouvelle entrée au catalogue KEV fait suite à d’autres vulnérabilités GitLab qui permettaient à des attaquants d’accéder à des données ou à des ressources internes par l’intermédiaire de fonctionnalités côté serveur.

CVE-2023-2825 était une autre vulnérabilité de traversée de répertoires affichant un score CVSS de 10,0, limitée à GitLab CE/EE 16.0.0. Elle permettait de lire des fichiers sans authentification lorsqu’une pièce jointe était présente dans un projet public imbriqué dans au moins cinq groupes.

Deux anciennes failles de server-side request forgery ont également été inscrites au catalogue KEV en 2026. CVE-2021-39935, qui affecte l’API CI Lint, a été ajoutée le 3 février 2026, avec une échéance fédérale fixée au 24 février 2026. CVE-2021-22175, qui concerne des requêtes de webhook vers des réseaux internes, a suivi le 18 février 2026, avec une remédiation exigée avant le 11 mars 2026.

Pour CVE-2026-85706, la réponse est claire : recenser chaque instance autogérée, appliquer la version corrigée correspondant à sa branche, examiner le trafic API et rechercher d’éventuels accès aux données. Les systèmes exposés sur Internet doivent être traités en priorité.