GitLab : l'adresse des tickets pousse sur main

Ce qui se passe

Chaque projet GitLab propose, derrière le bouton « Email work item to this project », une adresse personnelle qui crée un ticket à votre nom. La chaîne au milieu de cette adresse est un jeton lié à votre compte, l'incoming email token, que la documentation décrit comme sans expiration.

Aikido Security a établi trois choses :

le jeton est le même dans les adresses de tous vos projets ;
il vaut pour tout projet que votre compte peut ouvrir, public ou privé ;
GitLab ne vérifie pas l'expéditeur : n'importe quelle boîte peut écrire à l'adresse, et le message est traité comme venant de vous.

Du ticket au commit

GitLab sait aussi créer une merge request par courriel. Il suffit de remplacer le suffixe -issue de l'adresse par -merge-request, de mettre le nom de la branche cible en objet et de joindre un patch. GitLab applique le patch sur cette branche (il la crée au besoin), avec vous comme auteur. Si vous pouvez pousser sur main, le commit y arrive. Si le patch touche .gitlab-ci.yml et que votre rôle le permet, le job de l'attaquant tourne avec vos droits.

Le test d'Aikido montre surtout les contrôles que ce chemin contourne :

Le clone est refusé, le courriel passe : les contrôles qui ne s'appliquent pas

La documentation de GitLab le confirme : le courriel entrant échappe aux restrictions d'adresse IP et fonctionne sans 2FA, même sur une instance qui l'impose.

Ce qui limite les dégâts

Vos droits, pas plus. L'adresse d'un compte Guest ne mène presque à rien ; celle d'un Maintainer ouvre les branches protégées et les secrets de CI/CD.
Il faut viser un projet. GitLab identifie la cible par son chemin et son identifiant numérique. Un projet public publie les deux ; un projet privé demande une seconde fuite, mais ses identifiants se devinent facilement.
Pas de détournement vers un fork : la merge request ne peut pas pointer vers une copie de l'attaquant, d'où le patch joint.

Sont concernés tous les comptes GitLab.com et les instances auto-hébergées où le courriel entrant est activé. GitLab Dedicated semble épargné, sans avoir pu être testé.

Ce qu'il faut faire

Réinitialiser le jeton depuis la page des jetons d'accès personnels de votre profil. Toutes vos adresses de projet changent d'un coup : celles que vous utilisez réellement cessent de fonctionner jusqu'à redistribution.
Chercher les adresses publiées dans vos README, guides de contribution et pages de support. Aikido en a trouvé une douzaine, actives, souvent postées exprès pour recevoir des rapports de bugs, dont quelques-unes dans des projets open source répandus.
Terminal
```
grep -rnE -- '-(issue|merge-request)@' --include='*.md' .
```
Sur une instance auto-hébergée, désactiver le courriel entrant à l'échelle de l'instance si personne ne s'en sert. Aucun réglage ne permet à un utilisateur de le couper pour lui seul.

Où en est GitLab

Signalé via HackerOne en mai 2026, le comportement a été classé « intended behavior », puis remonté en ticket confidentiel en juin. Pour GitLab, c'est un jeton comme un autre. L'éditeur a depuis réécrit la description du jeton, qui mentionne désormais les merge requests, et retiré la phrase affirmant qu'il ne donnait accès à aucune autre donnée. Le fonctionnement, lui, n'a pas changé ; un filtrage par adresse vérifiée est seulement à l'étude (issue 617883).

Source : A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You, The Hacker News, 23 septembre 2026, d'après la recherche d'Aikido Security.