En bref
GitLab vous fournit une adresse e-mail privée pour créer des tickets. Si elle est divulgée, quiconque la possède peut envoyer du code, exécuter des tâches CI/CD et contourner les restrictions IP sur l'ensemble de vos projets publics et privés. Cela concerne tous les comptes GitLab.com et les serveurs GitLab auto-hébergés qui permettent aux utilisateurs de créer des tickets par e-mail.
Ce que vous devez vérifier
Étape 1 : La fonctionnalité est-elle activée ?
- GitLab.com : Oui, pour chaque compte. Vous ne pouvez pas la désactiver.
- GitLab auto-hébergé : Peut-être.
- Ouvrez la liste des éléments de travail de l'un de vos projets et cliquez sur ⋮. Si vous voyez « Envoyer un élément de travail par e-mail à ce projet » ou un message similaire, c'est activé.
- GitLab Dedicated : Non.
Étape 2 : Est-ce que l'une de ces adresses a été partagée ?
L'adresse ne présente un risque que si une personne autre que son propriétaire y a accès. Recherchez `@incoming.gitlab.com` dans vos dépôts, votre documentation, votre centre d'aide et vos wikis (les utilisateurs auto-hébergés doivent rechercher le domaine de leur propre adresse). Une correspondance est dangereuse si l'adresse comporte un jeton avant `-issue` ou `-merge` :
- Dangereuse : incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
- Sûre : incoming+group-project-12346426-issue-@incoming.gitlab.com
Betterleaks (gratuit, open source) et la détection de secrets d'Aikido trouvent automatiquement ces adresses dans vos dépôts, y compris les anciens formats.
Étape 3 : Réinitialiser les adresses compromises
Le propriétaire d'une adresse e-mail compromise doit se rendre dans Paramètres utilisateur > Jetons d'accès personnels > Jeton d'e-mail entrant, puis cliquer sur Réinitialiser (lien direct pour GitLab.com). Cela modifie toutes les adresses e-mail de ses projets en même temps, et les anciennes cessent de fonctionner.
Vérifiez les commits récents, en particulier les modifications apportées à .gitlab-ci.yml, ainsi que les exécutions de pipelines récentes pour repérer toute activité dont le propriétaire de l'adresse e-mail ne se souvient pas.
L'histoire complète
Les projets GitLab disposent d'un bouton intitulé « Envoyer un élément de travail par e-mail à ce projet ».
Si vous cliquez dessus, GitLab affiche une adresse e-mail privée. Envoyez n'importe quel message à cette adresse et un nouveau ticket apparaît dans ce projet, créé en votre nom.
incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
La chaîne glimt- au milieu de cette adresse est un identifiant. Il s'agit d'un jeton à longue durée de vie associé à votre compte, et il n'expire jamais.
Il permet également bien plus que de simplement consigner des bugs. Quiconque détient cette adresse peut pousser du code et exécuter des tâches CI/CD dans tous les projets auxquels votre compte a accès.
Nous avons testé cela sur un projet privé protégé par les restrictions IP de GitLab, configuré pour accepter les connexions provenant d'une seule adresse qui n'était pas la nôtre. GitLab a bloqué notre navigateur et rejeté git clone. Il a accepté l'e-mail, et le commit a atterri sur main.
Inoffensif sur le papier dans l'interface utilisateur
La création de tickets par e-mail est une fonctionnalité courante. Trello, Todoist et Monday.com proposent tous une version de cette fonctionnalité, et leur périmètre est identique. Le courrier envoyé à une adresse unique crée une unité de travail dans un projet. Les utilisateurs arrivent donc sur GitLab en s'attendant au même comportement.
Et l'interface de GitLab l'a confirmé. La modale indiquait aux utilisateurs que l'adresse leur appartenait exclusivement et qu'elle ajoutait des éléments à ce projet.
La page des jetons d'accès personnel (sous `Paramètres utilisateur`) excluait toute autre possibilité. GitLab indiquait que le jeton d'e-mail entrant vous authentifie 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 le modèle mental qui est inculqué aux utilisateurs de GitLab. Il s'agit d'une adresse e-mail permettant de créer des tickets au sein d'un projet particulier, et elle doit rester privée.
Remarque : Après les avoir contactés, GitLab a ajouté le texte « et merge requests » aux deux éléments de l'interface.
Mon adresse e-mail est un PAT ?
GitLab a raison de dire qu'il faut la garder privée, mais ils minimisent le risque. Le jeton contenu dans cette adresse e-mail est essentiellement un jeton d'accès personnel à grain fin doté d'un accès étendu à vos projets GitLab.
Accès à l'échelle du compte
Ouvrez « Envoyer un élément de travail par e-mail à ce projet » dans cinq projets différents et GitLab vous fournira cinq adresses distinctes. Le jeton glimt- intégré dans chacune d'elles est identique, y compris dans les projets privés.
L'interface présente l'adresse comme étant limitée au projet, mais l'identifiant qu'elle contient ne l'est pas. Ce jeton appartient à l'ensemble de votre compte et s'étend à 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'expéditeur. En principe, s'assurer que l'adresse d'expédition correspond à celle du propriétaire du jeton ajouterait une couche de défense, mais GitLab ne le fait pas (bien qu'ils l'envisagent actuellement). N'importe quelle boîte aux lettres sur Internet peut envoyer un message à cette adresse, et GitLab traite le message en tant que propriétaire du jeton. Si vous possédez l'adresse, vous disposez à la fois de l'authentification et de l'autorisation.
Des tickets au code
Remplacez le suffixe -issue par -merge-request dans l'adresse e-mail, et GitLab ouvrira une merge request.
Cela ne suffit pas en soi, dans la mesure où un attaquant ne peut pas pointer la merge request vers un fork malveillant qu'il contrôle. Cependant, les e-mails de merge request acceptent une pièce jointe au format de correctif git (.patch), et GitLab applique ces modifications à la branche source. Si le patch modifie .gitlab-ci.yml et que le rôle de la victime le permet, GitLab exécute la tâche de l'attaquant.
Le parcours complet, du début à la fin :
- La victime publie ou fait fuiter l'adresse e-mail de création de tickets d'un projet.
- L'attaquant remplace -issue@ par -merge-request@.
- L'attaquant rédige un patch ajoutant un job à .gitlab-ci.yml, sans aucune connaissance du dépôt cible.
- L'attaquant envoie le patch par e-mail en précisant la branche source dans l'objet. GitLab pousse le code vers cette branche si elle existe ou la crée dans le cas contraire.
- GitLab exécute le job dans le projet de la victime, avec les privilèges de cette dernière.
L'exécution CI/CD est une issue possible. L'autre est un commit sur n'importe quelle branche sur laquelle la victime a des droits de push, y compris main, dont elle est l'auteur. Quiconque compile à partir de ce dépôt récupère le code de l'attaquant.
Les e-mails contournent les restrictions IP
Nous avons restreint un projet privé à une seule adresse IP qui n'était pas la nôtre.
GitLab a bloqué notre navigateur et rejeté nos commandes git clone. Mais il a tout de même accepté un e-mail de merge request.
Les équipes activent les restrictions IP en pensant avoir établi une frontière de sécurité autour d'un projet, souvent en bordure d'un VPN d'entreprise. Cette barrière fonctionne pour HTTP et SSH, mais pas pour les e-mails entrants. Un attaquant qui ne peut pas accéder au projet par le réseau peut l'atteindre via le canal des e-mails.
Ce qu'une seule adresse permet à un attaquant
Une seule adresse e-mail divulguée peut compromettre gravement le compte GitLab d'un utilisateur ou d'une organisation. Nous avons confirmé chacun de ces vecteurs d'attaque sur des projets que nous contrôlons :
- Pousser du code vers une branche protégée dans un dépôt privé protégé par une liste blanche d'adresses IP.
- Exfiltrer le code source de projets privés protégés par une liste blanche d'adresses IP.
- Lire les variables CI/CD et les secrets de projets privés.
- Accéder aux tickets confidentiels dans des projets privés (via l'action rapide /move)
- Utiliser le jeton CI_JOB_TOKEN disponible dans les jobs CI/CD pour s'enfoncer plus profondément dans le compte.
Une adresse e-mail entrante GitLab contient un jeton qui agit comme un token d'accès personnel granulaire doté de permissions significatives.
La distinction la plus importante est qu'au lieu 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 même compromission de compte, importe-t-il qu'il s'agisse d'une requête HTTP ou d'un e-mail ?
Contraintes de l'attaquant
Deux éléments limitent un attaquant en possession de l'adresse :
1. Le jeton hérite des permissions de la victime, et rien dans le processus de messagerie ne permet de les élever.
Les permissions de la victime limitent l'ampleur des dégâts. Une adresse d'invité (Guest) divulguée est pratiquement inutile. Une adresse de mainteneur (Maintainer) divulguée peut donner accès à des branches protégées et à des variables CI/CD. Rien dans le canal e-mail ne fixe cette limite, si ce n'est le rôle de la victime.
2. Le routage nécessite de connaître le projet ciblé.
GitLab identifie la destination à partir de deux éléments présents dans l'adresse e-mail entrante : le chemin d'accès (slug) du projet et l'ID du projet. Pour atteindre un second projet, un attaquant doit fournir le chemin et l'ID d'un autre projet en plus du jeton volé. Pour les projets publics, GitLab rend ces deux valeurs publiques. Pour les projets privés, un attaquant a besoin d'une fuite d'information nommant le projet (l'ID étant devinable).
Une douzaine, publiées intentionnellement
Tout ce qui précède dépend de l'obtention d'une adresse e-mail par un attaquant. Nous avons passé un après-midi à parcourir la documentation publique et avons facilement trouvé une douzaine d'adresses e-mail entrantes actives dans des fichiers README, des guides de contribution et des pages de support. Presque toutes avaient été publiées délibérément par un mainteneur indiquant aux utilisateurs où envoyer les rapports de bugs ! Quelques-unes appartenaient à des projets open source très populaires.
Il ne s'agit pas d'une erreur utilisateur. Une adresse e-mail est l'identifiant par excellence conçu pour être partagé. GitLab qualifie cet élément d'adresse e-mail, lui donne le format correspondant et propose un bouton pour la copier. Rien en elle ne ressemble à un jeton d'authentification.
La modale indique bien de la garder privée et avertit que quiconque détient cette adresse peut créer des éléments de travail en votre nom. Cet avertissement décrit du spam, et non des pushs de code et des exécutions de pipelines sur l'ensemble des projets du compte.
Nous avons prévenu les comptes concernés avant la publication. Malheureusement, GitLab ne dispose d'aucun mécanisme pour révoquer ces jetons en masse ou notifier les utilisateurs, si bien que nos efforts ont eu des résultats mitigés.
Qui est concerné ?
Tous les comptes GitLab.com, ainsi que toutes les instances autohébergées (self-managed) pour lesquelles les e-mails entrants sont activés. GitLab restreignant la documentation sur les e-mails entrants aux offres Self-Managed et GitLab.com, GitLab Dedicated ne semble pas concerné. Nous n'avons pas pu le tester directement.
Aucun de ces utilisateurs ne peut désactiver cette fonctionnalité. Il n'existe aucun paramètre pour désactiver la création d'issues par e-mail, aucun paramètre pour désactiver la création de merge requests par e-mail, ni aucun moyen d'exiger que l'expéditeur corresponde à une adresse vérifiée. Le jeton n'expire pas. Le seul contrôle fourni par GitLab est le lien de réinitialisation sur votre page de tokens d'accès personnels, et sa réinitialisation invalide toutes les adresses de vos projets.
Signalement à GitLab
Il ne s'agit pas d'une « vulnérabilité » typique. C'est un mélange de fausses attentes de la part des utilisateurs et de configurations par défaut non sécurisées. Nous l'avons signalée via HackerOne en mai 2026, mais elle a été classée comme comportement attendu (ce qui n'est pas une surprise). Nous avons ouvert un ticket confidentiel sur le dépôt GitLab en juin 2026, ce qui a permis d'obtenir une réponse plus détaillée.
D'après ce que nous comprenons, la position de GitLab est qu'il s'agit d'un jeton comme un autre et que tout jeton divulgué entraîne des conséquences néfastes. Cela décrit le comportement de n'importe quel identifiant dès lors qu'un attaquant s'en empare, et c'est exact. Mais cela élude ce qui rend celui-ci différent. GitLab a créé un jeton ayant accès à l'ensemble des projets du compte et contournant les restrictions IP, tout en le présentant comme une simple adresse e-mail.
En réponse à notre rapport, GitLab a publié une mise à jour comportant 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 des merge requests » là où l'interface indiquait auparavant que l'adresse ne pouvait créer que des éléments de travail.
- Ajout de la mention selon laquelle les e-mails entrants ne sont pas soumis aux restrictions IP.
C'est une réponse honnête à notre signalement, mais ces mises à jour ne reflètent toujours pas l'ampleur du risque. Un utilisateur qui lit « merge requests » ne réalise pas que l'adresse intègre un jeton permettant de pousser du code, d'exécuter des jobs CI/CD et d'agir en dehors d'une liste blanche d'adresses IP. Rien sur aucune interface n'indique que ce jeton donne accès à tous les projets du compte.
GitLab a également laissé le mécanisme sous-jacent intact. La mesure la plus efficace pour réduire la surface d'attaque consisterait à exiger que l'adresse de l'expéditeur corresponde à celle du compte GitLab. Un attaquant aurait alors besoin d'accéder à la boîte mail de la victime, et non plus seulement à une adresse.
Comment nous les détectons
Nous avons ajouté une couverture supplémentaire à Betterleaks pour identifier tous les types de jetons d'e-mail entrant GitLab, notamment :
- les tokens préfixés par `glimt-`
- les tokens avec des préfixes personnalisés
- les tokens créés avant l'existence du préfixe `glimt-`
Betterleaks identifie désormais plus de formats de tokens d'e-mails entrants GitLab que tout autre scanner de secrets, y compris GitLab.
La détection de secrets d'Aikido offre le même niveau de couverture que Betterleaks sur vos dépôts et vos merge requests. Si des résultats apparaissent, renouvelez vos identifiants immédiatement.
Une adresse e-mail GitLab compromise représente un vecteur de plus permettant aux acteurs malveillants d'injecter du code malveillant et de compromettre la supply chain. Pensez à utiliser Safe Chain ou Device Protection d'Aikido pour éviter d'installer accidentellement des paquets compromis (vous-même ou votre équipe). Safe Chain est une CLI open source qui encapsule npm, pip et d'autres gestionnaires de paquets pour bloquer les malwares connus avant leur installation. Device Protection fait de même pour les équipes en bloquant les paquets malveillants, en enregistrant les installations à l'échelle de l'organisation et en appliquant des politiques d'approbation. Aucun de ces outils n'empêche un détenteur de jeton de pusher du code, mais ils contribuent à empêcher l'exécution d'une dépendance malveillante ajoutée via un commit compromis sur la machine d'un développeur ou lors d'un build.
