CVE-2026-85706 : Faille de Traversée de Répertoires GitLab Critique Exploitée dans la Nature

GitLab a publié des mises à jour de sécurité d’urgence pour une vulnérabilité de gravité maximale dans Community Edition (CE) et Enterprise Edition (EE) qui permet aux attaquants non authentifiés de lire des fichiers arbitraires depuis des serveurs vulnérables. Suivie sous le nom CVE-2026-85706 et notée 10,0 sur l’échelle CVSS, la faille réside dans l’API des commits de dépôt et résulte d’une mauvaise limitation de chemin combinée à une absence de renforcement de l’authentification.

Le risque a immédiatement augmenté après la divulgation. Les chercheurs en sécurité ont observé des sondages à l’échelle d’Internet débutant vers 06:00 UTC le 11 septembre 2026, peu de temps après la publication des correctifs par GitLab. CISA a ensuite ajouté la vulnérabilité à son catalogue des vulnérabilités exploitées connues sur la base de preuves d’exploitation active.

Une exploitation réussie peut exposer des fichiers sensibles stockés sur le serveur GitLab, y compris des données de configuration, des identifiants, des secrets, des journaux et d’autres informations accessibles au service GitLab. Dans les environnements de développement, ces fichiers peuvent contenir des secrets CI/CD, des identifiants de déploiement, des tokens, des données liées au code source et des informations qui pourraient faciliter une compromission ultérieure.

La faille est particulièrement dangereuse pour les installations GitLab auto-gérées exposées à Internet car l’exploitation ne nécessite pas de compte, de privilèges existants ou d’interaction utilisateur. Selon watchTowr, la condition principale pour le chemin d’attaque observé est que l’instance GitLab contienne au moins un projet public.

Analyse de CVE-2026-85706

La vulnérabilité est un problème de traversée de chemin dans l’API des commits de dépôt de GitLab. GitLab décrit la cause première comme une limitation insuffisante des chemins de fichiers combinée à l’échec d’application de l’authentification sur la fonctionnalité affectée. Cela permet aux informations de chemin contrôlées par un attaquant d’échapper à l’emplacement où GitLab s’attend à ce que les fichiers du dépôt résident et de référencer d’autres fichiers accessibles à l’application.

Le vecteur CVSS attribué par GitLab est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Il reflète une vulnérabilité exploitable à distance avec une faible complexité d’attaque, sans exigence d’authentification, ni d’interaction utilisateur. GitLab attribue des impacts élevés en termes de confidentialité et d’intégrité, tandis que la disponibilité n’est pas directement affectée par le primitif de lecture de fichier.

Les détails les plus importants pour CVE-2026-85706 sont que les attaquants peuvent interagir à distance avec l’API des commits de dépôt vulnérable et demander des chemins qui devraient se trouver en dehors du répertoire de dépôt autorisé. Si GitLab ne contient pas correctement ce chemin, le serveur peut renvoyer le contenu d’un fichier arbitraire accessible au processus GitLab.

Selon watchTowr, l’exploitation peut exposer des fichiers spécifiques à GitLab contenant des configurations et des journaux contenant des identifiants, des secrets et d’autres informations sensibles. Selon la configuration du système et les autorisations de fichiers, les attaquants peuvent également cibler les clés SSH, les fichiers d’environnement, les identifiants de base de données, les tokens de déploiement ou d’autres données d’application sensibles.

CVE-2026-85706 affecte les versions suivantes de GitLab CE et EE :

• Toutes les versions de 18.7 avant 19.1.8
• Toutes les versions de 19.2 avant 19.2.6
• Toutes les versions de 19.3 avant 19.3.2

GitLab.com exécutait déjà la version corrigée lorsque le problème a été divulgué, tandis que les clients GitLab Dedicated n’ont pas besoin de prendre de mesures. L’exigence de remédiation urgente s’applique principalement aux organisations exploitant des instances GitLab auto-gérées.

L’exigence pour au moins un projet public augmente considérablement l’exposition des organisations qui hébergent intentionnellement des dépôts open-source, des projets de développement publics, des ressources communautaires ou d’autres contenus accessibles anonymement sur leur propre infrastructure GitLab. Un attaquant n’a pas besoin d’adhérer au projet ou d’un compte GitLab valide avant de tenter une exploitation.

Les conséquences peuvent aller au-delà de la simple divulgation d’informations. GitLab se trouve souvent au centre des pipelines de développement logiciel et stocke des matériaux hautement sensibles, y compris le code source, les variables CI/CD, les identifiants de déploiement, la configuration de l’infrastructure, les tokens d’accès et les secrets d’intégration.

Si un attaquant obtient de tels identifiants via un accès arbitraire aux fichiers, la vulnérabilité initiale de GitLab peut devenir une rampe de lancement pour une activité d’intrusion supplémentaire. Les secrets volés pourraient potentiellement donner accès à des dépôts de code source, à des infrastructures CI/CD, à des services cloud, à des registres de conteneurs, à des systèmes de déploiement ou à d’autres ressources connectées.

Cela introduit également un risque de chaîne d’approvisionnement logiciel. L’accès aux identifiants de développement ou à l’infrastructure de construction pourrait permettre à un attaquant de tenter des modifications de dépôt non autorisées, de manipuler les processus de construction, de voler du code propriétaire, ou de compromettre des systèmes en aval qui font confiance aux artefacts produits via l’environnement GitLab affecté.

GitLab a crédité le chercheur en sécurité s3ntago pour avoir signalé la vulnérabilité via le programme de bug bounty HackerOne de la société. La date exacte de découverte et de rapport privés n’a pas été divulguée publiquement. GitLab a publié des versions corrigées le 10 septembre 2026 et a documenté publiquement la faille dans le cadre de sa publication de correctifs critiques.

La transition de la divulgation à une activité hostile a été extrêmement rapide. WatchTowr a déclaré que son réseau honeypot Attacker Eye avait détecté des sondes comportementales ciblant la vulnérabilité à partir d’environ 06:00 UTC le 11 septembre, indiquant que des acteurs externes avaient déjà rétro-ingénier la faiblesse et commencé à tester les systèmes GitLab accessibles depuis Internet.

CISA a ajouté la faille à son catalogue KEV plus tard le 11 septembre après avoir confirmé des preuves d’exploitation active. Les agences de la branche exécutive civile fédérale ont été instruites de remédier aux systèmes affectés d’ici le 14 septembre 2026, et CISA a également marqué la vulnérabilité comme nécessitant un triage médico-légal en vertu de la Directive Opérationnelle Contraignante 26-04.

Le code PoC public de CVE-2026-85706 est également apparu peu après la divulgation, abaissant encore la barrière technique pour les attaquants intéressés à reproduire le comportement de lecture de fichier arbitraire. Combinée à la faible complexité de la vulnérabilité et au chemin d’attaque non authentifié, la reproduction publique augmente la probabilité d’une exploitation opportuniste plus large.

Il n’existe actuellement aucun ensemble complet de IOC spécifiques à la campagne CVE-2026-85706, tels que les adresses IP des attaquants, les domaines ou les hachages de logiciels malveillants pouvant identifier de manière fiable l’exploitation. Au lieu de cela, l’indicateur le plus utile est la structure des demandes ciblant l’API vulnérable de GitLab.

WatchTowr recommande de rechercher des requêtes HTTP POST dirigées vers des chemins correspondant à :

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

Les défenseurs devraient prêter une attention particulière lorsque ces demandes contiennent des paramètres de chemin de fichier suspects ou semblent demander des fichiers non liés au dépôt en cours d’accès.

Atténuation de CVE-2026-85706

GitLab recommande fortement à toutes les installations auto-gérées affectées de mettre immédiatement à niveau vers l’une des versions corrigées :

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Toute version ultérieure prise en charge contenant le correctif de sécurité devrait également résoudre la vulnérabilité. Les administrateurs doivent vérifier la version exacte en cours d’exécution plutôt que de supposer que la mise à jour automatique s’est produite.

Les organisations incapables de corriger immédiatement devraient supprimer l’accès public inutile à l’instance GitLab affectée ou restreindre la connectivité au niveau du proxy inverse, du pare-feu, de l’équilibreur de charge ou du réseau jusqu’à ce que la mise à jour puisse être complétée. Il ne s’agit que d’une mesure temporaire de réduction de l’exposition et ne doit pas remplacer l’installation de la version corrigée de GitLab.

La détection de CVE-2026-85706 devrait commencer par l’identification de toutes les instances GitLab auto-gérées, de leurs versions exactes et de savoir si elles étaient accessibles depuis Internet après le 10 septembre. Les systèmes hébergeant un ou plusieurs projets publics devraient recevoir une priorité d’investigation particulièrement élevée.

Pour détecter l’exploitation ou la reconnaissance de CVE-2026-85706, les défenseurs devraient examiner les télémétries de GitLab, de proxy inverse, WAF et serveur web pour :

• Des requêtes HTTP POST vers /api/v4/projects/{id}/repository/commits/
• Des requêtes contenant des paramètres de chemin de fichier inhabituels
• Des séquences de traversée de chemin tentant de quitter les répertoires de dépôt attendus
• Des requêtes pour des fichiers de configuration ou de journaux GitLab via les API de dépôt
• Un grand nombre de requêtes d’API de commits de dépôt provenant de sources auparavant inconnues
• Un accès anonyme suivi de tentatives inhabituelles de récupération de ressources côté serveur
• Un accès inattendu à des identifiants, des fichiers de configuration ou des secrets d’application
• Une nouvelle activité d’authentification utilisant des identifiants qui ont pu être exposés via GitLab
• Un accès inexpliqué à l’infrastructure CI/CD, de cloud, de registre ou de déploiement suite à une activité GitLab suspecte

WatchTowr recommande particulièrement d’examiner le modèle d’API des commits de dépôt parce qu’il peut fournir une preuve directe des tentatives de sondage ou d’exploitation contre l’endpoint vulnérable.

Le patching devrait également être combiné avec une enquête rétrospective. L’exigence de triage médico-légal de la CISA reflète la possibilité que les organisations aient été compromises avant le déploiement du correctif, en particulier compte tenu de la rapidité avec laquelle les attaques ont commencé après la divulgation.

Si une activité de lecture de fichiers suspecte est identifiée, les administrateurs devraient déterminer exactement quels fichiers peuvent avoir été accédés. Les secrets contenus dans les fichiers potentiellement exposés devraient être considérés comme compromis jusqu’à preuve du contraire.

Les organisations devraient envisager de faire tourner :

• Les tokens d’accès GitLab et les tokens d’accès personnels
• Les tokens de déploiement
• Les variables et secrets CI/CD
• Les identifiants de base de données
• Les clés SSH
• Les identifiants de cloud
• Les identifiants de registre de conteneur
• Les tokens API et d’intégration
• Les secrets OAuth
• Les identifiants de déploiement et d’automatisation

Les équipes de sécurité devraient également enquêter sur les systèmes en aval qui faisaient confiance à ces identifiants. La mise à jour de GitLab ferme le chemin de lecture de fichier vulnérable mais ne peut invalider les secrets déjà obtenus par un attaquant.

Pour les systèmes à haut risque, les défenseurs devraient comparer l’activité récente du dépôt, du pipeline, du compte, du runner et du déploiement avec les enregistrements de confiance connus pour identifier un abus potentiel suivi. Les modifications inattendues dans les pipelines, les modifications des dépôts, les nouveaux tokens émis ou l’accès inhabituel à l’infrastructure de construction devraient être investigués.

Étant donné la sévérité CVSS de 10,0, l’exploitation confirmée, la reproduction publique et la transition rapide de la divulgation au scanning, la remédiation devrait être considérée comme une urgence pour les déploiements GitLab auto-gérés exposés à Internet.