GitLab sous haute tension après la découverte de graves vulnérabilités
GitLab traverse une période mouvementée en ce printemps 2025. L’Agence nationale de la sécurité des systèmes d’information (ANSSI) a récemment lancé une alerte officielle via le CERT-FR, révélant plusieurs vulnérabilités majeures. Ces failles exposent potentiellement les données confidentielles de millions d’utilisateurs et permettent des attaques sophistiquées, comme les injections XSS ou les assauts par déni de service (DDoS). Face à l’ampleur de la menace, l’agence exhorte tous les administrateurs GitLab à réagir rapidement pour éviter de lourdes conséquences.
La plateforme de gestion de code, prisée par d’innombrables entreprises et développeurs, a publié une mise à jour de sécurité critique afin de corriger ces failles. Cependant, la vigilance reste de mise, car la fenêtre d’exploitation pour les cybercriminels est encore ouverte. Zoom sur les détails de cette alerte inquiétante.
Injections XSS et surveillance : des risques graves pour les utilisateurs de GitLab
Des vulnérabilités critiques dans le proxy Maven
Parmi les failles identifiées, deux vulnérabilités particulièrement alarmantes concernent le proxy de dépendances Maven, un composant clé de GitLab utilisé par de nombreuses organisations. Référencées sous les identifiants CVE-2025-1763 et CVE-2025-2443, ces brèches permettent des attaques de type Cross-Site Scripting (XSS). Concrètement, des attaquants peuvent contourner les mesures de sécurité du navigateur et injecter du code malveillant dans l’interface de GitLab.
Ces failles ont obtenu un score CVSS de 8,7 sur 10, soulignant leur extrême dangerosité. Toutes les versions de GitLab depuis la 16.6 sont concernées, rendant la portée du problème particulièrement large. Pour les entreprises, la menace ne concerne pas uniquement les données visibles, mais aussi le cœur même de leurs opérations.
Injection d’en-têtes NEL : vers une prise de contrôle potentielle
Une troisième vulnérabilité, identifiée sous le code CVE-2025-1908, ajoute une couche d’inquiétude supplémentaire. Celle-ci permet une injection d’en-têtes NEL (Network Error Logging), offrant aux attaquants un moyen de surveiller l’activité des utilisateurs, et potentiellement de prendre le contrôle total des comptes affectés.
Avec un score CVSS de 7,7, cette faille affecte également toutes les versions depuis la 16.6. Dans un contexte où le code source représente un actif stratégique pour les entreprises, une compromission de GitLab pourrait entraîner des conséquences catastrophiques, tant sur le plan opérationnel que financier.
D’autres failles moins graves mais non négligeables
En plus de ces vulnérabilités critiques, GitLab fait face à deux failles supplémentaires, de gravité moyenne. La première, référencée CVE-2025-0639 avec un score CVSS de 6,5, concerne le système d’aperçu des tickets et pourrait être exploitée pour déclencher une attaque par déni de service (DDoS). Cela pourrait perturber le fonctionnement normal de GitLab, ralentissant les flux de travail ou rendant temporairement inaccessible l’accès aux projets.
La seconde vulnérabilité, CVE-2024-12244, bien que moins grave (score CVSS de 4,3), permet un accès non autorisé aux noms de branches, dans certaines configurations spécifiques où des fonctionnalités sont désactivées. Même si ces failles ne présentent pas un risque immédiat d’intrusion massive, elles pourraient exposer des informations sensibles et désorganiser les processus internes des équipes.
Comment sécuriser votre GitLab : les mises à jour indispensables
Trois nouvelles versions de GitLab à déployer rapidement
Face à ces risques élevés, GitLab a publié dès le 23 avril trois mises à jour correctives : 17.11.1, 17.10.5 et 17.9.7. L’équipe de sécurité recommande fermement à tous les administrateurs de mettre à jour leur instance sans attendre. Cette recommandation concerne aussi bien les installations Omnibus que les déploiements à partir du code source ou par Helm Chart.
Pour les utilisateurs de GitLab.com, la situation est plus rassurante : la plateforme cloud a déjà été mise à jour automatiquement. Quant aux clients de GitLab Dedicated, aucune action n’est requise. En revanche, toutes les autres installations doivent être corrigées rapidement pour éviter d’être la cible d’attaques.
Un compte à rebours inquiétant
Un élément important vient intensifier la pression : GitLab prévoit de publier les détails techniques de ces failles dans 30 jours. Passé ce délai, les cybercriminels auront en leur possession toutes les informations nécessaires pour exploiter les vulnérabilités sur les instances non mises à jour. Chaque jour qui passe augmente donc le risque d’être attaqué.
Dans ce contexte, appliquer les correctifs sans tarder est la seule manière de protéger efficacement son environnement de développement. Reporter cette opération pourrait avoir des conséquences dramatiques, tant pour la confidentialité que pour l’intégrité des projets hébergés.
HackerOne et la chasse aux vulnérabilités : un modèle qui fait ses preuves
Le rôle crucial des programmes de bug bounty
Les failles récemment corrigées ont été découvertes grâce au programme de récompenses HackerOne, auquel GitLab participe activement. Ce type d’initiative, appelé bug bounty, permet de mobiliser des chercheurs en sécurité indépendants qui détectent les failles avant qu’elles ne soient exploitées par des acteurs malveillants.
Le succès de ces programmes démontre que la sécurité ne peut plus être envisagée comme un exercice purement interne. L’ouverture à des experts externes constitue désormais une stratégie incontournable pour améliorer en continu la résilience des plateformes numériques.
Un rappel pour toutes les entreprises
Cette alerte sur GitLab est un rappel précieux pour toutes les entreprises : sécuriser ses outils numériques est un processus permanent. L’audit régulier des infrastructures, la participation à des programmes de bug bounty et l’application rapide des correctifs doivent devenir des réflexes pour quiconque manipule des données sensibles ou des environnements critiques.
GitLab, comme d’autres grands noms de la tech, montre que même les acteurs les plus sérieux peuvent être exposés. C’est la rapidité de réaction et l’organisation des procédures de correction qui font aujourd’hui toute la différence entre un incident isolé et une catastrophe de grande ampleur.
