tl;dr
GitLab stellt Ihnen eine private E-Mail-Adresse zur Erstellung von Issues zur Verfügung. Sollte diese Adresse in falsche Hände geraten, kann jeder, der darüber verfügt, Code hochladen, CI/CD-Jobs ausführen und IP-Beschränkungen in all Ihren öffentlichen und privaten Projekten umgehen. Dies betrifft alle GitLab.com-Konten und selbst gehosteten GitLab-Server, die es Benutzern ermöglichen, Issues per E-Mail zu erstellen.
Was Sie überprüfen müssen
Schritt 1: Ist die Funktion aktiviert?
- GitLab.com: Ja, für jedes Konto. Man kann diese Funktion nicht deaktivieren.
- Selbst gehostetes GitLab: Vielleicht.
- Öffnen Sie die Arbeitslisten eines Ihrer Projekte und klicken Sie auf ⋮. Wenn dort „Arbeitselement an dieses Projekt per E-Mail senden“ oder etwas Ähnliches angezeigt wird, ist die Funktion aktiviert.
- GitLab Dedicated: Nein.
Schritt 2: Hat jemand eine dieser Adressen weitergegeben?
Die Adresse ist nur dann gefährlich, wenn sie sich in den Händen einer anderen Person als dem Eigentümer befindet. Durchsuchen Sie Ihre Repos, Dokumente, das Hilfezentrum und Ihre Wikis nach `@incoming.gitlab.com` (Nutzer mit eigenem Hosting sollten in ihrer eigenen Adresse nach der Domain 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“
- Safe: eingehend + group-project-12346426-issue-@incoming.gitlab.com
AikidoB etterleaks (kostenlos, Open Source) und die secrets -Funktion zur Erkennung von „ “ finden diese Adressen automatisch in Ihren Repositories, auch in älteren Formaten.
Schritt 3: Offengelegte Adressen zurücksetzen
Der Inhaber einer offengelegten E-Mail-Adresse sollte zu „Benutzereinstellungen“ > „Persönliche Zugriffstoken“ > „Token für eingehende E-Mails“ navigieren und auf „Zurücksetzen“ klicken (Direktlink für GitLab.com). Dadurch werden alle seine Projekt-E-Mail-Adressen auf einmal geändert, und die alten funktionieren nicht mehr.
Überprüfen Sie die letzten Commits, insbesondere Änderungen an der Datei „.gitlab-ci.yml“, sowie die letzten Pipeline-Läufe auf Vorgänge, 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 Bezeichnung „Arbeitselement an dieses Projekt senden“.
Wenn du darauf klickst, zeigt GitLab dir eine private E-Mail-Adresse an. Schicke eine beliebige E-Mail an diese Adresse, und es erscheint ein neues Issue in diesem Projekt, dessen Autor du bist.
eingehende+E-project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
Die „glimt“-Zeichenkette in der Mitte dieser Adresse ist ein Zugangsnachweis. Es handelt sich um ein dauerhaft gültiges Token, das mit Ihrem Konto verknüpft ist und niemals abläuft.
Es kann aber noch wesentlich mehr als nur Fehler melden. Jeder, der über diese Adresse verfügt, kann Code hochladen und CI/CD-Jobs in jedem Projekt ausführen, auf das Ihr Konto Zugriff hat.
Wir haben dies anhand eines privaten Projekts getestet, das durch die IP-Einschränkungen von GitLab geschützt war und so konfiguriert war, dass es Verbindungen von einer einzigen Adresse akzeptierte, die nicht unsere eigene war. GitLab blockierte unseren Browser und lehnte den Befehl „git clone“ ab. Die E-Mail wurde jedoch akzeptiert, und der Commit landete im Branch „main“.
Auf dem Papier in der Benutzeroberfläche harmlos
Das Anlegen von Aufgaben per E-Mail ist eine gängige Produktfunktion. Trello, Todoist und Monday.com bieten alle eine entsprechende Funktion an, die auf die gleiche Weise funktioniert: Eine an eine bestimmte Adresse gesendete E-Mail erzeugt eine Arbeitseinheit in einem Projekt. Daher erwarten Nutzer bei GitLab dasselbe.
Und die Benutzeroberfläche von GitLab bestätigte dies. Das Modalfenster teilte den Nutzern mit, dass die Adresse ausschließlich ihnen gehört und dass dadurch Elemente zu diesem Projekt hinzugefügt werden.
Auf der Seite „Persönliche Zugriffstoken“ (unter „Benutzereinstellungen“) wurde alles andere ausgeschlossen. Laut GitLab dient das Token für eingehende E-Mails dazu, dich zu authentifizieren, wenn du per E-Mail ein neues Issue erstellst, und es „kann nicht für den Zugriff auf andere Daten verwendet werden“.
Das ist das mentale Modell, das GitLab-Nutzern verbleibt. Es handelt sich um eine E-Mail-Adresse, mit der man innerhalb eines bestimmten Projekts Issues erstellen kann, und sie sollte vertraulich behandelt werden.
Hinweis: Nachdem ich mich an GitLab gewandt hatte, haben sie den Text „und Merge-Anfragen“ zu beiden UI-Elementen hinzugefügt.
Meine E-Mail-Adresse lautet PAT?
GitLab hat zwar Recht, dass man diese E-Mail-Adresse geheim halten sollte, doch das Unternehmen spielt das Risiko herunter. Das Token in dieser E-Mail-Adresse ist im Grunde ein detailliertes persönliches Zugriffstoken, das umfangreichen Zugriff auf Ihre GitLab-Projekte gewährt.
Zugriff auf das gesamte Konto
Öffnet man „Workitem per E-Mail an dieses Projekt senden“ in fünf verschiedenen Projekten, gibt GitLab fünf verschiedene Adressen aus. Das in jeder Adresse eingebettete „glimt“-Token ist identisch, auch in privaten Projekten.
In der Benutzeroberfläche wird die Adresse als projektbezogen dargestellt, die darin enthaltenen Anmeldedaten sind es jedoch nicht. Dieses Token gilt für Ihr gesamtes Konto und gilt für jedes Projekt, auf das Sie Zugriff haben – egal, ob öffentlich oder privat.
Der Absender spielt keine Rolle
GitLab überprüft den Absender nicht. Grundsätzlich würde die Überprüfung, ob die Absenderadresse mit der E-Mail-Adresse des Token-Inhabers übereinstimmt, eine zusätzliche Sicherheitsstufe darstellen, doch GitLab führt diese Überprüfung nicht durch (obwohl dies derzeit in Erwägung gezogen wird). Jede E-Mail-Adresse im Internet kann eine Nachricht an diese Adresse senden, und GitLab verarbeitet die Nachricht als stammend vom Token-Inhaber. Wer über diese Adresse verfügt, verfügt sowohl über die Authentifizierung als auch über die Autorisierung.
Von Problemen zum Code
Ersetze das Suffix „-issue“ in der E-Mail-Adresse durch „-merge-request“, und GitLab eröffnet einen Merge-Request.
Das allein reicht noch nicht aus, da ein Angreifer den Merge-Request nicht auf einen von ihm kontrollierten bösartigen Fork richten kann. Allerdings lassen E-Mails zu Merge-Requests einen Git-.patch-Anhang zu, und GitLab wendet diese Änderungen auf den Quellzweig an. Wenn der Patch die Datei „.gitlab-ci.yml“ betrifft und die Rolle des Opfers dies zulässt, führt GitLab den Job des Angreifers aus.
Der gesamte Weg, von Anfang bis Ende:
- Das Opfer veröffentlicht oder gibt die E-Mail-Adresse für Fehlermeldungen eines Projekts weiter.
- Der Angreifer ersetzt -issue@ durch -merge-request@.
- Der Angreifer erstellt einen Patch, der einen Job zur Datei „.gitlab-ci.yml“ hinzufügt, ohne das Ziel-Repository zu kennen.
- Der Angreifer versendet den Patch per E-Mail und gibt dabei den Quellzweig in der Betreffzeile an. GitLab führt einen Push in diesen Zweig durch, sofern er existiert, und legt ihn andernfalls neu an.
- GitLab führt den Job im Projekt des Opfers aus – und zwar als das Opfer.
Die CI/CD-Ausführung ist ein Ergebnis. Das andere ist ein Commit auf einem beliebigen Branch, auf den das Opfer pushen kann – einschließlich „main“ –, der von ihm erstellt wurde. Jeder, der aus diesem Repository eine Build-Version erstellt, bezieht den Code des Angreifers mit ein.
E-Mails umgehen IP-Beschränkungen
Wir haben den Zugriff auf ein privates Projekt auf eine einzige IP-Adresse beschränkt, die nicht zu uns gehörte.
GitLab hat unseren Browser blockiert und unsere „git clone“-Befehle abgelehnt. Eine E-Mail mit einer Merge-Anfrage wurde jedoch weiterhin akzeptiert.
Teams aktivieren IP-Beschränkungen in der Annahme, damit eine Sicherheitsgrenze um ein Projekt gezogen zu haben – häufig am Rand des Unternehmens-VPNs. Diese Grenze gilt zwar für HTTP und SSH, nicht jedoch für eingehende E-Mails. Ein Angreifer, der das Projekt vom Netzwerk aus nicht erreichen kann, gelangt stattdessen über den E-Mail-Pfad dorthin.
Welche Adresse erhält ein Angreifer?
Schon eine einzige offengelegte E-Mail-Adresse kann das GitLab-Konto eines Nutzers oder einer Organisation ernsthaft gefährden. Wir haben jeden dieser Angriffswege anhand von Projekten, die wir kontrollieren, überprüft:
- Code in einen geschützten Zweig in einem privaten Repository hinter einer IP-Zulassungsliste hochladen.
- Exfiltration von Quellcode aus privaten Projekten hinter einer IP-Whitelist.
- CI/CD-Variablen und „ secrets “ aus privaten Projekten auslesen.
- Zugriff auf vertrauliche Themen in privaten Projekten (über die Schnellaktion „/move“)
- Nutzung des in CI/CD-Jobs verfügbaren CI_JOB_TOKEN, um tiefer in das Konto einzudringen.
Eine GitLab-E-Mail-Adresse für eingehende Nachrichten enthält ein Token, das wie ein detailliertes persönliches Zugriffstoken mit weitreichenden Berechtigungen funktioniert.
Der wichtigste Unterschied besteht darin, dass die Nutzer nicht über die API auf GitLab zugreifen, sondern Daten per E-Mail übermitteln müssen. Aus Sicht eines Sicherheitsverantwortlichen stellt sich die Frage: Wenn dies zu einer Kompromittierung des Kontos führen kann, spielt es dann eine Rolle, ob es sich um eine HTTP-Anfrage oder um 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 es gibt keine Stelle im E-Mail-Pfad, an der diese Berechtigungen erweitert werden.
Die Berechtigungen des Opfers begrenzten den Schaden. Eine offengelegte „Guest“-Adresse ist so gut wie wertlos. Eine offengelegte „Maintainer“-Adresse könnte jedoch Zugriff auf geschützte Branches und CI/CD-Variablen ermöglichen. Diese Grenze wird nicht durch den E-Mail-Pfad festgelegt, sondern ausschließlich durch die Rolle des Opfers.
2. Für die Weiterleitung muss bekannt sein, welches Projekt als Ziel dient.
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 anzusteuern, 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 benötigt ein Angreifer eine Informationsleck, aus der der Name des Projekts hervorgeht (die ID lässt sich erraten).
Ein Dutzend, absichtlich veröffentlicht
All das setzt voraus, dass ein Angreifer eine E-Mail-Adresse in die Hände bekommt. Wir haben einen Nachmittag damit verbracht, öffentliche Dokumentationen zu durchsuchen, und konnten mühelos ein Dutzend aktive E-Mail-Adressen in README-Dateien, Leitfäden für Mitwirkende und Support-Seiten ausfindig machen. Fast jede davon war absichtlich veröffentlicht worden – von einem Betreuer, der den Nutzern mitteilte, wohin sie Fehlerberichte senden sollten! Einige davon gehörten zu sehr beliebten Open-Source-Projekten.
Das ist kein Benutzerfehler. Eine E-Mail-Adresse ist die einzige Kennung, die dazu dient, weitergegeben zu werden. GitLab bezeichnet diese als E-Mail-Adresse, formatiert sie entsprechend und stellt Ihnen eine Schaltfläche zum Kopieren zur Verfügung. Nichts daran sieht wie ein Anmeldedaten aus.
Im Modal-Fenster wird zwar darauf hingewiesen, dass die Adresse privat bleiben soll, und es wird davor gewarnt, dass jeder, der die Adresse besitzt, in Ihrem Namen Arbeitselemente erstellen kann. Diese Warnung bezieht sich auf Spam. Sie bezieht sich nicht auf Code-Pushes und Pipeline-Läufe in allen Projekten des Kontos.
Wir haben die betroffenen Konten vor der Veröffentlichung benachrichtigt. Leider verfügt GitLab über keine Möglichkeit, diese Tokens pauschal zu widerrufen oder die Nutzer zu benachrichtigen, sodass unsere Bemühungen nur teilweise erfolgreich waren.
Wer ist betroffen?
Jedes GitLab.com-Konto und jede selbstverwaltete Instanz, bei der der Empfang von E-Mails aktiviert ist. GitLab beschränkt die Dokumentation zum E-Mail-Empfang auf selbstverwaltete Instanzen und GitLab.com, sodass GitLab Dedicated offenbar nicht betroffen ist. Wir konnten dies nicht direkt testen.
Keiner dieser Benutzer kann diese Funktion deaktivieren. Es gibt keine Einstellung, um das Erstellen von Issues per E-Mail zu deaktivieren, keine Einstellung, um das Erstellen von Merge-Anfragen per E-Mail zu deaktivieren, und keine Möglichkeit, zu verlangen, dass der Absender über eine verifizierte Adresse verfügt. Das Token läuft nicht ab. Die einzige Kontrollmöglichkeit, die GitLab Ihnen bietet, ist der Link zum Zurücksetzen auf Ihrer Seite für persönliche Zugriffstoken, und durch das Zurücksetzen werden alle Ihre Projektadressen ungültig.
Offenlegung gegenüber GitLab
Das ist keine typische „Sicherheitslücke“. Es handelt sich zum einen um enttäuschte Nutzererwartungen und zum anderen um unsichere Standardeinstellungen. Wir haben den Fehler im Mai 2026 über HackerOne gemeldet, aber er wurde als beabsichtigtes Verhalten abgehakt (was keine Überraschung war). Im Juni 2026 haben wir im GitLab-Repository ein vertrauliches Ticket erstellt und darauf eine ausführlichere Antwort erhalten.
GitLab vertritt unserer Auffassung nach den Standpunkt, dass es sich hierbei um ein Token wie jedes andere handelt und dass jedes offengelegte Token negative Folgen nach sich zieht. Das beschreibt, wie sich jede Anmeldeinformation verhält, sobald ein Angreifer sie in seinen Händen hält, und es ist zutreffend. Allerdings wird dabei außer Acht gelassen, was dieses Token von anderen unterscheidet. GitLab hat eine Anmeldeinformation entwickelt, die Zugriff auf jedes Projekt im Konto gewährt und IP-Beschränkungen umgeht, und diese dann als E-Mail-Adresse präsentiert.
Als Reaktion auf unseren Bericht hat GitLab ein Update mit drei Änderungen veröffentlicht:
- Der Text „Es kann nicht zum Zugriff auf andere Daten verwendet werden“ wurde aus der Benutzeroberfläche entfernt.
- Es wurde „und Merge-Anfragen“ hinzugefügt, wo in der Benutzeroberfläche zuvor stand, dass die Adresse nur Arbeitselemente erstellen könne.
- Es wurde dokumentiert, dass eingehende E-Mails keinen IP-Beschränkungen unterliegen.
Das ist eine angemessene Reaktion auf unseren Bericht, aber die Aktualisierungen vermitteln immer noch nicht das gesamte Risiko. Ein Nutzer, der „Merge-Anfragen“ liest, erfährt nicht, dass die Adresse ein Token enthält, mit dem Code übertragen, CI/CD-Jobs ausgeführt und von außerhalb einer IP-Whitelist gearbeitet wird. An keiner Stelle wird erwähnt, dass dieses Token auf jedes Projekt im Konto Zugriff hat.
Auch GitLab hat den zugrunde liegenden Mechanismus unverändert gelassen. Die größte Verringerung der Angriffsfläche würde darin bestehen, zu verlangen, dass die Absenderadresse mit der des GitLab-Kontos übereinstimmt. Ein Angreifer müsste dann Zugriff auf das E-Mail-Konto des Opfers haben, nicht nur auf dessen Adresse.
Wie wir diese erkennen
Wir haben die Abdeckung von Betterleaks erweitert, um alle Arten von E-Mail-Tokens in eingehenden GitLab-E-Mails zu identifizieren, darunter:
- Token mit dem Präfix `glimt-`
- benutzerdefinierte Token mit Präfix
- Token, die geprägt wurden, bevor das Präfix „glimt-“ existierte
Betterleaks erkennt mittlerweile mehr Token-Formate für eingehende E-Mails bei GitLab als jeder andere Secret-Scanner, einschließlich GitLab selbst.
AikidoDie „ secrets “-Erkennung deckt dieselben Bereiche ab wie Betterleaks – und zwar in all Ihren Repositories und Merge-Anfragen. Sollten Ergebnisse auftreten, ändern Sie Ihre Zugangsdaten umgehend.
Eine durchgesickerte GitLab-E-Mail-Adresse bietet Angreifern einen weiteren Angriffsvektor, um Schadcode zu verbreiten und eine Lieferkette zu kompromittieren. Erwägen Sie den Einsatz von „Safe Chain“ oder „Device Protection“ von Aikido, um zu verhindern, dass Sie (oder Ihr Team) versehentlich kompromittierte Pakete installieren. „Safe Chain“ ist eine Open-Source-Befehlszeilenschnittstelle (CLI), die npm, pip und andere Paketmanager umschließt, um bekannte Malware bereits vor der Installation zu blockieren. „Device Protection“ erfüllt denselben Zweck für Teams, indem es schädliche Pakete blockiert, Installationen organisationsweit protokolliert und Genehmigungsrichtlinien durchsetzt. Keines der beiden Tools hindert einen Token-Inhaber daran, Code zu veröffentlichen, aber sie tragen dazu bei, zu verhindern, dass eine über einen kompromittierten Commit hinzugefügte schädliche Abhängigkeit auf dem Rechner eines Entwicklers oder in einem Build ausgeführt wird.
