En bref
GitLab vous attribue une adresse e-mail privée pour créer des tickets. En cas de fuite, toute personne en possession de cette adresse peut pousser du code, exécuter des tâches CI/CD et contourner les restrictions d'adresse IP sur l'ensemble de vos projets publics et privés. Cela concerne tous les comptes GitLab.com et tous les serveurs GitLab auto-hébergés qui permettent aux utilisateurs de créer des tickets par e-mail.
Ce qu'il faut vérifier
Étape 1 : La fonctionnalité est-elle activée ?
- GitLab.com : Oui, pour tous les comptes. Il n'est pas possible de désactiver cette fonctionnalité.
- GitLab auto-hébergé : Peut-être.
- Ouvrez la liste des tâches de l'un de vos projets et cliquez sur ⋮. Si vous voyez « Envoyer la tâche par e-mail à ce projet » ou une mention similaire, cela signifie que la fonctionnalité est activée.
- GitLab Dedicated : Non.
Étape 2 : Est-ce que quelqu'un a déjà partagé l'une de ces adresses ?
Une adresse n'est dangereuse que si elle est détenue par une personne autre que son propriétaire. Recherchez « @incoming.gitlab.com » dans vos dépôts, votre documentation, votre centre d'aide et vos wikis (les utilisateurs en auto-hébergement doivent rechercher ce domaine dans leur propre adresse). Une correspondance est dangereuse si l'adresse comporte un jeton avant « -issue » ou « -merge-request » :
- Danger : project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com en approche
- Safe : entrant + group-project-12346426-issue-@incoming.gitlab.com
AikidoB etterleaks (gratuit, open source) et détection de secrets / détectent automatiquement ces adresses dans vos dépôts, y compris celles au format ancien.
Étape 3 : Réinitialiser les adresses qui ont fait l'objet d'une fuite
Le propriétaire d'une adresse e-mail ayant fait l'objet d'une fuite doit se rendre dans « Paramètres utilisateur > Jetons d'accès personnels > Jeton de messagerie entrante » et cliquer sur « Réinitialiser » (lien direct pour GitLab.com). Cela modifie d'un seul coup toutes ses adresses e-mail associées à ses projets, et les anciennes cessent de fonctionner.
Vérifiez les commits récents, en particulier les modifications apportées au fichier .gitlab-ci.yml, ainsi que les exécutions récentes du pipeline, afin de repérer toute action dont le titulaire de l'adresse e-mail ne se souvient pas avoir effectuée.
L'article complet
Les projets GitLab comportent un bouton intitulé « Envoyer l'élément de travail par e-mail à ce projet ».
Si vous cliquez dessus, GitLab vous affiche une adresse e-mail privée. Envoyez un e-mail à cette adresse et un nouveau ticket apparaîtra dans ce projet, dont vous serez l'auteur.
project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com à venir
La chaîne « glimt- » au milieu de cette adresse correspond à un identifiant d'authentification. Il s'agit d'un jeton à durée de vie illimitée associé à votre compte, qui n'expire jamais.
Mais ses fonctionnalités ne se limitent pas à la simple signalisation de bogues. Toute personne disposant de cette adresse peut déployer du code et exécuter des tâches CI/CD dans tous les projets accessibles depuis votre compte.
Nous avons testé cette fonctionnalité sur un projet privé protégé par les restrictions d'IP de GitLab, configuré pour n'accepter les connexions qu'à partir d'une seule adresse qui n'était pas la nôtre. GitLab a bloqué notre navigateur et a rejeté la commande « git clone ». Il a toutefois accepté l'e-mail, et le commit a bien été enregistré dans la branche « main ».
Inoffensif sur le papier dans l'interface utilisateur
La création de tickets par e-mail est une fonctionnalité courante des outils de gestion de projets. Trello, Todoist et Monday.com proposent tous une version de cette fonctionnalité, et ils la gèrent tous de la même manière : un e-mail envoyé à une adresse unique crée une tâche dans un projet. Les utilisateurs s'attendent donc à retrouver la même fonctionnalité sur GitLab.
Et l'interface utilisateur de GitLab l'a confirmé. La fenêtre modale indiquait aux utilisateurs que l'adresse leur était propre et qu'elle permettait d'ajouter des éléments à ce projet.
La page « Jetons d'accès personnels » (dans la rubrique « Paramètres utilisateur ») a écarté toutes les autres possibilités. GitLab a précisé que le jeton « E-mails entrants » permet de vous authentifier lorsque vous créez un nouveau ticket par e-mail, et qu'il « ne peut pas être utilisé pour accéder à d'autres données ».
C'est l'idée que se font les utilisateurs de GitLab. Il s'agit d'une adresse e-mail permettant de créer des tickets au sein d'un projet donné, et celle-ci doit rester confidentielle.
Remarque : après avoir contacté GitLab, l'équipe a ajouté la mention « et les requêtes merge » aux deux éléments de l'interface utilisateur.
Mon adresse e-mail est un PAT ?
GitLab a raison de recommander de garder cette information confidentielle, mais l'entreprise minimise le risque. Le jeton contenu dans cette adresse e-mail est en réalité un jeton d'accès personnel très précis qui confère des droits d'accès étendus à vos projets GitLab.
Accès à l'échelle du compte
Ouvrez la fonction « Envoyer un élément de travail par e-mail vers ce projet » dans cinq projets différents, et GitLab vous fournit cinq adresses différentes. Le jeton « glimt- » intégré à chacune d'entre elles est identique, même dans les projets privés.
L'interface utilisateur présente l'adresse comme étant limitée au projet, mais les identifiants qu'elle contient ne le sont pas. Ce jeton appartient à l'ensemble de votre compte et s'applique à tous les projets auxquels vous avez accès, qu'ils soient publics ou privés.
L'expéditeur n'a pas d'importance
GitLab ne vérifie pas l'identité de l'expéditeur. En principe, vérifier que l'adresse d'expédition correspond à l'adresse e-mail du propriétaire du jeton ajouterait un niveau de sécurité supplémentaire, mais GitLab ne le fait pas (même s'ils envisagent désormais cette option). N'importe quelle boîte mail sur Internet peut envoyer un message à cette adresse, et GitLab traite ce message comme s'il provenait du propriétaire du jeton. Si vous disposez de cette adresse, vous bénéficiez à la fois de l'authentification et de l'autorisation.
Des problèmes au code
Remplacez le suffixe « -issue » de l'adresse e-mail par « -merge-request » : GitLab ouvrira alors une demande d'merge .
En soi, cela ne suffit pas, car un attaquant ne peut pas rediriger la requête « merge » vers une branche malveillante qu’il contrôle. Cependant, les e-mails de requête « merge » acceptent une pièce jointe au format .patch Git, et GitLab applique ces modifications à la branche source. Si le patch modifie le fichier .gitlab-ci.yml et que le rôle de la victime l’autorise, GitLab exécute la tâche de l’attaquant.
Le parcours complet, du début à la fin :
- La victime publie ou divulgue l'adresse e-mail dédiée aux tickets d'un projet.
- L'attaquant remplace « -issue@ » par « -merge-request@ ».
- L'attaquant écrit un correctif ajoutant une tâche au fichier .gitlab-ci.yml, sans connaître le dépôt cible.
- L'attaquant envoie le correctif par e-mail, en indiquant le nom de la branche source dans l'objet. GitLab effectue un push vers cette branche si elle existe et la crée si ce n'est pas le cas.
- GitLab exécute la tâche dans le projet de la victime, en tant que victime.
L'exécution du CI/CD est l'un des résultats. L'autre est un commit sur n'importe quelle branche vers laquelle la victime peut effectuer un push, y compris la branche « main », et dont elle est l'auteur. Quiconque effectue une compilation à partir de ce dépôt intègre alors le code de l'attaquant.
Les e-mails contournent les restrictions liées à l'adresse IP
Nous avons restreint l'accès à un projet privé à une seule adresse IP qui n'était pas la nôtre.
GitLab a bloqué notre navigateur et a rejeté nos commandes « git clone ». Il a toutefois accepté un e-mail de demande d'merge .
Les équipes mettent en place des restrictions d'adresses IP, convaincues d'avoir établi une barrière de sécurité autour d'un projet, souvent à la périphérie du VPN de l'entreprise. Cette barrière est efficace pour les protocoles HTTP et SSH, mais pas pour les e-mails entrants. Un pirate qui ne parvient pas à accéder au projet depuis le réseau peut s'y introduire par le biais de la messagerie électronique.
Quelle adresse permet à un pirate d'accéder à…
La divulgation d'une seule adresse e-mail peut compromettre gravement le compte GitLab d'un utilisateur ou d'une organisation. Nous avons vérifié chacune de ces voies d'attaque sur des projets que nous contrôlons :
- Déployer du code vers une branche protégée dans un dépôt privé soumis à une liste blanche d'adresses IP.
- Exfiltration du code source de projets privés protégés par une liste blanche d'adresses IP.
- Lecture des variables CI/CD et des secrets issus de projets privés.
- Accéder aux tickets confidentiels dans les projets privés (via l'action rapide /move)
- Utiliser le CI_JOB_TOKEN disponible dans les tâches CI/CD pour accéder à d'autres parties du compte.
Une adresse e-mail de réception GitLab contient un jeton qui fonctionne comme un jeton d'accès personnel très précis, doté d'autorisations étendues.
La principale différence réside dans le fait que, plutôt que d’accéder à GitLab via l’API, les utilisateurs doivent envoyer des données par e-mail. Du point de vue d’un défenseur, si cela peut aboutir à la compromission du même compte, quelle importance cela a-t-il qu’il s’agisse d’une requête HTTP ou d’un e-mail ?
Contraintes liées à l'attaquant
Deux éléments limitent les possibilités d'un attaquant en possession de l'adresse :
1. Le jeton hérite des autorisations de la victime, et aucun élément du chemin d'accès du courrier ne les renforce.
Les droits d'accès de la victime ont limité l'étendue des dégâts. Une adresse « Guest » divulguée n'a pratiquement aucune valeur. Une adresse « Maintainer » divulguée pourrait donner accès à des branches protégées et à des variables CI/CD. Aucun élément du chemin de transmission du courrier n'impose cette limite ; seul le rôle de la victime entre en ligne de compte.
2. Le routage nécessite de savoir quel projet cibler.
GitLab détermine la destination à partir de deux valeurs contenues dans l'adresse e-mail d'origine : le slug du chemin d'accès au projet et l'identifiant du projet. Pour accéder à un deuxième projet, un attaquant doit fournir le chemin d'accès et l'identifiant d'un autre projet en plus du jeton volé. Pour les projets publics, GitLab publie ces deux valeurs. Pour les projets privés, un attaquant a besoin d'une fuite d'informations indiquant le nom du projet (l'identifiant pouvant être deviné).
Une douzaine, publiées exprès
Tout ce qui précède repose sur le fait qu'un pirate parvienne à obtenir une adresse e-mail. Nous avons passé un après-midi à parcourir la documentation publique et avons facilement trouvé une douzaine d'adresses e-mail actives dans des fichiers README, des guides de contribution et des pages d'assistance. Presque toutes avaient été publiées délibérément par un responsable du projet, afin d'indiquer aux utilisateurs où envoyer leurs rapports de bogues ! Certaines appartenaient à des projets open source très populaires.
Il ne s'agit pas d'une erreur de l'utilisateur. Une adresse e-mail est le seul identifiant destiné à être communiqué. GitLab désigne cette information comme une adresse e-mail, la présente sous ce format et met à votre disposition un bouton pour la copier. Rien dans cette présentation ne fait penser à un identifiant de connexion.
La fenêtre contextuelle indique effectivement de garder ces informations confidentielles et prévient que toute personne disposant de cette adresse peut créer des tâches en votre nom. Cet avertissement fait référence au spam. Il ne concerne pas les déploiements de code ni les exécutions de pipeline sur l'ensemble des projets du compte.
Nous avons averti les comptes concernés avant la publication. Malheureusement, GitLab ne dispose d'aucun mécanisme permettant de révoquer ces jetons de manière groupée ni d'en informer les utilisateurs ; nos efforts ont donc donné des résultats mitigés.
Qui est concerné ?
Tous les comptes GitLab.com, ainsi que toutes les instances auto-gérées sur lesquelles la réception d'e-mails est activée. GitLab limite la portée de la documentation relative à la réception d'e-mails aux instances auto-gérées et à GitLab.com ; par conséquent, GitLab Dedicated ne semble pas être concerné. Nous n'avons pas pu le vérifier directement.
Aucun de ces utilisateurs ne peut désactiver cette fonctionnalité. Il n'existe aucun paramètre permettant de désactiver la création de tickets par e-mail, ni de demandes d'merge par e-mail, et il n'y a aucun moyen d'exiger que l'expéditeur utilise une adresse vérifiée. Le jeton n'expire pas. Le seul moyen de contrôle que GitLab met à votre disposition est le lien de réinitialisation disponible sur votre page de jetons d'accès personnels ; or, sa réinitialisation invalide toutes les adresses de projet dont vous disposez.
Communication d'informations à GitLab
Il ne s'agit pas d'une « vulnérabilité » classique. C'est d'une part une rupture des attentes des utilisateurs, et d'autre part des paramètres par défaut peu sécurisés. Nous l'avons signalée via HackerOne en mai 2026, mais le ticket a été clôturé au motif qu'il s'agissait d'un comportement prévu (ce qui n'est pas une surprise). Nous avons ensuite ouvert un ticket confidentiel sur le dépôt GitLab en juin 2026, ce qui nous a valu une réponse plus détaillée.
La position de GitLab, telle que nous la comprenons, est qu’il s’agit d’un jeton comme un autre, et que toute fuite de jeton entraîne des conséquences néfastes. Cela décrit le comportement de n’importe quel identifiant une fois qu’un pirate en a pris possession, et c’est exact. Mais cela élude ce qui rend celui-ci différent. GitLab a créé un identifiant qui donne accès à tous les projets du compte et contourne les restrictions d’adresse IP, puis l’a présenté sous la forme d’une adresse e-mail.
En réponse à notre rapport, GitLab a publié une mise à jour comprenant trois modifications :
- Suppression de la mention « Il ne peut pas être utilisé pour accéder à d'autres données » de l'interface utilisateur.
- Ajout de « et les demandes de type merge » là où l'interface utilisateur indiquait auparavant que l'adresse ne permettait que de créer des éléments de travail.
- Il a été vérifié que les e-mails entrants ne sont pas soumis à des restrictions liées à l'adresse IP.
C'est une réponse pertinente à ce que nous avons signalé, mais les mises à jour ne reflètent toujours pas l'intégralité du risque. Un utilisateur qui lit «merge requests » ne se rend pas compte que cette adresse contient un jeton qui injecte du code, exécute des tâches CI/CD et fonctionne depuis l'extérieur d'une liste d'adresses IP autorisées. Rien, dans aucune de ces deux interfaces, n'indique que ce jeton affecte tous les projets du compte.
GitLab n'a pas non plus modifié le mécanisme sous-jacent. La mesure la plus efficace pour réduire la surface d'attaque consisterait à exiger que l'adresse de l'expéditeur corresponde à celle associée au compte GitLab. Un pirate devrait alors avoir accès au compte de messagerie de la victime, et pas seulement à son adresse.
Comment nous les détectons
Nous avons élargi la couverture de Betterleaks afin d'identifier tous les types de jetons présents dans les e-mails entrants de GitLab, notamment :
- les tokens préfixés par « glimt- »
- jetons avec préfixe personnalisé
- jetons émis avant l'apparition du préfixe « glimt- »
Betterleaks détecte désormais davantage de formats de jetons dans les e-mails entrants de GitLab que n'importe quel autre outil d'analyse des secrets, y compris GitLab lui-même.
AikidoLa fonctionnalité « détection de secrets » propose la même couverture que Betterleaks sur l'ensemble de vos dépôts et de vos requêtes merge . Si des résultats apparaissent, modifiez immédiatement vos identifiants.
La fuite d’une adresse e-mail GitLab offre aux acteurs malveillants un nouveau vecteur pour diffuser du code malveillant et compromettre une chaîne d’approvisionnement. Envisagez d’utiliser les solutions « Safe Chain » ou « Device Protection » d’ Aikidoafin d’éviter que vous (ou votre équipe) n’installiez accidentellement des paquets compromis. Safe Chain est une interface en ligne de commande (CLI) open source qui encapsule npm, pip et d’autres gestionnaires de paquets afin de bloquer les logiciels malveillants connus avant leur installation. Device Protection fait de même pour les équipes en bloquant les paquets malveillants, en consignant les installations à l’échelle de l’organisation et en appliquant des politiques d’approbation. Aucune de ces solutions n’empêche un détenteur de jeton de publier du code, mais elles contribuent à empêcher qu’une dépendance malveillante ajoutée via un commit compromis ne s’exécute sur la machine d’un développeur ou dans une build.
