Les administrateurs et les développeurs utilisant des installations autogérées ont demandé à mettre à niveau dès que possible.
Une nouvelle vulnérabilité dans les éditions de la communauté et de l’entreprise de GitLab utilisées pour gérer le code source est «dangereuse» et doit être rapidement corrigée, explique un expert.
La vulnérabilité, CVE-2025-5121, est l’une des 10 décrites mercredi par Gitlab, car elle a publié des correctifs de bogue et de sécurité pour les installations autogérées.
« Nous recommandons fortement que toutes les installations autogérées de Gitlab soient améliorées vers l’une de ces versions (corrigées) (18.0.2, 17.11.4, 17.10.8) », a indiqué la plate-forme. GitLab.com exécute déjà la version corrigée, donc les clients dédiés à Gitlab n’ont pas besoin d’agir.
Quatre des vulnérabilités sont évaluées en haute gravité.
Johannes Ullrich, doyen de la recherche au Sans Institute, était particulièrement inquiet pour CVE-2025-5121, un problème d’autorisation manquant. Il l’a décrit comme «dangereux». S’il n’est pas corrigé, dans certaines conditions, il peut permettre à un attaquant réussi avec un accès authentifié à une instance Gitlab avec une licence Gitlab Ultimate appliquée (client ou essai payant) pour injecter un travail CI / CD malveillant dans tous les futurs pipelines CI / CD de tout projet.
Les versions impactées sont Gitlab Ultimate EE 17.11 avant 17.11.4 et 18.0 avant 18.0.2. Cette vulnérabilité a reçu un score CVSS de 8,5.
L’autre vulnérabilité à laquelle Ullrich a attiré l’attention est CVE-2025-4278, un trou d’injection HTML. Il l’a décrit comme essentiellement une vulnérabilité de script de site croisé, mais avec un impact plus limité. GitLab lui donne un score CVSS de 8,7.
« L’impact de ces vulnérabilités est souvent difficile à évaluer », a déclaré Ullrich, « mais les attaquants créatifs sont souvent en mesure de les exploiter pour inciter les utilisateurs à effectuer des actions dangereuses au nom de l’attaquant. »
GitLab dit que, à moins de corriger, dans certaines conditions, le défaut permettrait à un attaquant réussi de reprendre un compte en injectant du code dans la page de recherche.
Toutes les instances de version 18.0 avant le 18.0.2 des éditions communautaires et d’entreprise sont affectées.
Les deux autres vulnérabilités évaluées comme élevées sont:
- Le CVE-2025-2254, un problème de script inter-sites, qui, dans certaines conditions, pourrait permettre à un attaquant d’agir comme un utilisateur légitime en injectant un script malveillant dans le spectateur 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 affectées; - CVE-2025-0673, une vulnérabilité qui peut provoquer un déni de service en déclenchant une boucle de redirection infinie, ce qui entraînerait l’épuisement de la mémoire sur le serveur Gitlab. Les versions affectées de Gitlab CE / EE sont 17,7 avant 17.10.8, 17.11 avant 17.11.4 et 18.0 avant 18.0.2.
Trois autres vulnérabilités de déni de service sont répertoriées, bien qu’elles portent des notes de risque plus faibles.
Le CVE-2025-1516, s’il est non corrigé, permet à un attaquant réussi de refuser l’accès aux utilisateurs légitimes du système ciblé en générant des jetons avec des noms suffisamment grands, Le CVE-2025-1478 permet à un attaquant de refuser l’accès aux utilisateurs légitimes du système ciblé en fabriquant des noms de carte avec des tailles suffisamment grandes, 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 permettre à un attaquant réussi de cloner le référentiel privé d’un utilisateur légitime en envoyant une demande de clone chronométrée lorsqu’un nœud secondaire est hors synchronisation. Ce trou a un score CVSS de 5,3.
Il s’agit notamment de limiter les privilèges d’accès et d’accès aux référentiels GitHub – par exemple, en veillant à ce que la visibilité par défaut soit définie sur privé – permettant une authentification multi-facteurs pour accéder et garantir que les mots de passe suivent des règles de complexité typiques, la mise en œuvre des contrôles d’accès des rôles et l’examen fréquemment de listes d’accès, la mise en œuvre des certificats SSL et TL et la signature du code, et plus encore.
