Contexte et découverte
Aikido Security a identifié une faille dans le mécanisme d'incoming email token de GitLab. Ce jeton, intégré dans les adresses email privées générées par la plateforme, agit comme un personal access token à portée fine. GitLab indique que le jeton n’expire jamais et qu’il autorise la création d’issues et de merge‑requests au nom de l’utilisateur. Les chercheurs ont constaté que le même jeton était réutilisé pour plusieurs projets appartenant à un même compte, ce qui rend possible la réutilisation d’une adresse compromise sur l’ensemble de ces projets.
Le problème a été signalé via HackerOne en mai 2026, puis confirmé par un rapport confidentiel en juin. GitLab a depuis clarifié la documentation et l’interface, mais n’a pas désactivé la fonctionnalité d’envoi d’emails.
Mode d’exploitation technique
L’attaque repose sur deux vecteurs principaux. Premièrement, l’adversaire modifie le suffixe de l’adresse – de -issue à -merge-request – et joint un fichier .patch. GitLab applique alors le patch sur la branche cible ou crée la branche si elle n’existe pas, ce qui permet de pousser du code avec les droits du propriétaire du jeton. Deuxièmement, le même mécanisme peut injecter un job dans le fichier .gitlab-ci.yml via un patch envoyé par email. Le job déclenché exécute alors une pipeline CI/CD en tant que l’utilisateur légitime.
Une fois la pipeline active, le script peut lire les variables CI/CD et les secrets stockés dans l’environnement du job. De plus, le token CI_JOB_TOKEN fourni à chaque job peut être réutilisé pour appeler d’autres API GitLab, ouvrant l’accès à des dépôts ou à des ressources supplémentaires tant que le job possède les autorisations requises.
Contraintes et portée
L’exploitation est strictement limitée par les permissions déjà attribuées au compte propriétaire du jeton. Un jeton lié à un compte Guest offre peu de valeur, alors qu’un compte Maintainer peut exposer des branches protégées, des variables sensibles et des pipelines complexes. L’attaquant doit également connaître le chemin du projet et son ID pour cibler un dépôt privé ; ces informations sont publiques pour les projets ouverts, mais restent difficiles à obtenir pour les projets fermés sans fuite supplémentaire.
Le jeton ne confère aucun privilège supplémentaire ; il ne « élève » pas les droits au‑delà de ceux déjà accordés à l’utilisateur. Cette limitation réduit l’impact potentiel, mais ne l’élimine pas, notamment dans des environnements où les mainteneurs détiennent des accès critiques.
Mitigation et recommandations
GitLab recommande de réinitialiser le jeton depuis les paramètres de personal access token. La réinitialisation invalide toutes les adresses contenant l’ancien jeton, empêchant toute réutilisation future. Les organisations qui s’appuient sur la création d’issues ou de merge‑requests par email doivent surveiller la diffusion de ces adresses et envisager de désactiver la fonctionnalité si elle n’est pas indispensable.
En outre, il est conseillé de restreindre les permissions des comptes de service, de limiter l’accès aux variables CI/CD aux seuls jobs strictement nécessaires, et d’auditer régulièrement les pipelines déclenchés par email. Une documentation précise et une sensibilisation des équipes de développement aux risques liés aux jetons d’email contribuent à réduire la surface d’attaque.
