Aikido Security zeigte, wie sich die Adresse über die GitLab-Funktion “Merge Request per E-Mail” in einen Weg zum Code-Commit verwandeln lässt. Der Merge Request selbst kann nicht auf eine vom Angreifer kontrollierte Kopie des Projekts gerichtet werden – deshalb transportiert der angehängte Patch den Code, nicht der Merge Request.
Zwei Umstände begrenzen den Schaden. Der Token trägt ausschließlich die Rechte des jeweiligen Kontos: Eine geleakte Adresse eines Guest-Accounts ist nahezu wertlos, die eines Maintainers eröffnet dagegen Zugriff auf geschützte Branches und CI/CD-Geheimnisse. Zudem reicht die Adresse allein nicht, um ein bestimmtes Projekt zu treffen. GitLab ermittelt das Ziel aus dem Projektpfad und der numerischen Projekt-ID; ein Angreifer benötigt also beides zusätzlich zum Token. Bei öffentlichen Projekten sind Pfad und ID frei einsehbar, bei privaten Projekten braucht es ein separates Leck – wobei die Projekt-IDs von GitLab leicht zu erraten sind.
Besonders unangenehm: Eingehende E-Mails unterliegen laut GitLab-Dokumentation keinen IP-Beschränkungen. Der Angriff kann damit von außerhalb einer IP-Freigabeliste erfolgen. Aikido beschränkte in einem Test ein privates Projekt auf eine einzige IP-Adresse, die nicht die eigene war. GitLab blockierte daraufhin den Browserzugriff und verweigerte ein git clone – akzeptierte aber die Merge-Request-E-Mail, und der Commit landete auf main.
Auch die Zwei-Faktor-Authentifizierung wird auf diesem Weg umgangen. Die Dokumentation von GitLab hält fest, dass die Funktionen für eingehende E-Mails ohne 2FA arbeiten, selbst auf Instanzen, die 2FA verpflichtend vorschreiben.
Jedes Konto auf GitLab.com besitzt einen solchen Token, ebenso jede selbstverwaltete GitLab-Instanz mit aktiviertem E-Mail-Eingang – auf GitLab.com ist das die Voreinstellung. GitLab Dedicated scheint nicht betroffen zu sein, da GitLab die Funktion auf selbstverwaltete Instanzen und GitLab.com beschränkt; Aikido konnte Dedicated allerdings nicht direkt testen. Andere Nutzer von der Funktion abzuhalten, ist nicht möglich, eine geleakte Adresse lässt sich jedoch entwerten.
Nach dem Bericht von Aikido änderte GitLab den Text rund um den Token. Die Beschreibung nennt nun auch die Erstellung von Merge Requests, zuvor war nur von Arbeitselementen die Rede; zudem entfernte GitLab einen Satz, dem zufolge der Token keinen Zugriff auf andere Daten ermögliche. Am Verhalten selbst hat sich nichts geändert: Der Token läuft weiterhin nicht ab, GitLab prüft den Absender der E-Mail weiterhin nicht, und es gibt nach wie vor keinen Schalter, mit dem einzelne Nutzer die Funktion abschalten könnten.
GitLab hat ein Issue eröffnet, um zu prüfen, ob solche E-Mails künftig nur noch von einer beim Kontoinhaber verifizierten Adresse angenommen werden. Das befindet sich jedoch erst in der Prüfung und ist nicht umgesetzt.
Aikido meldete das Verhalten nach eigenen Angaben zunächst im Mai 2026 über HackerOne, wo der Bericht als beabsichtigtes Verhalten geschlossen wurde, und reichte im Juni ein vertrauliches Issue bei GitLab ein. GitLabs Position lautet Aikido zufolge, es handle sich um einen Token wie jeden anderen, und jede geleakte Zugangsinformation führe zu schlechten Ergebnissen. The Hacker News hat GitLab und Aikido um eine Stellungnahme gebeten.