Les jetons d'e-mail de GitLab permettent des envois de code et l'exécution de CI sans authentification

Des chercheurs en sécurité chez Aikido Security ont identifié une vulnérabilité significative dans la fonctionnalité d'e-mail entrant de GitLab, permettant aux attaquants de pousser du code et d'exécuter des jobs CI/CD en utilisant uniquement une adresse e-mail divulguée. Signalée à la mi-2026, cette faille affecte à la fois GitLab.com et les instances auto-hébergées où l'e-mail entrant est activé, traitant effectively un jeton d'e-mail statique comme un identifiant hautement privilégié qui contourne les contrôles de sécurité standard tels que l'authentification à deux facteurs et les listes blanches d'adresses IP.

Ce qui s'est passé

Le cœur du problème réside dans la manière dont GitLab gère la conversion des e-mails en éléments de travail. Chaque compte utilisateur sur GitLab se voit attribuer un jeton unique et non expirant intégré dans une adresse e-mail utilisée pour créer des tickets. Bien que cette adresse semble spécifique à un seul projet, Aikido Security a découvert que le jeton sous-jacent est partagé entre tous les projets accessibles par cet utilisateur. Par conséquent, toute personne obtenant cette adresse e-mail peut interagir avec n'importe quel projet public ou privé auquel l'utilisateur a accès, indépendamment du projet ayant initialement affiché l'adresse.

La vulnérabilité va au-delà de la simple création de tickets. En modifiant le suffixe de l'adresse e-mail de -issue à -merge-request, un attaquant peut soumettre des correctifs directement à un dépôt. Si l'attaquant connaît le chemin du projet cible et son ID numérique, il peut envoyer un e-mail contenant un correctif de code en pièce jointe. GitLab traite cet e-mail comme une demande de fusion (merge request), appliquant le correctif à la branche spécifiée. Si l'utilisateur a la permission de pousser vers cette branche, y compris des branches protégées comme main, le code est validé sous l'identité de l'utilisateur. De plus, si le correctif modifie le fichier .gitlab-ci.yml, GitLab exécutera les jobs CI/CD résultants avec les permissions de l'utilisateur, exposant potentiellement des secrets ou compromettant l'infrastructure.

Détails clés

• Jeton partagé : Le jeton d'e-mail est identique pour tous les projets auxquels un utilisateur peut accéder, ce qui signifie qu'une fuite depuis un projet compromet l'accès à tous les autres.
• Absence de vérification de l'expéditeur : GitLab ne vérifie pas l'adresse e-mail de l'expéditeur contre celle du propriétaire du compte, permettant à n'importe quelle boîte aux lettres d'agir en tant que l'utilisateur.
• Contournement des contrôles de sécurité : Les actions liées aux e-mails entrants sont exemptes des restrictions IP et des exigences d'authentification à deux facteurs, même si elles sont appliquées ailleurs.
• Dépendance aux privilèges : L'impact varie selon le rôle de l'utilisateur ; les comptes Invité ont un impact limité, tandis que les Mainteneurs peuvent pousser vers des branches protégées et accéder aux secrets CI.
• Identification de la cible : Les attaquants ont besoin du chemin du projet et de l'ID numérique en plus du jeton, bien que les IDs soient facilement devinables et que les chemins soient souvent publics.
• Pas de désactivation au niveau utilisateur : Les utilisateurs individuels ne peuvent pas désactiver la création de tickets ou de demandes de fusion via e-mail ; seuls les administrateurs d'instance peuvent désactiver la fonctionnalité globalement.

Contexte

La fonctionnalité d'e-mail entrant de GitLab est conçue pour rationaliser le flux de travail en permettant aux utilisateurs de créer des tickets ou des demandes de fusion via des clients de messagerie. Cela est particulièrement utile pour les équipes qui gèrent le triage via des interfaces e-mail ou qui souhaitent abaisser la barrière pour les contributeurs externes signalant des bugs. Le système repose sur une adresse e-mail unique pour chaque combinaison utilisateur-projet, contenant un jeton caché qui authentifie l'action.

Cependant, les jetons d'authentification nécessitent généralement des politiques strictes de confidentialité et de rotation. Dans ce cas, le jeton est statique et n'expire jamais. Bien que GitLab le traite comme un identifiant standard, son intégration avec le système d'e-mail crée un angle mort. Les mesures de sécurité traditionnelles comme le filtrage IP, qui restreint l'accès aux réseaux connus, ne s'appliquent pas au trafic d'e-mail entrant. De même, l'authentification à deux facteurs (2FA), qui ajoute une deuxième couche de vérification pour les connexions, est contournée car le système d'e-mail fait implicitement confiance au jeton sans interroger l'expéditeur.

Pourquoi c'est important

Pour les équipes exploitant des instances GitLab auto-hébergées ou utilisant GitLab.com, cette vulnérabilité met en évidence une lacune critique dans la sécurité de la chaîne d'approvisionnement. Les développeurs partagent souvent des coordonnées dans les fichiers README, les guides de contribution ou les pages de support pour faciliter le signalement de bugs. Si ces documents contiennent l'adresse e-mail spéciale de GitLab, ils publient involontairement un identifiant accordant un droit d'écriture sur le code. Aikido Security a trouvé environ une douzaine de telles adresses actives publiées ouvertement, y compris dans des projets open source largement utilisés.

La capacité de contourner les restrictions IP est particulièrement préoccupante pour les entreprises qui comptent sur la sécurité au niveau réseau pour protéger leurs bases de code. Un attaquant situé hors du réseau d'entreprise peut toujours pousser du code malveillant sur la branche principale s'il possède le jeton d'e-mail. Cela sape l'hypothèse selon laquelle les branches internes sont à l'abri des menaces externes. De plus, l'exécution de jobs CI/CD en tant qu'utilisateur compromis peut entraîner des mouvements latéraux supplémentaires au sein de l'infrastructure, surtout si ces jobs ont accès à des clés de déploiement ou à des identifiants cloud.

Que pouvez-vous faire

• Réinitialisez votre jeton : Accédez à votre page de jetons d'accès personnels dans GitLab et réinitialisez votre jeton d'e-mail entrant. Cela invalide immédiatement toutes les adresses de projet existantes.
• Auditez la documentation publique : Recherchez dans vos READMEs de projet, guides de contribution et pages de support toute adresse e-mail GitLab publiée et supprimez-la.
• Désactivez l'e-mail entrant : Si vous êtes administrateur d'une instance auto-gérée, envisagez de désactiver la fonctionnalité d'e-mail entrant globalement si elle n'est pas essentielle à votre flux de travail.
• Surveillez les demandes de fusion : Gardez un œil attentif sur les demandes de fusion créées via e-mail, en particulier celles ciblant des branches protégées ou modifiant des fichiers de configuration CI.
• Formez les membres de l'équipe : Informez les développeurs que l'adresse e-mail affichée dans le bouton "Email work item" est sensible.