Une vulnérabilité dans GitLab Ultimate Enterprise Edition, utilisé pour la gestion du code source, est « dangereuse » et doit être corrigée rapidement, selon un expert. La faille, CVE-2025-5121, est l'une des 10 décrites récemment par GitLab lors de la publication de correctifs de bogues et de sécurité pour les installations autogérées. « Nous recommandons vivement à tous les utilisateurs d'installations GitLab autogérées de mettre à jour immédiatement leur version vers l'une des versions corrigées [18.0.2, 17.11.4, 17.10.8] », a déclaré la plateforme. GitLab.com utilise déjà la version corrigée, les clients GitLab Dedicated n'ont donc aucune mesure à prendre.
4 failles classées haute gravité
Johannes Ullrich, doyen de la recherche au SANS Institute, s'est montré particulièrement inquiet au sujet de la faille CVE-2025-5121, un problème d'autorisation manquante. Il l'a qualifié de « dangereux ». Si elle n'est pas corrigée, dans certaines conditions, elle peut permettre à un pirate informatique disposant d'un accès authentifié à une instance GitLab avec une licence GitLab Ultimate (client payant ou essai) d'injecter une tâche CI/CD malveillante dans tous les pipelines CI/CD de n'importe quel projet. « En injectant une tâche malveillante, un pirate informatique serait en mesure de compromettre la manière dont le logiciel est construit », a déclaré M. Ullrich à CSO. « Cela pourrait notamment inclure l'ajout de portes dérobées au logiciel ou le contournement de certaines étapes de validation. Le code aurait également accès aux secrets utilisés pendant le processus de construction. »
Les versions concernées sont GitLab Ultimate EE 17.11 antérieures à la version 17.11.4 et 18.0 antérieures à la version 18.0.2. Cette vulnérabilité a reçu une note CVSS de 8,5. L'autre vulnérabilité sur laquelle M. Ullrich a attiré l'attention est la CVE-2025-4278, une faille d'injection HTML. Il l'a décrite comme une vulnérabilité de type « cross site scripting », mais avec un impact plus limité. GitLab lui attribue un score CVSS de 8,7. « L'impact de ces vulnérabilités est souvent difficile à évaluer », a déclaré M.Ullrich, « mais des attaquants créatifs sont souvent capables de les exploiter pour inciter les utilisateurs à effectuer des actions dangereuses pour le compte de l'attaquant. » GitLab indique que, sans correctif, dans certaines conditions, cette faille permettrait à un attaquant de prendre le contrôle d'un compte en injectant du code dans la page de recherche.
Toutes les instances de la version 18.0 antérieures à la version 18.0.2 des éditions Community et Enterprise sont concernées. Les deux autres vulnérabilités classées comme élevées sont les suivantes :
- CVE-2025-2254, un problème de cross-site scripting qui, dans certaines conditions, pourrait permettre à un attaquant d'agir comme un utilisateur légitime en injectant un script malveillant dans la visionneuse d'extraits.
- Toutes les versions GitLab CE/EE de 17.9 avant 17.10.8, 17.11 avant 17.11.4 et 18.0 avant 18.0.2 sont concernées ;
- CVE-2025-0673, une vulnérabilité pouvant entraîner un déni de service en déclenchant une boucle de redirection infinie, ce qui provoquerait l'épuisement de la mémoire sur le serveur GitLab. Les versions concernées de GitLab CE/EE sont les versions 17.7 antérieures à 17.10.8, 17.11 antérieures à 17.11.4 et 18.0 antérieures à 18.0.2.
3 failles de déni de service sont répertoriées avec un niveau de risque moindre.
CVE-2025-1516, si elle n'est pas corrigée, permet à un attaquant de bloquer l'accès aux utilisateurs légitimes du système ciblé en générant des jetons avec des noms suffisamment longs, CVE-2025-1478 permet à un attaquant de bloquer l'accès aux utilisateurs légitimes du système ciblé en créant des noms de tableau suffisamment longs, et CVE-2025-5996 permet un déni de service en intégrant un composant tiers malveillant dans un projet GitLab. Une autre vulnérabilité corrigée, CVE-2024-9515, aurait pu donner la capacité à un attaquant de cloner le référentiel privé d'un utilisateur légitime en envoyant une demande de clonage temporisée lorsqu'un nœud secondaire est désynchronisé. Cette faille a un score CVSS de 5,3. Robert Beggs, CEO de la société canadienne de réponse aux incidents Digital Defence, a déclaré que les responsables de la sécurité informatique doivent garder à l'esprit que GitLab n'est pas un dossier passif dans lequel un utilisateur dépose et récupère ultérieurement des données ou du code source. Il s'agit d'une application complexe qui prend en charge l'ensemble du cycle de vie DevOps, de la planification au déploiement et à la surveillance. Pour remplir ce rôle, GitLab fournit un grand nombre de fonctions complexes. Cet ensemble de fonctionnalités augmente la surface d'attaque. Combinées à la complexité de l'application, toute configuration incorrecte ou vulnérabilité pourrait avoir un impact significatif pour les utilisateurs.
« Comme pour toutes les applications, les CSO doivent prêter attention aux rapports des fournisseurs sur les vulnérabilités et à tout correctif ou mise à jour de l'application », a-t-il déclaré dans un e-mail. « Ils doivent également être attentifs à leur propre hygiène de sécurité et suivre les meilleures pratiques d'utilisation de GitLab. » Il s'agit notamment de limiter l'accès et les privilèges d'accès aux référentiels GitHub (par exemple, en s'assurant que la visibilité par défaut est définie sur Privé), d'activer l'authentification multifactorielle pour l'accès et de s'assurer que les mots de passe respectent les règles de complexité habituelles, de mettre en œuvre des contrôles d'accès basés sur les rôles et de revoir fréquemment les listes d'accès, de mettre en œuvre des certificats SSL et TLS pour sécuriser les communications, de sécuriser les runners GitLab et les variables de pipeline, de protéger la base de code en mettant en œuvre des règles de protection des branches et la signature du code, etc.