La faille de traversée de chemin parfaite de GitLab est déjà sondée dans la nature

GitLab a corrigé une vulnérabilité de gravité maximale qui permet à un attaquant non authentifié de lire des fichiers arbitraires sur un serveur GitLab auto-hébergé, et environ un jour après la publication du correctif, les chercheurs en sécurité observaient déjà des tentatives pour trouver des instances non corrigées sur l'internet public.

À lire aussi: La faille zero-day de Fortinet sur FortiMail permet aux attaquants d'écrire des fichiers sans se connecter · Google corrige CVE-2026-58704, une faille zero-day du modem des Pixel exploitée activement.

Le bug, suivi sous la référence CVE-2026-85706, porte un score CVSS de 10,0, le sommet de l'échelle. Il s'agit d'un problème de traversée de chemin dans l'API des commits de dépôt, et la description de GitLab lui-même est sans détour sur la cause : « confinement de chemin incorrect et absence d'application de l'authentification » dans ce point de terminaison. En pratique, cela signifie qu'un attaquant capable d'atteindre le serveur par le réseau n'a besoin d'aucun compte, d'aucun jeton et d'aucune interaction de l'utilisateur pour lui demander des fichiers qu'il n'aurait jamais dû distribuer.

GitLab a livré des correctifs dans les versions 19.1.8, 19.2.6 et 19.3.2, et a demandé à ses clients auto-hébergés de mettre à jour immédiatement. « Ces versions contiennent d'importants correctifs de bogues et de sécurité, et nous recommandons vivement que toutes les installations GitLab auto-hébergées soient mises à niveau vers l'une de ces versions immédiatement », a écrit l'entreprise dans ses notes de version correctives. GitLab a indiqué que son propre service hébergé, GitLab.com, exécutait déjà le code corrigé, et que les clients GitLab Dedicated n'avaient pas besoin d'agir, ce qui concentre l'exposition parmi les organisations qui exploitent GitLab sur leur propre infrastructure.

Pourquoi une faille de lecture de fichiers vaut 10,0

Il est tentant de considérer « lire des fichiers arbitraires » comme un problème moindre qu'une exécution de code à distance. Dans le contexte d'une plateforme qui stocke du code source, des définitions de pipelines, des clés de déploiement et des jetons d'accès, la distinction s'effondre. Un fichier lisible depuis un serveur GitLab héberge exactement le matériel dont un intrus a besoin pour passer d'une requête réseau anonyme au contrôle de la chaîne d'approvisionnement logicielle : identifiants d'administrateur, secrets CI/CD, chaînes de connexion aux bases de données, clés de signature et jetons d'API qui permettent aux systèmes automatisés de pousser du code ou de modifier des pipelines.

Le vecteur CVSS explique pourquoi la faille atteint le plafond. Elle est exploitable par le réseau (AV:N), de faible complexité (AC:L), ne nécessite aucun privilège (PR:N) ni interaction de l'utilisateur (UI:N), et elle a une portée modifiée (S:C), la vulnérabilité dans un composant permet à un attaquant d'affecter des ressources au-delà. La confidentialité et l'intégrité sont toutes deux évaluées comme élevées.

La section des versions affectées de l'avis de GitLab est inhabituellement large. Tout, de la version 18.7 jusqu'aux versions corrigées, est touché : les versions GitLab Community Edition et Enterprise Edition antérieures à 19.1.8 sur la branche 19.1, antérieures à 19.2.6 sur la 19.2, et antérieures à 19.3.2 sur la 19.3. Cela représente une grande partie de toutes les installations auto-hébergées qui ont été maintenues raisonnablement à jour au cours de l'année écoulée.

Le correctif de GitLab est arrivé aux côtés de plusieurs autres correctifs de sécurité dans la même version, dont un problème critique de désérialisation non sécurisée dans le sérialiseur d'abonnements GraphQL affectant Enterprise Edition, et un ensemble de failles de gravité élevée couvrant un débordement de tampon, une erreur d'autorisation de portée de variable CI/CD et deux failles de déni de service dans la limitation de complexité GraphQL. La traversée de chemin est celle qui a fixé le calendrier, parce qu'elle était exploitable avant authentification.

Le chercheur qui l'a signalée l'a fait via le programme de bug bounty de GitLab sur HackerOne, sous le pseudonyme « s3ntago », selon BleepingComputer. Cela compte pour les défenseurs de manière pratique : parce que la faille a été divulguée de manière responsable, les correctifs existaient avant que les détails ne deviennent publics, ce qui fait la différence entre une course au correctif et une déroute.

La fenêtre de sondage s'est mesurée en heures

Cela n'est pas resté discret longtemps. La société de sécurité watchTowr, qui exploite un réseau de capteurs dédiés à l'exploitation émergente, a déclaré avoir commencé à voir des tentatives réelles de localisation de serveurs GitLab vulnérables presque immédiatement après l'avis.

« Vu l'historique, la transition de cette vulnérabilité vers une exploitation massive et indiscriminée n'est probablement pas loin, et les défenseurs ont peu de temps pour agir », a déclaré Ben Knott, de watchTowr, dans des propos rapportés par The Hacker News. La société a publié une signature de détection pour les défenseurs : recherchez les requêtes HTTP POST vers des URI de la forme /api/v4/projects/{id}/repository/commits/ qui transportent un paramètre file.Path, la forme que prend une requête d'exploitation.

Au 11 septembre, la CISA avait ajouté CVE-2026-85706 à son catalogue des vulnérabilités exploitées connues, ce qui impose aux agences fédérales civiles une date limite contraignante pour corriger ou documenter des contrôles compensatoires. L'inscription au KEV est le signal public le plus fort, à défaut d'une confirmation du fournisseur, qu'un bug est utilisé plutôt que simplement étudié.

L'écart entre la divulgation et le sondage se mesure désormais en heures plutôt qu'en semaines, et cette compression est elle-même l'histoire des bugs d'infrastructure les plus graves de 2026. Les attaquants automatisent de plus en plus la recherche de failles fraîchement divulguées, de sorte que la question utile n'est pas de savoir si un bug sera ciblé, mais à quelle vitesse une organisation donnée peut inventorier, corriger et vérifier ses systèmes exposés. Pour les opérateurs de GitLab, le problème d'inventaire est plus vaste qu'il n'y paraît : une seule organisation peut exploiter de nombreuses instances auto-hébergées (déploiements régionaux, clusters de préproduction, serveurs dédiés à un projet) et un scanner de vulnérabilités qui ne couvre que l'instance de production principale manquera les copies qui comptent.

Répondre à CVE-2026-85706

Le chemin de remédiation est simple dans les grandes lignes et exigeant dans l'exécution. Mettez à niveau les instances auto-hébergées vers 19.1.8, 19.2.6 ou 19.3.2 sur la branche correspondante, ou vers une version ultérieure. Lorsqu'une mise à niveau immédiate est impossible, restreignez l'accès réseau à l'API des commits de dépôt et à l'instance GitLab en général, puisque la faille exige que l'attaquant atteigne directement le serveur.

Parce que la vulnérabilité est un problème de lecture de fichiers, corriger et oublier n'est pas une réponse complète. Les serveurs GitLab détiennent couramment des identifiants qui survivent à une mise à jour logicielle : jetons d'accès personnels, jetons de tâches CI/CD, clés de déploiement, éléments de known_hosts et contenu des fichiers de configuration. Les équipes de sécurité qui avaient une instance exposée à internet dans la plage affectée pendant la fenêtre d'exposition devraient renouveler les identifiants accessibles depuis le système de fichiers et examiner les journaux d'accès de GitLab à la recherche de requêtes inhabituelles sur l'API des commits. Les conseils de détection de watchTowr constituent une requête de départ raisonnable, mais l'absence de lignes de journal correspondantes n'est pas une preuve de sécurité, les journaux tournent, et un attaquant prudent ne lit rien qui se démarquerait.

Il y a un point de gouvernance sous le point technique. La raison pour laquelle un 10,0 dans une plateforme de code source compte davantage qu'un 10,0 dans une application périphérique est que GitLab auto-hébergé est souvent la racine de confiance de la chaîne de build d'une organisation. Tout ce qu'un attaquant peut y lire est, par conception, suffisant pour modifier le logiciel auquel tout le monde en aval fait confiance. Traiter ce système comme une installation de confort plutôt que comme une frontière de sécurité critique, voilà l'erreur que cette vulnérabilité expose.

Le schéma plus large

CVE-2026-85706 s'inscrit dans une saison chargée de failles critiques dans l'infrastructure des développeurs et de l'informatique. En quelques semaines, les organisations ont été invitées à corriger une faille d'enchaînement de jetons dans JFrog Artifactory qui pouvait transformer une requête anonyme en jeton d'administrateur, une paire de bugs de pré-authentification dans le noyau de SAP et le serveur de messagerie NetWeaver, une faille dans le chemin de prévente des serveurs de gestion d'impression PaperCut, et un zero-day critique dans la plateforme de gestion à distance N-central de N-able. Le fil conducteur est que le logiciel vulnérable se trouve à l'intérieur du périmètre, détenant souvent les clés de tout ce qui se trouve derrière, et qu'il n'est fréquemment pas corrigé au même rythme que les applications exposées à internet qui attirent davantage l'attention.

La raison pour laquelle ces bugs se regroupent est structurelle. Les plateformes de développement et d'informatique sont conçues pour être dignes de confiance de tout ce qui les entoure : elles détiennent des identifiants, elles se trouvent à l'intérieur du réseau, et elles sont généralement administrées par une petite équipe déjà surchargée. Cette combinaison les rend attractives comme cibles et lentes à corriger, car une mise à niveau peut casser un pipeline de build ou une intégration d'authentification que personne ne veut toucher. CVE-2026-85706 supprime même l'excuse de la nécessité d'identifiants pour commencer, la seule condition préalable est l'accessibilité réseau, précisément la propriété qui rend un serveur GitLab utile à une équipe d'ingénierie distribuée.

Il y a aussi un problème de mesure. Les organisations ont tendance à savoir combien d'instances GitLab elles exploitent délibérément, et à avoir une image beaucoup plus floue de celles qui existent parce qu'une équipe en a lancé une pour un projet ou qui ont été créées il y a des années et jamais retirées. Les services de balayage à l'échelle d'internet rendent trivial pour un attaquant de trouver ces serveurs oubliés; la même visibilité qui permet à une équipe de sécurité d'auditer son exposition alimente aussi les scanners qui la visent. La leçon pratique des dernières semaines est que la gestion des correctifs pour l'infrastructure des développeurs internes doit être aussi agressive que pour la périphérie exposée au public, et que l'inventaire des actifs (savoir ce que l'on exploite réellement) est la partie difficile.

Pour les défenseurs, l'ordre d'opérations raisonnable consiste à corriger, puis à vérifier que le correctif a pris sur chaque instance, puis à enquêter sur la fenêtre durant laquelle un serveur non corrigé était accessible. Les identifiants qui ont touché le système de fichiers d'une instance exposée doivent être considérés comme suspects jusqu'à leur renouvellement, et les journaux doivent être examinés à la recherche du motif file.Path publié par watchTowr. Rien de tout cela ne garantit un bilan de santé impeccable, mais c'est la différence entre répondre à un bug connu et découvrir des mois plus tard qu'il était la première étape d'une intrusion plus longue.

Pour GitLab spécifiquement, la date limite pratique, c'est maintenant. Le correctif est disponible, l'exploitation a commencé, et le coût du retard se mesure en identifiants qui ne peuvent pas être renouvelés aussi vite qu'un serveur peut être mis à niveau. Les organisations devraient confirmer leur version, vérifier leur exposition et présumer que toute instance laissée ouverte pendant la fenêtre mérite une enquête, non pas parce qu'une compromission est certaine, mais parce que la preuve d'une telle compromission serait discrète, et les conséquences de la manquer ne le seraient pas.

Image de couverture : composite original de TechPastWeek utilisant le logo GitLab (GitLab Inc., licence MIT).