Kurzfassung
GitLab stellt Ihnen eine private E-Mail-Adresse zur Erstellung von Issues zur Verfügung. Wenn diese geleakt wird, kann jeder, der sie besitzt, Code pushen, CI/CD-Jobs ausführen und IP-Beschränkungen für all Ihre öffentlichen und privaten Projekte umgehen. Dies betrifft alle GitLab.com-Konten sowie selbst gehostete GitLab-Server, bei denen Benutzer Issues per E-Mail erstellen können.
Worauf Sie achten müssen
Schritt 1: Ist das Feature aktiviert?
- GitLab.com: Ja, für jedes Konto. Sie können es nicht deaktivieren.
- Selbst gehostetes GitLab: Möglicherweise.
- Öffnen Sie die Liste der Work Items eines Ihrer Projekte und klicken Sie auf ⋮. Wenn dort „E-Mail-Work-Item an dieses Projekt senden“ oder Ähnliches steht, ist es aktiv.
- GitLab Dedicated: Nein.
Schritt 2: Hat jemand eine dieser Adressen geteilt?
Die Adresse ist nur dann gefährlich, wenn sie außer dem Inhaber noch jemand anderes hat. Durchsuchen Sie Ihre Repositories, Dokumentationen, Ihr Help Center und Ihre Wikis nach `@incoming.gitlab.com` (Nutzer von Self-Hosted-Instanzen sollten nach der Domain in ihrer eigenen Adresse suchen). Ein Treffer ist gefährlich, wenn die Adresse vor `-issue` oder `-merge-request` ein Token enthält:
- Gefährlich: incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
- Sicher: incoming+group-project-12346426-issue-@incoming.gitlab.com
Betterleaks (kostenlos, Open Source) und Aikido's secrets detection finden diese Adressen in Ihren Repositories automatisch, einschließlich älterer Formate.
Schritt 3: Geleakte Adressen zurücksetzen
Der Inhaber einer geleakten E-Mail-Adresse sollte zu User settings > Personal access tokens > Incoming email token gehen und auf Zurücksetzen klicken (Direktlink für GitLab.com). Dadurch werden alle Projekt-E-Mail-Adressen des Nutzers auf einmal geändert und die alten funktionieren nicht mehr.
Überprüfen Sie aktuelle Commits – insbesondere Änderungen an `.gitlab-ci.yml` – sowie jüngste Pipeline-Läufe auf Aktivitäten, an die sich der Inhaber der E-Mail-Adresse nicht erinnern kann.
Die ganze Geschichte
GitLab-Projekte verfügen über eine Schaltfläche mit der Aufschrift „Arbeitselement per E-Mail an dieses Projekt senden“.
Wenn Sie darauf klicken, zeigt GitLab Ihnen eine private E-Mail-Adresse. Senden Sie eine beliebige E-Mail an diese Adresse, erscheint ein neues Issue in diesem Projekt, das von Ihnen verfasst wurde.
incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
Der glimt-String in der Mitte dieser Adresse ist ein Credential. Es handelt sich um ein langlebiges Token, das an Ihr Konto gebunden ist und niemals abläuft.
Es tut zudem deutlich mehr als nur Bugs zu erfassen. Jeder, der im Besitz dieser Adresse ist, kann in jedem Projekt, das Ihr Konto erreichen kann, Code pushen und CI/CD-Jobs ausführen.
Wir haben dies an einem privaten Projekt getestet, das durch die IP-Beschränkungen von GitLab geschützt und so konfiguriert war, dass es Verbindungen von einer einzigen Adresse akzeptiert, die nicht die unsere war. GitLab blockierte unseren Browser und lehnte git clone ab. Die E-Mail wurde jedoch akzeptiert und der Commit landete auf main.
Auf dem Papier in der Benutzeroberfläche harmlos
Das Erstellen von Issues per E-Mail ist eine gängige Produktfunktion. Trello, Todoist und Monday.com bieten alle eine Variante davon an und beschränken diese auf dieselbe Weise. E-Mails an eine eindeutige Adresse erzeugen eine Arbeitseinheit in einem Projekt. Nutzer erwarten daher bei GitLab dasselbe.
Und die GitLab-Benutzeroberfläche bestätigte dies. Das Modal teilte den Nutzern mit, dass die Adresse ganz ihnen gehört und Elemente zu diesem Projekt hinzufügt.
Die Seite für persönliche Zugriffstokens (unter `User settings`) schloss alles andere aus. GitLab gab an, dass das Token für eingehende E-Mails Sie authentifiziert, wenn Sie ein neues Issue per E-Mail erstellen, und dass es „nicht für den Zugriff auf andere Daten verwendet werden kann“.
Das ist das mentale Modell, das bei GitLab-Nutzern verbleibt. Es ist eine E-Mail-Adresse zum Erstellen von Issues innerhalb eines bestimmten Projekts, und sie sollte privat gehalten werden.
Hinweis: Nachdem ich GitLab kontaktiert hatte, fügten sie den Text „und Merge Requests“ zu beiden UI-Elementen hinzu.
Meine E-Mail-Adresse ist ein PAT?
GitLab hat recht, dass Sie sie privat halten sollten, aber sie untertreiben das Risiko. Das in dieser E-Mail-Adresse enthaltene Token ist im Wesentlichen ein fein abgestimmtes persönliches Zugriffstoken mit erheblichem Zugriff auf Ihre GitLab-Projekte.
Kontowsweiter Zugriff
Öffnen Sie „Arbeitselement per E-Mail an dieses Projekt senden“ in fünf verschiedenen Projekten, und GitLab gibt Ihnen fünf verschiedene Adressen. Das in jeder einzelnen eingebettete glimt-Token ist identisch, auch bei privaten Projekten.
Die Benutzeroberfläche stellt die Adresse so dar, als sei sie auf das Projekt beschränkt, aber die darin enthaltene Berechtigung ist das nicht. Dieses Token gehört zu Ihrem gesamten Konto und hat Zugriff auf jedes Projekt, auf das Sie Zugriff haben, egal ob öffentlich oder privat.
Der Absender spielt keine Rolle
GitLab verifiziert den Absender nicht. Prinzipiell würde die Überprüfung, ob die Absendertadresse mit der E-Mail des Token-Eigentümers übereinstimmt, eine zusätzliche Verteidigungsschicht darstellen, aber GitLab tut dies nicht (obwohl dies nun erwogen wird). Jedes Postfach im Internet kann an diese Adresse senden, und GitLab verarbeitet die Nachricht als der Eigentümer des Tokens. Wenn Sie die Adresse haben, haben Sie sowohl Authentifizierung als auch Autorisierung.
Von Issues zu Code
Ändern Sie das Suffix -issue in der E-Mail-Adresse zu -merge-request, und GitLab öffnet einen Merge Request.
Das allein ist noch nicht viel, da ein Angreifer den Merge Request nicht auf einen bösartigen Fork lenken kann, den er kontrolliert. Aber Merge-Request-E-Mails akzeptieren einen Git-.patch-Anhang, und GitLab wendet diese Änderungen auf den Quellbranch an. Wenn der Patch .gitlab-ci.yml berührt und die Rolle des Opfers dies zulässt, führt GitLab den Job des Angreifers aus.
Der vollständige Pfad von Anfang bis Ende:
- Das Opfer veröffentlicht oder leakt die Issue-by-Email-Adresse eines Projekts.
- Der Angreifer tauscht -issue@ gegen -merge-request@ aus.
- Der Angreifer schreibt einen Patch, der .gitlab-ci.yml einen Job hinzufügt, ohne Kenntnis des Ziel-Repositories.
- Der Angreifer sendet den Patch per E-Mail und nennt den Quellbranch in der Betreffzeile. GitLab pusht in diesen Branch, falls er existiert, und erstellt ihn, falls nicht.
- GitLab führt den Job im Projekt des Opfers als das Opfer aus.
Die CI/CD-Ausführung ist das eine Ergebnis. Das andere ist ein Commit in einem beliebigen Branch, in den das Opfer pushen kann, einschließlich main, der von ihm autorisiert wurde. Jeder, der aus diesem Repository baut, zieht den Code des Angreifers ein.
E-Mails umgehen IP-Beschränkungen
Wir haben ein privates Projekt auf eine einzige IP-Adresse beschränkt, die nicht unsere war.
GitLab hat unseren Browser blockiert und unsere Git-Clone-Befehle abgelehnt. Dennoch hat es eine Merge-Request-E-Mail akzeptiert.
Teams aktivieren IP-Beschränkungen in dem Glauben, sie hätten eine Sicherheitsgrenze um ein Projekt gezogen, oft am Rand eines Unternehmens-VPNs. Die Grenze gilt für HTTP und SSH, aber nicht für eingehende E-Mails. Ein Angreifer, der das Projekt nicht über das Netzwerk erreichen kann, erreicht es stattdessen über den E-Mail-Pfad.
Was eine einzige Adresse einem Angreifer verschafft
Eine einzige geleakte E-Mail-Adresse kann das GitLab-Konto eines Benutzers oder einer Organisation schwerwiegend kompromittieren. Wir haben jeden dieser Angriffswege an von uns kontrollierten Projekten bestätigt:
- Pushen von Code in einen geschützten Branch in einem privaten Repository hinter einer IP-Allowlist.
- Exfiltrieren von Quellcode aus privaten Projekten hinter einer IP-Allowlist.
- Auslesen von CI/CD-Variablen und Secrets aus privaten Projekten.
- Zugriff auf vertrauliche Issues in privaten Projekten (über die Schnellaktion /move)
- Verwenden des in CI/CD-Jobs verfügbaren CI_JOB_TOKEN, um weiter in das Konto vorzudringen.
Eine eingehende GitLab-E-Mail-Adresse enthält ein Token, das wie ein fein abgestuftes persönliches Zugriffstoken mit erheblichen Berechtigungen fungiert.
Der wichtigste Unterschied besteht darin, dass Nutzer Daten per E-Mail senden müssen, anstatt über die API auf GitLab zuzugreifen. Macht es aus Sicht der Verteidigung – wenn das Ergebnis derselben Kontoübernahme entspricht – einen Unterschied, ob es sich um eine HTTP-Anfrage oder eine E-Mail handelt?
Einschränkungen für Angreifer
Zwei Faktoren schränken einen Angreifer ein, der im Besitz der Adresse ist:
1. Das Token übernimmt die Berechtigungen des Opfers, und der E-Mail-Pfad sieht keinerlei Eskalation dieser Berechtigungen vor.
Die Berechtigungen des Opfers begrenzen den Schaden. Eine geleakte Gast-Adresse ist im Grunde wertlos. Eine geleakte Maintainer-Adresse könnte hingegen auf geschützte Branches und CI/CD-Variablen zugreifen. Kein Mechanismus im E-Mail-Pfad setzt dieses Limit, sondern einzig die Rolle des Opfers.
2. Das Routing erfordert die Kenntnis des Zielprojekts.
GitLab ermittelt das Ziel anhand von zwei Werten in der eingehenden E-Mail-Adresse: dem Projektpfad-Slug und der Projekt-ID. Um ein zweites Projekt zu erreichen, muss ein Angreifer neben dem gestohlenen Token den Pfad und die ID eines anderen Projekts angeben. Bei öffentlichen Projekten veröffentlicht GitLab beide Werte. Bei privaten Projekten ist ein Informationsleck erforderlich, das den Projekt-Namen nennt (die ID ist erratbar).
Ein Dutzend, absichtlich veröffentlicht
Alles Oben genannte setzt voraus, dass ein Angreifer eine E-Mail-Adresse in die Hände bekommt. Wir haben einen Nachmittag lang öffentliche Dokumentationen durchsucht und mühelos ein Dutzend aktive eingehende E-Mail-Adressen in READMEs, Mitwirkenden-Leitfäden und Support-Seiten gefunden. Fast jede davon war absichtlich veröffentlicht worden, weil Maintainer Nutzern mitteilen wollten, wohin sie Bug-Reports senden sollen! Einige gehörten zu sehr populären Open-Source-Projekten.
Dies ist kein Anwenderfehler. Eine E-Mail-Adresse ist schliesslich genau der Bezeichner, der dafür gedacht ist, weitergegeben zu werden. GitLab bezeichnet diese als E-Mail-Adresse, formatiert sie wie eine solche und stellt einen Button zum Kopieren bereit. Nichts an ihr sieht nach einem Anmeldedatensatz aus.
Das Modal weist zwar darauf hin, sie privat zu halten, und warnt, dass jeder, der die Adresse besitzt, Arbeitselemente in Ihrem Namen erstellen kann. Diese Warnung beschreibt jedoch Spam – und eben keine Code-Pushes und Pipeline-Ausführungen für jedes einzelne Projekt im Konto.
Wir haben die betroffenen Konten vor der Veröffentlichung benachrichtigt. Leider bietet GitLab keinen Mechanismus, um diese Tokens gebündelt zu widerrufen oder Nutzer zu benachrichtigen, weshalb unsere Bemühungen gemischte Ergebnisse brachten.
Wer ist betroffen
Jedes GitLab.com-Konto sowie jede Self-Managed-Instanz, bei der eingehende E-Mails aktiviert sind. Da GitLab die Dokumentation zu eingehenden E-Mails auf Self-Managed und GitLab.com beschränkt, scheint GitLab Dedicated nicht betroffen zu sein. Wir konnten dies nicht direkt testen.
Keiner dieser Nutzer kann diese Funktion deaktivieren. Es gibt keine Einstellung, um das Erstellen von Issues per E-Mail zu deaktivieren, keine Option zum Deaktivieren von Merge Requests per E-Mail und keine Möglichkeit zu erzwingen, dass der Absender mit einer verifizierten Adresse übereinstimmt. Das Token läuft nicht ab. Die einzige Kontrollmöglichkeit seitens GitLab ist der Zurücksetzungs-Link auf der Seite für persönliche Zugriffstokens, wobei ein Zurücksetzen jede einzelne Projektadresse ungültig macht, die Sie besitzen.
Offenlegung gegenüber GitLab
Dies ist keine typische „Schwäche“. Es handelt sich zu einem Teil um falsche Nutzererwartungen und zu zwei Teilen um unsichere Standardeinstellungen. Wir haben das Problem im Mai 2026 über HackerOne gemeldet, wo es jedoch als beabsichtigtes Verhalten geschlossen wurde (was keine Überraschung war). Im Juni 2026 reichten wir ein vertrauliches Ticket im GitLab-Repository ein, woraufhin wir eine detailliertere Reaktion erhielten.
GitLabs Standpunkt ist nach unserem Verständnis, dass es sich hierbei um ein Token wie jedes andere handelt und dass jedes geleakte Token zu schlechten Ergebnissen führt. Das beschreibt zwar, wie sich Zugangsdaten verhalten, sobald ein Angreifer sie in den Händen hält, und ist auch korrekt. Es lenkt jedoch davon ab, was dieses Token so besonders macht: GitLab hat ein Token entwickelt, das jedes Projekt im Konto erreicht und IP-Beschränkungen umgeht, es dann aber als E-Mail-Adresse präsentiert.
Als Reaktion auf unseren Bericht hat GitLab ein Update mit drei Änderungen veröffentlicht:
- Entfernung des Hinweises „Es kann nicht für den Zugriff auf andere Daten verwendet werden“ aus der Benutzeroberfläche.
- Ergänzung von „und Merge Requests“ an Stellen, an denen die Benutzeroberfläche zuvor besagte, dass die Adresse nur Arbeitselemente erstellen könne.
- Dokumentation darüber, dass für eingehende E-Mails keine IP-Beschränkungen gelten.
Das ist eine faire Reaktion auf das von uns gemeldete Problem, aber die Aktualisierungen vermitteln das Gesamtrisiko nach wie vor nicht vollständig. Ein Nutzer, der „Merge Requests“ liest, erfährt dadurch nicht, dass die Adresse ein Token enthält, welches Code überträgt, CI/CD-Jobs ausführt und von ausserhalb einer IP-Whitelist funktioniert. Nirgendwo auf der Benutzeroberfläche wird erwähnt, dass dieses Token Zugriff auf jedes einzelne Projekt im Konto gewährt.
GitLab hat zudem den zugrundeliegenden Mechanismus unangetastet gelassen. Die mit Abstand wirksamste Massnahme zur Verringerung der Angriffsfläche wäre die Anforderung, dass die Absenderadresse mit der im GitLab-Konto hinterlegten übereinstimmen muss. Ein Angreifer bräuchte dann Zugriff auf das E-Mail-Konto des Opfers und nicht nur auf eine Adresse.
Wie wir diese erkennen
Wir haben Betterleaks um zusätzliche Abdeckung erweitert, um alle Arten von GitLab-Incoming-Email-Tokens zu identifizieren, darunter:
- Tokens mit dem Präfix `glimt-`
- Tokens mit benutzerdefiniertem Präfix
- Tokens, die erstellt wurden, bevor das Präfix `glimt-` existierte
Betterleaks identifiziert jetzt mehr GitLab-Formate für eingehende E-Mail-Tokens als jeder andere Secret Scanner, einschließlich GitLab.
Die Secrets detection von Aikido deckt Ihre Repositories und Merge Requests mit demselben Umfang wie Betterleaks ab. Wenn Ergebnisse auftauchen, rotieren Sie Ihre Anmeldeinformationen umgehend.
Eine geleakte GitLab-E-Mail-Adresse stellt einen weiteren Vektor dar, über den Bedrohungsakteure böswilligen Code einschleusen und eine Lieferkette kompromisieren können. Erwägen Sie die Verwendung von Aikidos Safe Chain oder Device Protection, um zu verhindern, dass Sie (oder Ihr Team) versehentlich kompromisierte Pakete installieren. Safe Chain ist eine Open-Source-CLI, die npm, pip und andere Paketmanager umschließt, um bekannte Malware vor der Installation zu blockieren. Device Protection tut dasselbe für Teams, indem es bösartige Pakete blockiert, Installationen im gesamten Unternehmen protokolliert und Freigaberichtlinien durchsetzt. Keines von beiden hindert einen Token-Inhaber daran, Code zu pushen, aber sie tragen dazu bei, dass eine über einen kompromittierten Commit hinzugefügte bösartige Abhängigkeit nicht auf dem Rechner einer Entwickelnden oder in einem Build ausgeführt wird.
