Une adresse GitLab « Email work item » fuitée en public ouvre des merge requests à votre place
Le 24 septembre 2026, Aikido a révélé que les adresses « Email work item to this project » de GitLab, générées avec un jeton longue durée et publiées par erreur dans des README, laissent un attaquant créer des merge requests ou pousser du code à la place du titulaire. Cherchez ces adresses dans vos dépôts et réinitialisez les jetons exposés.
Mai 2026. Aikido signale à GitLab, via HackerOne, que les adresses « Email work item to this project » contiennent un jeton utilisable comme une identité. Juin 2026. GitLab ferme d’abord le rapport comme « comportement prévu », puis met à jour son interface après un second signalement. 24 septembre 2026. Aikido rend l’affaire publique après avoir trouvé une douzaine d’adresses vivantes dans des README publics en un seul après-midi. Pourquoi c’est important : le secret ne fuit pas par une mauvaise configuration — il est collé en clair dans la documentation, et il ouvre la porte aux dépôts.
Un jeton caché dans une adresse e-mail
GitLab propose une fonctionnalité appelée « Email work item to this project » : elle génère une adresse e-mail privée qui, lorsqu’elle reçoit un message, le transforme en ticket ou en tâche dans le projet. Cette adresse n’est pas qu’une adresse. Elle contient une chaîne préfixée glimt- qui fait office de jeton longue durée, lié au compte du développeur qui l’a générée.
Le jeton est persistant : il reste valable pour toutes les adresses similaires créées pour le même projet. Et la fonctionnalité est pensée pour recevoir du courrier de n’importe quelle boîte : GitLab traite le message comme s’il venait du titulaire du jeton, sans vérifier l’adresse d’expédition. « Toute boîte mail d’Internet peut écrire à cette adresse, et GitLab traite le message comme le propriétaire du jeton », résume Aikido.
De l’issue à la merge request, d’un simple suffixe
L’exploitation est d’une simplicité déconcertante. Une adresse de ce type se termine par le suffixe -issue. Changez ce suffixe en -merge-request, et GitLab ouvre une merge request sur le projet, toujours au nom du titulaire du jeton. Les tests d’Aikido montrent en outre que l’attaque contourne les restrictions par adresse IP : le message arrive par le canal e-mail, hors du chemin d’authentification classique.
Le niveau d’accès obtenu dépend des permissions du compte titulaire. Pour un mainteneur, cela peut signifier des modifications de code, le déclenchement de pipelines CI/CD, la lecture de secrets dans les variables d’intégration, ou l’accès à des issues confidentielles et au code source d’un dépôt privé. Il faut tout de même deux conditions : le chemin du projet et son identifiant. Pour un projet public, ces deux informations sont publiques ; pour un projet privé, l’identifiant peut être bruteforcé, mais le chemin doit fuir — souvent par la même documentation qui expose l’adresse.
La documentation de GitLab ne s’y trompe pas : l’adresse est « générée juste pour vous », et l’avertissement est sans ambiguïté. « Gardez-la pour vous, car toute personne qui la connaît peut créer des issues ou des merge requests comme si c’était vous. Si vous pensez que cette adresse privée a fui, réinitialisez le jeton immédiatement. »
Des adresses collées dans des README par choix
Le problème n’est pas un bug de GitLab : c’est l’exposition volontaire du secret par les mainteneurs. Aikido a trouvé, en un seul après-midi, une douzaine d’adresses entrantes vivantes dans des README publics, des guides de contribution et des pages de support. Ces adresses y avaient été placées délibérément, pour permettre aux utilisateurs d’envoyer des rapports de bug aux mainteneurs.
Le risque est d’autant plus lourd que l’exposition touche parfois des projets open source très populaires. « Quelques-unes appartenaient à des projets open source très populaires », précisent les chercheurs. Pour un attaquant, une telle adresse sur un dépôt très utilisé est un vecteur de supply chain : pousser un changement malveillant par une merge request au nom d’un mainteneur, dans un projet que des milliers de dépendances consomment.
Le parallèle avec les clés API committées par erreur est tentant, mais trompeur. Une clé API fuitée se détecte par son format : un préfixe reconnaissable, une entropie élevée, parfois un scan de secrets intégré au CI. L’adresse « Email work item » n’a rien de tout cela : c’est une adresse e-mail d’apparence banale, que ni un linter ni un scanner de secrets ne signale. C’est précisément ce qui la rend dangereuse : elle se fond dans la documentation, là où un secret devrait sauter aux yeux.
La réponse de GitLab : un comportement « prévu »
Aikido a signalé le problème à GitLab par HackerOne en mai. La réponse initiale : le rapport est fermé comme « intended behavior » — comportement prévu. Un second signalement en juin a fini par convaincre l’éditeur d’agir, mais sur la forme plus que sur le fond : l’interface mentionne désormais les merge requests, les mentions inexactes sur l’accès aux données du jeton ont été retirées, et la documentation reconnaît que le courrier entrant contourne les restrictions IP.
Le fond, lui, n’a pas changé : une adresse qui fuit reste utilisable jusqu’à sa réinitialisation, et la vérification de l’adresse d’expédition n’existe toujours pas — GitLab indique seulement « l’envisager ». C’est le point central du verdict : la mitigation ne viendra pas d’un correctif automatique, mais d’une hygiène de secret que les équipes doivent appliquer elles-mêmes.
Pourquoi ce jeton est si difficile à faire tourner
Le piège de l’adresse « Email work item » tient à sa nature : le jeton glimt- n’est pas un secret rangé dans un gestionnaire, c’est un identifiant d’adresse e-mail. On ne le révoque pas comme une clé d’API ; on le trouve collé dans des fichiers de documentation, là où personne ne pense à chercher un secret. La rotation est manuelle, projet par projet, et chaque adresse publiée dans un README historique reste exploitable tant qu’on n’a pas explicitement réinitialisé le jeton.
Il y a un second piège, plus subtil : la persistance. « Le jeton persiste à travers toutes les adresses similaires générées pour le projet », rappelle Aikido. Autrement dit, réinitialiser une adresse ne coupe pas forcément toutes les routes si d’autres variantes ont été générées pour le même projet. La seule stratégie propre est de recenser toutes les adresses du projet et de tout réinitialiser d’un coup.
Enfin, le contournement des restrictions IP aggrave le tableau. Beaucoup d’équipes croient qu’une restriction d’adresse IP protège leurs dépôts contre ce genre d’abus. Les tests d’Aikido montrent le contraire : le courrier entrant contourne cette barrière, parce qu’il n’emprunte pas le canal d’authentification classique mais le chemin e-mail, traité « comme le propriétaire du jeton ».
Verdict
Si vous maintenez un projet GitLab : cherchez dès maintenant toute adresse entrante dans vos README, guides et pages de support — un grep -R "glimt-" . ou une recherche du suffixe -issue dans le dépôt suffit à les repérer — puis réinitialisez le jeton de chaque adresse exposée. Si vous avez déjà publié une telle adresse par le passé, partez du principe qu’elle a été collectée : réinitialisez-la et ne la republiez jamais. Si vous voulez recueillir des rapports de bug, préférez un formulaire, un canal d’issues public ou une adresse dédiée sans jeton de projet : la commodité de l’adresse e-mail ne vaut pas l’identité qu’elle transporte.