Présentation

GitLab génère pour chaque compte un adresse e‑mail d'issue contenant un token unique. Cette adresse, affichée derrière le bouton « Email work item to this project », permet de créer des tickets en votre nom. Le token, indiqué dans la partie centrale de l’adresse, ne possède aucune date d’expiration et est partagé entre tous les projets accessibles à l’utilisateur, qu’ils soient publics ou privés.

Mécanisme d'exploitation

Le chercheur en sécurité Aikido Security a constaté que le même token est réutilisable pour chaque projet. En modifiant simplement le suffixe -issue en -merge-request, l’adresse accepte un e‑mail qui ouvre une merge request au lieu d’un ticket. Le sujet de l’e‑mail indique la branche cible, le corps contient le patch, et GitLab applique le patch directement sur la branche, créant la branche si elle n’existe pas. Ainsi, un attaquant peut committer du code en votre nom, même sur la branche main si votre rôle le permet. Si le patch modifie le fichier .gitlab-ci.yml, GitLab déclenche immédiatement les jobs CI/CD avec les permissions de l’utilisateur compromis.

project+abcd1234-issue@mygitlab.com          # création d'issue
project+abcd1234-merge-request@mygitlab.com # création de MR

Le service d’e‑mail entrant de GitLab n’applique aucune restriction d’adresse IP et fonctionne sans authentification à deux facteurs, même sur des instances qui exigent 2FA pour les connexions web. Par conséquent, l’attaque peut être lancée depuis l’extérieur d’une liste blanche d’IP.

Implications de sécurité

Le périmètre d’accès dépend du rôle de l’utilisateur dont le token est compromis. Un compte Guest offre peu d’impact, tandis qu’un compte Maintainer peut toucher les branches protégées et accéder aux secrets CI/CD. La découverte du token nécessite le chemin du projet et son identifiant numérique, informations publiquement visibles pour les projets publics et facilement devinables pour les projets privés. Les tokens sont actifs par défaut sur GitLab.com et sur les instances auto‑gérées où la fonctionnalité d’e‑mail entrant est activée, ce qui représente la configuration par défaut.

Mesures d'atténuation

GitLab ne propose pas de désactivation granulaire du token par utilisateur. Les actions possibles sont :

• Réinitialiser le token d’e‑mail entrant depuis la page des jetons d’accès personnels ; la réinitialisation invalide toutes les adresses existantes.

• Sur une instance auto‑gérée, l’administrateur peut désactiver l’e‑mail entrant globalement.

• Auditer les dépôts publics et les documents (README, guides de contribution) afin de retirer les adresses publiées.

GitLab a modifié la description du token pour mentionner explicitement la création de merge requests, mais le comportement technique reste inchangé. Un ticket interne a été ouvert pour envisager la validation de l’expéditeur, mais aucune implémentation n’est encore déployée. Les utilisateurs doivent donc considérer le token comme un credential sensible et le protéger comme tout autre secret d’accès.