CVE-2026-85706 : corrigez sans délai vos instances GitLab autogérées

CVE-2026-85706 est une vulnérabilité de sévérité maximale dans les éditions Community Edition (CE) et Enterprise Edition (EE) de GitLab exploitées en autogestion. Notée 10,0 sur 10 selon CVSS 3.1, elle peut permettre, dans certaines conditions, à un utilisateur non authentifié de lire des fichiers arbitraires sur le serveur GitLab. Il ne s’agit plus d’un risque théorique : la CISA américaine l’a inscrite parmi les vulnérabilités connues comme exploitées, tandis que des chercheurs ont signalé des sondes visant des instances exposées sur Internet peu après la publication des correctifs. 32122

Priorité immédiate : mettre à niveau

Toute instance GitLab autogérée concernée doit être mise à jour au plus vite vers l’une de ces versions corrigées :

• 19.1.8 ou version ultérieure ;
• 19.2.6 ou version ultérieure ;
• 19.3.2 ou version ultérieure.

Les versions touchées sont les GitLab CE/EE 18.7 à 19.1.7, 19.2.0 à 19.2.5 et 19.3.0 à 19.3.1. GitLab a publié les correctifs le 10 septembre 2026. 37

La CISA a ajouté CVE-2026-85706 à son catalogue KEV (Known Exploited Vulnerabilities) le 11 septembre, avec une échéance au 14 septembre pour les agences civiles fédérales américaines couvertes. Cette date ne s’impose pas automatiquement aux organisations privées, mais elle illustre le niveau d’urgence pour toute installation autogérée accessible depuis Internet. 3

Ce que permet la faille

La vulnérabilité se situe dans l’API Repository Commits de GitLab. Son origine documentée est la combinaison d’un contrôle insuffisant des chemins fournis par l’utilisateur et d’une absence de contrôle d’authentification. Un requérant non authentifié peut ainsi, dans certaines conditions, lire des fichiers auxquels le service GitLab a accès. 3

Il s’agit avant tout d’une faille de divulgation de fichiers. Les éléments fournis ne démontrent pas que CVE-2026-85706 permette, à elle seule, l’exécution de code à distance. En revanche, la lecture de fichiers arbitraires peut révéler les éléments nécessaires à une compromission ultérieure selon la configuration du serveur : paramètres applicatifs, jetons, clés SSH, identifiants de bases de données ou autres secrets lisibles par le processus GitLab. 925

Pourquoi l’exploitation active change la réponse

WatchTowr a indiqué avoir observé des sondes exploitant la faille dans la nature, notamment via son réseau de pots de miel le 11 septembre. L’inscription au catalogue KEV de la CISA est un autre signal majeur : ce catalogue recense des vulnérabilités pour lesquelles il existe des preuves d’exploitation réelle. 222

Les informations publiques confirment une activité de sondage et d’exploitation, mais n’attribuent pas les faits à un acteur unique, ne fournissent pas de nombre fiable de victimes et ne démontrent pas une chaîne de compromission identique dans tous les cas. L’absence de signalement d’incident connu ne doit donc pas être interprétée comme la preuve qu’un serveur exposé n’a pas été visé.

Considérez les instances exposées comme un risque de fuite de secrets

L’installation du correctif bloque le comportement vulnérable, mais n’annule pas la lecture de données qui aurait déjà eu lieu. Pour un serveur concerné et accessible depuis Internet, conservez les éléments de preuve et évaluez ce que le compte de service GitLab pouvait lire avant de lancer un nettoyage généralisé.

À examiner puis à renouveler en priorité :

• les secrets applicatifs et de configuration GitLab ;
• les identifiants de base de données, Redis, stockage objet, registre, SMTP, annuaire et fournisseur d’identité présents dans la configuration ;
• les variables CI/CD, jetons de déploiement, jetons d’accès, jetons de runners, clés de déploiement et identifiants montés pour les tâches ou intégrations ;
• les clés cloud, identifiants de registres de paquets, clés de signature et clés privées SSH ou TLS accessibles depuis l’hôte ou par le processus GitLab.

Cette rotation doit être préparée : modifier des secrets applicatifs ou des paramètres liés au chiffrement peut invalider des sessions et perturber des paramètres chiffrés ou des intégrations. Conservez d’abord les journaux et les éléments de configuration utiles, préparez un plan de retour arrière, puis faites pivoter les secrets les plus sensibles selon une séquence maîtrisée.

Détection : quels journaux examiner ?

Un premier indicateur utile est une requête HTTP POST vers le chemin de l’API Repository Commits :

/api/v4/projects/<id>/repository/commits/

Les signalements recommandent spécifiquement de rechercher les requêtes contenant le paramètre file.path. Analysez les journaux du proxy inverse, du répartiteur de charge, du WAF et des accès GitLab Rails afin d’identifier des requêtes non authentifiées inhabituelles, des entrées encodées évoquant une traversée de répertoires, des identifiants de projet inattendus, des échecs répétés, des tentatives d’énumération ou des tailles de réponse anormales. 212426

Examinez également l’activité possiblement liée après la fenêtre d’exposition présumée : nouveaux jetons ou jetons utilisés, enregistrements de runners, changements dans les variables CI/CD ou les définitions de pipelines, imports inhabituels, activité GraphQL et connexions sortantes inattendues. Les recommandations publiées autour de cette mise à jour conseillent aussi de revoir les commits, les abonnements GraphQL, les imports de projets et les pipelines CI/CD. 23

L’absence de résultat dans les journaux ne constitue pas une preuve d’absence d’exploitation : la conservation des logs peut être limitée, les journaux applicatifs peuvent ne pas contenir le détail de la requête concernée, et les traces du proxy ou du WAF peuvent être les seules disponibles.

Mesures temporaires si la mise à jour est retardée

La mise à niveau reste la correction nécessaire. Si une mise à jour d’urgence est momentanément impossible, réduisez l’exposition en limitant l’accès aux services web et API GitLab à un VPN ou à des réseaux autorisés. Une règle de proxy inverse ou de WAF restreignant très précisément la route Repository Commits vulnérable peut réduire le risque à court terme, mais elle peut perturber des automatisations légitimes et ne remplace pas le correctif.

Pour chaque serveur concerné, la séquence pratique est la suivante :

1. Recenser et prioriser les instances autogérées accessibles de l’extérieur.
2. Mettre à jour vers 19.1.8, 19.2.6, 19.3.2 ou une version plus récente.
3. Vérifier la version réellement en cours d’exécution après l’intervention.
4. Conserver puis examiner les journaux à la recherche d’indicateurs d’exploitation.
5. Faire pivoter les secrets potentiellement exposés selon les accès du serveur et les conséquences métier.

Les autres vulnérabilités corrigées dans cette publication

Les rapports de sécurité évoquent également deux vulnérabilités propres à Enterprise Edition corrigées dans la même publication :

• CVE-2026-87719 : une désérialisation non sécurisée nécessitant une authentification, notée CVSS 9,9, associée dans certains signalements à l’exposition de la configuration et des identifiants d’Advanced Search. 6
• CVE-2026-88765 : un risque d’exécution de code à distance nécessitant une authentification lors de l’import d’une exportation de projet Git conçue de manière malveillante, noté CVSS 8,5. 625

Ces failles n’ont pas les mêmes prérequis ni les mêmes effets que CVE-2026-85706. Pour les installations GitLab autogérées et exposées, la vulnérabilité de lecture de fichiers sans authentification, déjà activement exploitée, doit rester la priorité de confinement et de réponse à incident.