La plateforme avertit les utilisateurs des versions sur site de mettre à niveau vers les dernières versions ; Les versions SaaS et Web ont été corrigées.
Selon les experts, une vulnérabilité critique de contournement de l’authentification à deux facteurs dans les éditions Community et Enterprise de la plateforme de développement d’applications GitLab doit être corrigée immédiatement.
Cette faille est l’une des cinq vulnérabilités corrigées mercredi dans le cadre des nouvelles versions de GitLab. Trois sont classés en gravité élevée, y compris le problème de contournement 2FA, tandis que les deux autres sont classés en gravité moyenne.
GitLab indique que le trou 2FA, CVE-2026-0723, s’il est exploité sur un système non corrigé, pourrait permettre à une personne connaissant les informations d’identification d’une victime de contourner l’authentification à deux facteurs en soumettant de fausses réponses sur l’appareil.
C’est ce trou qui a retenu l’attention des experts, en raison de ses implications.
L’objectif de l’authentification multifacteur est de protéger les comptes de connexion avec une étape de vérification supplémentaire en cas de vol des noms d’utilisateur et des mots de passe. Si un acteur malveillant peut accéder à un compte, il peut causer des dommages presque illimités aux systèmes informatiques.
Dans le cas de GitLab, si du code critique se trouve dans le compte d’un développeur, un acteur malveillant pourrait le compromettre, note David Shipley, responsable de la société canadienne de formation et de sensibilisation à la sécurité Beauceron Security. Si ce code doit être utilisé dans un logiciel pouvant être téléchargé ou vendu à d’autres organisations, les logiciels malveillants insérés pourraient alors se propager lors d’une attaque sur la chaîne d’approvisionnement. Le dernier exemple, a déclaré Shipley, est le ver Shai-Hulud, qui se propage parce que le compte d’un développeur dans le registre npm a été piraté.
Si le code contient des secrets cloud, a-t-il ajouté, l’acteur malveillant pourrait accéder à des plateformes cloud comme Azure, Amazon Web Service ou Google Cloud Platform.
La découverte du trou de contournement 2FA « est un rappel que ces contrôles (de sécurité) sont importants », a déclaré Shipley dans une interview. « Ils contribuent absolument à réduire un certain nombre de risques : attaques par force brute, pulvérisation de mots de passe, etc. Mais ils ne seront jamais infaillibles.
« Ce n’est pas la première fois que quelqu’un trouve un moyen intelligent de contourner les défis de la 2FA. Nous avons toute une série d’attaques autour de la capture de cookies de session qui sont également conçues pour vaincre la 2FA. Il est donc important de s’en souvenir lorsque quelqu’un lance un Silver Bullet en pensant que « Cette solution magique le résout (l’authentification) » ou « C’est le mauvais MFA. Voici le nouveau MFA ». Et j’inclus (en faisant confiance uniquement) les Yubikeys », a-t-il déclaré. « Les Yubikeys sont incroyables. Ils constituent la prochaine génération de 2FA. Mais comme ils sont conçus pour les humains, ils finiront par avoir quelques défauts. »
Même s’il n’y avait pas de défauts dans ces contrôles, les employés pourraient être amenés à renoncer à leurs informations d’identification par le biais de l’ingénierie sociale, a-t-il ajouté.
Il serait plus facile pour un attaquant d’utiliser des techniques telles que le phishing pour collecter les informations d’identification des utilisateurs plutôt que de falsifier les informations d’identification de l’appareil pour exploiter ce contournement 2FA particulier, a déclaré Johannes Ullrich, doyen de la recherche à l’Institut SANS. Mais, a-t-il ajouté, une fois que l’attaquant a accès à des mots de passe valides, il peut se connecter au serveur GitLab et effectuer des actions sur le code source – le télécharger, le modifier ou le supprimer – tout comme le ferait un utilisateur légitime.
Ce que les responsables de la sécurité de l’information doivent faire
C’est pourquoi le niveau de cybersécurité 101 (défense à plusieurs niveaux) est vital pour la gestion des identités et des accès, a déclaré Shipley. Cela inclut d’obliger les employés à avoir des mots de passe de connexion longs et uniques, de surveiller le réseau pour détecter toute activité inhabituelle (par exemple, si quelqu’un entre sans qu’un défi MFA soit enregistré) et, en cas d’échec, d’un plan de réponse aux incidents.
Les vulnérabilités de contournement MFA sont très courantes, a noté Ullrich. « Le problème principal est généralement que la MFA a été ajoutée ultérieurement à un produit existant », a-t-il déclaré, « et certaines fonctionnalités peuvent ne pas vérifier correctement si la MFA a été réalisée avec succès. »
Lors du test d’une solution d’authentification multifacteur, les responsables de la sécurité informatique doivent toujours vérifier qu’une application n’a pas marqué l’authentification comme terminée après la vérification du nom d’utilisateur et du mot de passe. L’activation de la MFA ne devrait pas assouplir les exigences en matière de mot de passe, a-t-il affirmé. Les utilisateurs doivent toujours choisir des mots de passe uniques et sécurisés et utiliser des gestionnaires de mots de passe pour les gérer. Les mots de passe sécurisés atténueront principalement les éventuels échecs de MFA, a déclaré Ullrich.
Toute vulnérabilité trouvée dans GitLab est importante, a-t-il ajouté. GitLab est généralement utilisé par des organisations suffisamment soucieuses de la confidentialité de leur code pour vouloir exécuter la plateforme sur site.
GitLab recommande « fortement » les mises à niveau
En décrivant les correctifs publiés mercredi, GitLab a déclaré qu’il recommandait « fortement » que toutes les installations GitLab autogérées soient mises à niveau vers l’une des trois nouvelles versions (18.8.2, 18.7.2, 18.6.4) pour GitLab Community Edition (CE) et Enterprise Edition (EE). Ceux qui utilisent GitLab.com ou GitLab Dedicated – une version de logiciel en tant que service à locataire unique – n’ont aucune mesure à prendre.
Les autres vulnérabilités corrigées dans les mises à jour de mercredi sont :
- CVE-2025-13927, un problème de déni de service dans l’intégration de Jira Connect. S’il est exploité sur un système non corrigé, il pourrait permettre à un utilisateur non authentifié de créer une condition de déni de service en envoyant des requêtes contrefaites avec des données d’authentification mal formées. Il porte un score de gravité CVSS de 7,5 ;
- CVE-2025-13928, un problème d’autorisation incorrect. S’il est exploité sur un système non corrigé, cela pourrait permettre à un utilisateur non authentifié de provoquer une condition de déni de service en exploitant une validation d’autorisation incorrecte dans les points de terminaison de l’API. Il porte un score de gravité CVSS de 7,5 ;
- CVE-2025-13335, un problème de boucle infinie dans les redirections Wiki. Dans certaines circonstances, cette faille pourrait permettre à un utilisateur authentifié de créer une condition de déni de service en configurant des documents Wiki mal formés qui contournent la détection du cycle. Il a un score CVSS de 6,5 ;
- CVE-2026-1102 – un problème de déni de service dans un point de terminaison d’API qui pourrait permettre à un utilisateur non authentifié de créer une condition de déni de service en envoyant des demandes d’authentification SSH répétées et mal formées. Il a un score CVSS de 5,3.
Conformément aux pratiques standard de GitLab, les détails des vulnérabilités de sécurité seront rendus publics sur un outil de suivi des problèmes 30 jours après la version dans laquelle elles ont été corrigées.
Les nouvelles versions incluent également des corrections de bogues, dont certaines, selon GitLab, peuvent inclure des migrations de bases de données. Dans le cas d’instances à nœud unique, un correctif entraînera un temps d’arrêt lors de la mise à niveau. Dans le cas d’instances multi-nœuds, les administrateurs qui suivent les procédures appropriées de mise à niveau sans temps d’arrêt de GitLab peuvent appliquer un correctif sans temps d’arrêt.
