GitLab-Lücke: Wie gefährlich ist die Issue-E-Mail-Adresse?

GitLab-Lücke per E-Mail: Eine öffentliche Issue-Adresse genügt für Code auf dem Main-Branch

Markus Seyfferth

Autor Dr. Web

24. September 2026

3 Min. Lesezeit

Die GitLab-Lücke steckt in einer Adresse, die viele Open-Source-Projekte selbst in ihre Dokumentation schreiben: der E-Mail-Adresse, über die Nutzer Issues anlegen. Das Sicherheitsunternehmen Aikido Security zeigt, wie Angreifer darüber Code auf geschützte Branches schieben und CI-Jobs im Namen des Kontoinhabers starten. GitLab verzichtet auf einen Patch und stuft das Verhalten als beabsichtigt ein.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Mit einer geleakten Adresse braucht ein Angreifer laut Aikido nur einen Patch im Anhang und den Ziel-Branch „main“ in der Betreffzeile, um über GitLabs Funktion „Email work item to this project“ einen Commit in ein fremdes Projekt zu schieben. Der Commit trägt den Namen des Opfers, die Pipeline läuft mit dessen Rechten.

Das Wichtigste in Kürze

Die Issue-Adresse enthält ein kontoweites Token mit dem Präfix „glimt-“, das nie abläuft.
Mit der Endung „-merge-request“ statt „-issue“ macht GitLab aus einem angehängten Patch einen Commit des Kontoinhabers.
IP-Allowlists greifen auf dem Mail-Weg nicht, auch nicht bei privaten Projekten.
GitLab schloss die Meldung im Mai als beabsichtigtes Verhalten und änderte nur die Dokumentation.

Wie wird aus einer Kontaktadresse ein Zugangsschlüssel?

Briefumschlag mit Schlüssel und Anhänger in Draufsicht auf weißem Hintergrund — GitLab-URLs enthalten kontoweite Zugangstoken, die nicht ablaufen und geheim bleiben sollen. Aikido fand heraus, dass verschiedene Projekte dasselbe Token nutzen

Technisch steckt in der Adresse ein Zugangstoken. Das Token nach „glimt-“ gehört zum Benutzerkonto, läuft nie ab und soll laut GitLab geheim bleiben. Aikido stellte fest, dass die Adressen verschiedener Projekte dasselbe kontoweite Token enthalten.^[1]

Den entscheidenden Fehler macht GitLab beim Eingang: Eine Absenderprüfung findet nicht statt. Jedes Postfach im Internet darf die Adresse anschreiben, Zwei-Faktor-Anmeldung und Single Sign-on spielen auf diesem Weg keine Rolle. Hängt ein Angreifer eine präparierte „.gitlab-ci.yml“ als Patch an, wendet GitLab die Änderung auf den genannten Branch an. Bei einem Maintainer-Konto trifft der Angriff auch geschützte Branches.^[1]

Selbst die IP-Allowlist hält den Angriff nicht auf. Aikido sperrte ein privates Testprojekt für alle Netze außer einer fremden IP-Adresse. Browserzugriff und git clone scheiterten, der per E-Mail geschickte Patch landete trotzdem als Commit auf dem Main-Branch. Über die ausgelöste Pipeline erreichen Angreifer anschließend CI/CD-Variablen, Job-Tokens und vertrauliche Issues.^[1]

Warum bleibt der Mail-Kanal ein Einfallstor?

Ein Präzedenzfall liegt neun Jahre zurück. Mit dem „Ticket Trick“ zeigte der Sicherheitsforscher Inti De Ceukelaire 2017, dass Issue-Adressen als Firmen-Mailadresse durchgehen: Mit einer Adresse auf @gitlab.com trat er dem internen Slack-Workspace von GitLab bei.^[2] Das Grundproblem blieb: Ein Postfach, das jeder anschreiben darf, taugt nicht als Berechtigungsnachweis.

Hinzu kommen langlebige Zugangsdaten, ein Dauerbrenner der Branche. Beim Snowflake-Hack öffneten vier Jahre alte Passwörter 165 Firmenkonten. Auch diesmal liegt die Abwehr bei den Betreibern, nicht beim Hersteller.

Von der Kontaktadresse zum Commit auf main

So nutzen Angreifer GitLabs Funktion für Issues per E-Mail

1 Token

für alle Projektadressen eines Kontos, ohne Ablaufdatum

Prüfungen des Absenders, jedes Postfach darf schreiben

rund 12

aktive Adressen fand Aikido öffentlich in Projektdokumentationen

Der Angriff in vier Schritten

Adresse finden

Die Issue-Adresse steht in einer README oder auf einer Support-Seite.

Endung tauschen

„-merge-request“ statt „-issue“, dazu ein Patch für die CI-Konfiguration.

Commit landet

GitLab übernimmt den Patch im Namen des Opfers, IP-Allowlist inklusive.

Pipeline liest Geheimnisse

Der CI-Job erreicht Variablen, Job-Tokens und vertrauliche Issues.

Eine E-Mail-Adresse, die jeder anschreiben darf, sollte nie Code auf den Main-Branch bringen. GitLab nennt das beabsichtigt, für betroffene Teams steht damit ein Generalschlüssel in der eigenen README.
— Michael Dobler, Herausgeber Dr. Web

Was sollten GitLab-Teams jetzt tun?

Den Anfang macht ein neues Incoming-Token. Im Profil unter den persönlichen Zugriffstokens setzen Nutzer das Token zurück, alle Projektadressen des Kontos ändern sich damit auf einen Schlag. Abschalten lässt sich die Funktion für einzelne Nutzer nicht. Betroffen sind GitLab.com und selbst betriebene Instanzen mit aktivem E-Mail-Eingang, GitLab Dedicated nach Aikidos Einschätzung nicht.^[1]

Parallel gehören Repositories, Wikis und Support-Seiten auf veröffentlichte Incoming-Adressen durchsucht. Findet ein Secret-Scanner eine Adresse, behandeln Teams sie wie ein geleaktes Passwort und rotieren das Token. Danach folgt der Blick in neue Merge Requests und Pipeline-Protokolle; CI-Variablen mit Produktivzugriff bekommen neue Werte.

Unternehmen, die unter das NIS2-Umsetzungsgesetz fallen, müssen die Sicherheit ihrer Software-Lieferkette ausdrücklich im Risikomanagement abbilden. Eine IP-Allowlist, die den Mail-Pfad nicht abdeckt, gehört deshalb in die nächste Risikobewertung. Die Cybersecurity-Grundlagen fassen die Pflichten für kleine und mittlere Unternehmen zusammen.

FAQ: GitLab-Lücke über die Issue-E-Mail-Adresse

Was ist die GitLab-Lücke mit der Issue-E-Mail-Adresse?

GitLab erzeugt für jedes Projekt eine Adresse, über die Nutzer Issues per E-Mail anlegen. Darin steckt ein kontoweites Token, das nie abläuft. Mit der Endung „-merge-request“ und einem angehängten Patch schieben Angreifer Code in Projekte, auf die der Kontoinhaber Schreibrechte hat.

Hat GitLab die Lücke geschlossen?

Nein. GitLab schloss die Meldung von Aikido Security im Mai 2026 als beabsichtigtes Verhalten und passte nur die Dokumentation an. Das Token läuft weiterhin nicht ab. GitLab prüft den Absender eingehender E-Mails nicht.

Schützt eine IP-Allowlist vor dem Angriff?

Nein. Aikido sperrte ein privates Projekt für alle Netze außer einer fremden IP-Adresse. Browserzugriff und git clone scheiterten, der per E-Mail geschickte Patch landete trotzdem als Commit auf dem Main-Branch.

Wie schützen Sie Ihr GitLab-Konto?

Setzen Sie im Profil unter den persönlichen Zugriffstokens das Incoming-E-Mail-Token zurück. Damit ändern sich alle Projektadressen Ihres Kontos. Durchsuchen Sie danach READMEs, Wikis und Support-Seiten nach veröffentlichten Adressen und prüfen Sie neue Merge Requests und Pipeline-Protokolle.