Was geschah
GitLab gibt jedem User eine private Email-Adresse, mit der er Issues per Mail anlegt. Die Adresse sieht projektspezifisch aus, enthält ein Token und — so die Doku — läuft nicht ab. Aikido Security hat herausgefunden, dass dieses Token weit mehr kann als Issues öffnen: Wer es besitzt, kann Code committen, Branches including main erstellen und CI/CD-Jobs unter fremdem Namen ausführen. Ohne Passwort, ohne 2FA, ohne IP-Allowlist — und GitLab prüft nicht, wer die Mail geschickt hat.
Berichtet wurde es zuerst im Mai 2026 über HackerOne — dort als „intended behavior" geschlossen. Nach einem vertraulichen Issue im Juni hat GitLab immerhin die Beschreibungstexte aktualisiert und ein Ticket geöffnet, um Mails nur von verifizierten Adressen zu akzeptieren. Geändert hat sich am Verhalten bis heute nichts.
Der Mechanismus
Die Adresse, die GitLab pro User und Projekt anzeigt, hat ein Suffix wie -issue. Aikido fand drei Dinge, die aus dem harmlosen Issue-Eingang einen Angriffspfad machen:
1. Das Token gilt global, nicht pro Projekt. Die Adressen für verschiedene Projekte eines Users sehen unterschiedlich, enthalten aber dasselbe Token. Es funktioniert für jedes Projekt, auf das der Account Zugriff hat — öffentlich wie privat.
2. GitLab prüft den Absender nicht. Jedes Postfach kann an die Adresse schreiben; GitLab behandelt die Mail, als käme sie vom Account-Inhaber.
3. Das Suffix bestimmt, was passiert. Ändert man -issue zu -merge-request, öffnet GitLab statt eines Issues einen Merge Request. Und der kann einen Patch tragen.
Der Pfad zu main
Der Merge-Request-per-Email-Weg nutzt GitLabs eigene Dokumentation:
- Suffix von
-issueauf-merge-requeständern. - Patch schreiben, Ziel-Branch in den Betreff.
- Patch anhängen und abschicken.
GitLab wendet den Patch auf den Branch an — und legt den Branch an, falls er noch nicht existiert. Der Commit landet unter deinem Namen. Kannst du auf main pushen, kann es der Angreifer auch. Bearbeitet der Patch die .gitlab-ci.yml und erlaubt deine Rolle das, läuft der Angreifer-Job als du — mit Zugriff auf CI/CD-Secrets, Runner, alles, was die Pipeline hergibt.
Was es schlimmer macht
Zwei Eigenschaften umgehen Sicherheitskontrollen, die Administratoren explizit eingesetzt haben:
- IP-Allowlists: Eingehende Mails sind von IP-Beschränkungen ausgenommen. Aikido sperrte ein Projekt auf eine einzelne IP, die nicht ihre eigene war — Browser und
git clonewurden blockiert, die Merge-Request-Mail ging trotzdem durch und der Commit landete aufmain. - 2FA: Eingehende Email-Funktionen arbeiten ohne Zweifaktor, auch auf Instanzen, die ihn sonst erzwingen.
Betroffen: jeder GitLab.com-Account und jede Self-Managed-Instanz mit aktiviertem Incoming Email (Default auf GitLab.com). GitLab Dedicated ist wahrscheinlich nicht betroffen, ließ sich aber nicht direkt testen.
Was den Schaden begrenzt
Das Token trägt nur die Rechte des Accounts. Ein geleaktes Token eines Guests ist nahezu wirkungslos; eines Maintainers öffnet geschützte Branches und CI/CD-Secrets. Und der Angreifer braucht neben dem Token auch Projektpfad und numerische Projekt-ID — beides bei öffentlichen Projekten frei zugänglich, bei privaten ein separater Leak. Aber: GitLads Projekt-IDs sind leicht zu raten (sequenziell).
Was zu tun ist
- Token zurücksetzen: In den Personal Access Tokens in den Profileinstellungen gibt es den Incoming Email Token. Reset ersetzt alle Projekt-Adressen auf einmal — alte Adressen funktionieren sofort nicht mehr.
- Eigene Dokumente prüfen: READMEs, Contributing Guides, Support-Seiten nach veröffentlichten Adressen durchsuchen. Aikido fand etwa ein Dutzend live Adressen, einige in weit verbreiteten Open-Source-Projekten — meist absichtlich als Bug-Report-Adresse gepostet.
- Self-Managed: Administratoren können Incoming Email für die ganze Instanz deaktivieren. Eine einzelne User-Einstellung zum Abschalten gibt es nicht.
GitLads Doku sagt jetzt, dass die Adresse Issues und Merge Requests erstellen kann — vorher stand dort nur „work items". Die Zeile, das Token könne nicht für andere Daten verwendet werden, wurde entfernt. Das Verhalten selbst ist unverändert: Token verfällt nicht, Absender wird nicht geprüft, kein Opt-Out für Einzeluser.
Die eigentliche Lektion
Ein Credential, das nicht als solches beschriftet ist, verhält sich trotzdem wie eines. GitLads Position — „es ist ein Token wie jedes andere, und geleakte Credentials führen zu schlechten Ergebnissen" — ist formal richtig, aber sie verkennt, dass Nutzer diese Adresse nicht wie ein Credential behandeln, weil GitLab sie nicht so präsentiert. Sie steht hinter einem Button namens „Email work item to this project", nicht unter „Access Tokens". Dass sie in READMEs und Support-Seiten landet, ist keine Nachlässigkeit, sondern die nahe liegende Konsequenz einer falschen Mental Model.
Dazu kommt: Wenn ein Token IP-Allowlists und 2FA umgeht, ist es kein Token „wie jedes andere" — es ist ein Token, das die Kontrollen unterläuft, die Admins explizit eingesetzt haben. Die Lektion ist nicht neu, aber sie wiederholt sich: Security-Design sollte danach bemessen werden, was ein Credential im Worst Case erlaubt, nicht danach, was es im Happy Path tut.