Une faille d'une gravité maximale dans GitLab expose les serveurs auto-hébergés à des lectures de fichiers arbitraires

Une vulnérabilité de sécurité critique, classée au niveau de gravité maximal, a été identifiée dans les instances auto-gérées des logiciels Community Edition et Enterprise Edition de GitLab. Elle permet à des attaquants distants non authentifiés de lire des fichiers arbitraires stockés sur les serveurs d'hébergement vulnérables. Selon les informations publiées par Taryn Plumb le 15 septembre 2026, les réseaux de surveillance de la sécurité ont déjà détecté des activités d'analyse et de balayage actives menées par des acteurs malveillants cherchant à découvrir des déploiements exposés et non corrigés sur l'Internet public. Cette faille de sécurité constitue une menace immédiate pour les environnements de développement logiciel des entreprises, car un accès non authentifié à la divulgation de fichiers peut permettre à des adversaires de récupérer des fichiers de configuration système, des identifiants de bases de données, des jetons d'accès API et du code source propriétaire, sans posséder de compte utilisateur légitime.

## Faits marquants - Une vulnérabilité de gravité maximale affecte les instances auto-gérées de GitLab Community Edition (CE) et Enterprise Edition (EE). - La faille offre un chemin non authentifié permettant à des attaquants distants d'effectuer des lectures de fichiers arbitraires sur le système de fichiers hôte. - Les services de surveillance de la cybersécurité ont enregistré des tentatives actives de balayage dans la nature ciblant les serveurs exposés sur Internet. - Les organisations exploitant des déploiements auto-hébergés doivent appliquer immédiatement les mises à jour de sécurité ou mettre en œuvre les contrôles d'accès réseau recommandés. - L'exposition de fichiers de serveurs sous-jacents dans un hôte d'intégration continue et de déploiement continu (CI/CD) peut compromettre les environnements cloud intégrés et les chaînes de distribution de logiciels.

## Ce qui s'est passé La faille de sécurité nouvellement divulguée cible les installations auto-gérées de GitLab, la plateforme très répandue de gestion de référentiels basée sur le Web et de DevOps. Selon les informations de Taryn Plumb, la faille a été classée au niveau de gravité le plus élevé en raison de son faible niveau de complexité d'exploitation et de l'étendue de l'accès qu'elle accorde aux utilisateurs non autorisés. Plus précisément, la vulnérabilité contient un chemin non authentifié qui permet à un utilisateur distant de demander et de consulter des fichiers arbitraires stockés sur le système de fichiers local du serveur.

Dans une architecture d'application Web classique, une validation stricte des entrées et des mécanismes de contrôle d'accès empêchent les requêtes Web externes de naviguer en dehors des répertoires publics désignés. Lorsqu'une faille de lecture de fichiers arbitraires survient, un attaquant peut manipuler les points d'accès ou les paramètres de l'application pour traverser les structures de répertoires — une technique historiquement connue sous le nom de traversée de répertoires (path traversal) ou d'inclusion de fichiers locaux (local file inclusion). Cela permet à l'attaquant de contourner les points de contrôle d'authentification et de forcer le processus applicatif à renvoyer des fichiers système sensibles au demandeur.

La télémétrie sur le renseignement sur les menaces indique que les acteurs malveillants n'ont pas attendu le déploiement généralisé des correctifs avant de lancer des opérations de reconnaissance. Comme le rapporte Taryn Plumb, des scripts de balayage automatisés et des sondes d'exploitation recherchent activement dans l'espace d'adresses IPv4 les points d'accès GitLab auto-gérés vulnérables. Ces sondes ciblent généralement des routes Web spécifiques afin de vérifier si une instance répond avec des identifiants de serveur ou des contenus de fichiers caractéristiques d'une version non corrigée. La vulnérabilité ne nécessitant aucune authentification, un attaquant peut lancer des scripts automatisés à grande échelle, cartographiant les installations vulnérables sans avoir besoin d'identifiants de connexion valides, de cookies de session ou d'un accès préalable au réseau de l'organisation cible.

## Pourquoi c'est important Les serveurs d'intégration continue et de déploiement continu (CI/CD) occupent une position particulièrement privilégiée au sein des réseaux d'entreprise modernes. En tant que moteur central pour l'automatisation de la création, du test et du déploiement de logiciels, un serveur GitLab stocke ou accède fréquemment à de nombreux identifiants opérationnels. Une vulnérabilité de lecture de fichiers arbitraires non authentifiée sur un tel serveur crée un vecteur de violation catastrophique qui s'étend bien au-delà du seul logiciel de gestion de référentiels.

Grâce à un accès en lecture de fichiers arbitraires, un adversaire peut extraire des fichiers de configuration système critiques, notamment les fichiers de secrets internes de GitLab (`gitlab-secrets.json`), les chaînes de connexion aux bases de données, les clés privées SSH et les variables d'environnement contenant des identifiants de services tiers. L'exposition de la clé secrète principale de l'application permet aux attaquants de forger des jetons de session, de déchiffrer les variables d'environnement stockées et d'usurper l'identité d'utilisateurs administrateurs. De plus, la lecture de fichiers de configuration système tels que `/etc/passwd` ou les définitions d'environnement de conteneurs peut fournir des informations clés sur l'architecture de l'OS hôte et la topologie du réseau adjacent.

Au-delà des secrets d'administration système, les plateformes CI/CD hébergent du code source propriétaire et de la propriété intellectuelle. L'accès aux fichiers bruts du référentiel sur le disque permet l'espionnage commercial, le vol de propriété intellectuelle et l'identification de vulnérabilités logicielles secondaires au sein de la base de code interne d'une organisation. Plus critique encore, la compromission d'un serveur de compilation (build) porte atteinte à l'intégrité de la chaîne d'approvisionnement logicielle. Si un attaquant exploite des identifiants volés ou un accès administratif obtenu par lecture de fichiers pour altérer des scripts de build ou des référentiels de code, il peut injecter des portes dérobées malveillantes dans les produits logiciels en aval distribués aux clients externes ou déployés sur l'infrastructure de l'entreprise.

Pour les équipes de cybersécurité et les administrateurs informatiques, la transition rapide entre la divulgation de la vulnérabilité et son exploitation active dans la nature élimine tout délai de grâce standard pour la gestion des correctifs. Les organisations qui ne parviennent pas à isoler ou à mettre à jour immédiatement les instances auto-gérées exposées s'exposent à une forte probabilité de compromission automatisée.

## Contexte GitLab, développé par GitLab Inc., est l'un des outils DevOps les plus largement adoptés au monde, offrant la gestion du code source, le suivi des tickets et des pipelines CI/CD automatisés. Le logiciel est distribué principalement selon deux modèles de déploiement : une plateforme SaaS (Software-as-a-Service) hébergée dans le cloud directement sur GitLab.com, et des installations auto-gérées déployées sur des infrastructures appartenant aux clients, des machines virtuelles cloud ou des réseaux d'entreprise isolés (air-gapped). Les déploiements auto-gérés sont proposés dans les versions open source Community Edition (CE) et commerciale Enterprise Edition (EE), qui partagent un socle de code commun.

L'infrastructure CI/CD auto-hébergée est particulièrement populaire auprès des établissements de santé, des services financiers, des entreprises du secteur de la défense et des agences gouvernementales opérant sous des cadres stricts de souveraineté des données, de confidentialité ou de conformité réglementaire qui interdisent l'hébergement de code propriétaire sur des plateformes cloud publiques. Cependant, la charge opérationnelle liée à la gestion, à la surveillance et à l'application des correctifs des serveurs auto-hébergés incombe entièrement aux équipes internes des opérations informatiques et de sécurité.

Historiquement, les vulnérabilités de gravité maximale dans GitLab ont suscité une exploitation immédiate et agressive par divers acteurs de la menace, allant des groupes de rançongiciels aux groupes de menaces persévérantes avancées (APT) soutenus par des États. Par exemple, en 2021, une vulnérabilité d'exécution de code à distance de gravité maximale désignée CVE-2021-22205 a été largement exploitée pour prendre le contrôle de serveurs non corrigés et les intégrer à des réseaux de botnets pour attaques par déni de service distribué (DDoS) ou le minage de cryptomonnaies. Plus récemment, début 2024, une vulnérabilité critique de prise de contrôle de compte suivie sous le nom de CVE-2023-7028 — affichant un score CVSS (Common Vulnerability Scoring System) de 10,0 — a provoqué des avis d'urgence de la CISA (Cybersecurity and Infrastructure Security Agency) à la suite de tentatives massives et automatisées de réinitialisation de mots de passe observées à l'échelle mondiale.

Selon le système de notation des vulnérabilités CVSS (CVSS v3.1/v4.0), une note de gravité maximale de 10,0 indique qu'une vulnérabilité est exploitable via le réseau sans interaction de l'utilisateur, qu'elle ne nécessite aucun privilège particulier et qu'elle présente des risques graves pour la confidentialité, l'intégrité et la disponibilité. Bien qu'une vulnérabilité de lecture de fichiers arbitraires impacte directement la confidentialité, les chercheurs en sécurité combinent fréquemment ces capacités de lecture avec des mécanismes logiciels existants pour exécuter du code à distance (RCE), transformant ainsi un bug de divulgation d'informations en prise de contrôle totale du serveur.

## Réactions La nouvelle des balayages actifs dans la nature a déclenché des avertissements de sécurité urgents au sein de la communauté de la cybersécurité et des groupes d'opérations DevOps. Il est conseillé aux administrateurs système gérant des infrastructures GitLab auto-hébergées d'examiner immédiatement les journaux d'accès à la recherche de requêtes HTTP anormales ciblant des ressources statiques ou des points d'accès de configuration, en particulier les requêtes affichant des séquences de traversée de répertoires comme `../` ou des schémas d'encodage d'URI inattendus.

Les équipes d'opérations de sécurité priorisent la restriction de l'accès réseau public aux déploiements GitLab auto-gérés. Les meilleures pratiques du secteur préconisent de placer les interfaces d'administration et les plateformes d'hébergement de référentiels derrière des contrôles de défense périmétrique, tels que des pare-feux d'applications Web (WAF), des passerelles d'accès réseau Zero Trust (ZTNA) ou des réseaux privés virtuels (VPN), pour empêcher le trafic Internet non authentifié d'interagir directement avec les ports d'application bruts.

Bien que les réponses officielles des victimes individuelles d'entreprises n'aient pas été détaillées publiquement, des procédures de mise à jour d'urgence sont activées dans les centres d'opérations de sécurité (SOC) des entreprises. Les analystes de sécurité soulignent que l'application des correctifs de sécurité officiels du fournisseur reste la seule atténuation complète, car les règles de pare-feu d'application Web et les politiques de filtrage de chemin peuvent fréquemment être contournées par de nouvelles techniques d'encodage.

## Ce que l'on ne sait pas encore Plusieurs détails techniques et opérationnels concernant cette faille de gravité maximale restent non confirmés dans les rapports disponibles. L'identifiant spécifique CVE (Common Vulnerabilities and Exposures) attribué pour suivre cette faille n'a pas été explicitement détaillé dans les premiers rapports, tout comme l'éventail complet des numéros de version sémantique affectés pour les versions CE et EE de GitLab.

Il reste difficile de déterminer si des chercheurs en sécurité ou des acteurs de la menace ont réussi à combiner cette faille de lecture de fichiers arbitraires avec d'autres fonctionnalités d'application pour obtenir une exécution complète de code à distance sur les systèmes cibles. De plus, bien que des balayages actifs dans la nature aient été observés, les rapports n'attribuent pas actuellement l'activité de balayage à des groupes de menaces connus ou à des entités d'espionnage cybernétique liées à des États. La répartition géographique complète et la ventilation par secteur d'activité des serveurs compromis ou sondés restent également inconnues dans l'attente de rapports de télémétrie plus larges émanant de sociétés de réponse aux incidents de cybersécurité.

## À surveiller Dans les prochains jours, plusieurs indicateurs critiques détermineront la trajectoire et l'impact global de cette menace de sécurité : - La publication d'avis de sécurité détaillés du fournisseur et de correctifs officiels par GitLab Inc., précisant les numéros de version corrigés pour les branches CE et EE. - La publication d'analyses détaillées des causes profondes et de code d'exploitation de preuve de concept (PoC) par des chercheurs en sécurité indépendants, ce qui accélère généralement l'exploitation automatisée par des acteurs de menaces moins qualifiés. - L'inclusion potentielle de la vulnérabilité dans le catalogue des vulnérabilités exploitées connues (KEV) de la Cybersecurity and Infrastructure Security Agency (CISA), déclenchant des délais de correction obligatoires pour les agences gouvernementales civiles fédérales des États-Unis. - La surveillance des divulgations d'incidents d'entreprise pour déterminer si des violations majeures de la chaîne d'approvisionnement logicielle ou des fuites d'identifiants résultent de serveurs non corrigés exposés pendant la fenêtre initiale de balayage.

Ce compte rendu intègre des éléments d'information initialement publiés par Taryn Plumb.