if ( !emtpy($headline_subheadline ) ) : ?>
La vulnérabilité affecte les instances CE et EE autogérées et fournit un chemin non authentifié vers des lectures de fichiers arbitraires. Il est déjà testé dans la nature.
endif; ?>
Une autre vulnérabilité de sécurité a été découverte dans l’infrastructure GitLab, celle-ci ayant une gravité parfaite de 10.
CVE-2026-85706, la deuxième faille révélée par GitLab en seulement un mois, est une vulnérabilité de gravité maximale qui permet aux attaquants de lire des fichiers arbitraires dans une seule requête HTTP. La faille de traversée du chemin résulte d’un confinement inapproprié et d’un manque d’application de l’authentification dans l’API de validation du référentiel GitLab, a rapporté la société.
Les acteurs malveillants pourraient l’exploiter « sous certaines conditions » et lire des fichiers arbitraires (identifiants, secrets et autres données sensibles) sur les serveurs GitLab vulnérables.
La société a corrigé la vulnérabilité, qui affecte GitLab Community Edition (CE) et Enterprise Edition (EE), et a conseillé aux clients disposant d’instances GitLab auto-hébergées publiques de mettre immédiatement à jour leurs serveurs ou de supprimer l’accès public.
Les experts estiment que cette faille est alarmante, car la plateforme DevSecOps de GitLab est utilisée par environ 50 % des sociétés Fortune 100 et compte plus de 50 millions d’utilisateurs enregistrés.
« GitLab n’est pas simplement un référentiel de code source », a noté Safayat Moahamad, directeur consultatif chez Info-Tech Research Group. Dans de nombreuses entreprises, il est connecté pour créer des pipelines, des processus de déploiement, des flux de travail de sécurité des applications et d’autres systèmes fiables.
En conséquence, un accès non autorisé aux fichiers de configuration, aux secrets ou aux informations d’identification sur le serveur GitLab pourrait « avoir des conséquences bien au-delà de l’instance affectée », a-t-il déclaré.
N’attendez pas le cycle de patch normal
GitLab a été une cible privilégiée des pirates informatiques ces derniers temps : en janvier, il a corrigé une faille de haute gravité qui permettait aux attaquants possédant l’identifiant de compte d’une cible de contourner l’authentification à deux facteurs, et en août, il a corrigé une vulnérabilité critique qui pourrait donner aux utilisateurs non authentifiés la possibilité d’apporter des modifications dans les référentiels de code ou même de les supprimer complètement avec une seule requête HTTP.
Le bogue actuel de gravité maximale, CVE-2026-85706, a été signalé via le programme de primes de bogues HackerOne de GitLab. Cela affectait les versions CE et EE 18.7 avant 19.1.8, 19.2 avant 19.2.6 et 19.3 avant 19.3.2.
L’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté CVE-2026-85706 à son catalogue de vulnérabilités exploitées connues, notant que ce type de vulnérabilité est un vecteur d’attaque fréquent pour les cyberacteurs malveillants et présente particulièrement des risques importants pour l’entreprise fédérale ; watchTowr Intel a signalé qu’il observait déjà des «sondes sauvages». « Sur la base des récentes vulnérabilités de GitLab, nous savons que le moment où une exploitation aveugle n’est probablement pas loin », prévient-il.
Il ne s’agit pas d’une vulnérabilité que les organisations devraient laisser au cycle normal de mise à jour des correctifs, a souligné Moahamad. « Il offre un chemin non authentifié vers des fichiers arbitraires sur une plate-forme qui se trouve fréquemment au centre des flux de travail du code source, de la construction et du déploiement », a-t-il déclaré.
Les entreprises doivent appliquer immédiatement les correctifs, rechercher les activités suspectes de l’API de validation du référentiel et déterminer si les fichiers exposés contiennent des informations d’identification ou des secrets qui pourraient désormais nécessiter une rotation, a-t-il conseillé.
Au-delà des correctifs, l’équipe watchTowr Intel a déclaré que les défenseurs devraient essayer d’identifier les tentatives d’exploitation en recherchant dans les fichiers journaux les requêtes HTTP POST adressées aux « » URI contenant des « » paramètres.
Les plateformes CI/CD sont une infrastructure de confiance essentielle
Les organisations qui exécutent des instances GitLab CE ou EE autogérées concernées devraient être les plus concernées, a noté Moahamad. Le risque augmente lorsque GitLab est connecté à des référentiels sensibles, des pipelines CI/CD, des environnements cloud ou des processus de déploiement en production.
Les informations et/ou l’accès que les attaquants pourraient obtenir dépendent de ce que le service GitLab peut lire et de ce que les organisations stockent sur le serveur, a-t-il expliqué. Il peut inclure des fichiers de configuration, des secrets, des informations d’identification et d’autres données sensibles côté serveur. Si ces fichiers contiennent des jetons, des clés ou des informations d’identification utilisables, un attaquant pourrait tenter d’accéder à l’infrastructure connectée.
« La faille crée directement un risque d’accès non autorisé aux fichiers », a-t-il déclaré. Le vol d’identifiants, les mouvements latéraux, l’exposition du code source et la compromission de la chaîne d’approvisionnement sont des scénarios de suivi possibles.
Le code source et les plateformes CI/CD doivent être gouvernés comme une « infrastructure de confiance critique », a-t-il déclaré. Même si l’application de correctifs reste essentielle, la résilience dépendra de la connaissance des emplacements où les plates-formes peuvent être exposées, de la limitation de ce à quoi elles peuvent accéder, de la détection des comportements anormaux des API et de la mise en place d’un processus testé pour enquêter et alterner les informations d’identification.
David Shipley de Beauceron Security a décrit deux facteurs entrant en collision pour générer une « douleur maximale » pour les utilisateurs de GitLab.
Le premier est la vulnérabilité. « C’est un 10 pour une raison : un accès en lecture non authentifié au code source du client GitLab », a-t-il déclaré.
Deuxièmement, cela fait particulièrement mal parce que les développeurs ont encore de mauvaises habitudes : beaucoup trop de code continue d’être expédié ou est en production avec des clés SSH intégrées, des secrets cloud, des jetons et d’autres données précieuses que les attaquants peuvent utiliser pour accéder à l’infrastructure, a déclaré Shipley.
« Donc, pour les attaquants, vous avez les classiques », a-t-il noté : l’exfiltration et l’extorsion de données, les ransomwares, le détournement d’infrastructures cloud pour le minage de cryptomonnaies, et le vol de jetons et d’infrastructures d’IA pour permettre d’autres activités criminelles.
« Ce niveau de vulnérabilité est l’équivalent du code et du cloud de la possibilité d’obtenir le numéro de carte de crédit, l’expiration et le numéro de sécurité », a déclaré Shipley. « Cela ouvre un monde d’achat de données criminelles. »
L’essentiel : « Éliminez ces secrets du code de production et adoptez les meilleures pratiques modernes d’authentification par codage », a-t-il conseillé.
