Bei GitLab reicht offenbar eine einzige E-Mail, um Code in ein fremdes, sogar privates Repository zu schmuggeln. Der Sicherheitsforscher Joe Leon von Aikido Security hat am 23. September eine Schwachstelle veröffentlicht, die zeigt: Die praktische Funktion, per E-Mail neue Issues anzulegen, ist deutlich mächtiger — und gefährlicher — als sie in der Oberfläche wirkt.
DER TRICK: Ein Token, der für viel mehr gilt als gedacht
GitLab stellt für jedes Projekt eine private E-Mail-Adresse bereit, an die man Nachrichten schicken kann, um automatisch ein Issue zu erstellen. Diese Adresse sieht projektbezogen aus und enthält einen langen, nie ablaufenden Code nach dem Muster glimt-XXXXXXXXXXXXXX. Genau hier liegt das Problem: Der eingebettete Token ist nicht auf das einzelne Projekt beschränkt, sondern gilt für den gesamten Account. Die Oberfläche suggeriert eine Projekt-Grenze, die es technisch gar nicht gibt.
Wer eine solche Adresse in die Finger bekommt — etwa aus einem versehentlich geteilten Screenshot, einem alten Support-Ticket oder einem öffentlichen Code-Repository — kann damit weit mehr als nur ein Issue anlegen.
VOM ISSUE ZUM CODE-PUSH: Wie der Angriff wirklich abläuft
Aikido zeigt in seinem Bericht Schritt für Schritt, wie aus einer harmlos wirkenden Adresse ein Einfallstor wird:
- Ersetzt man im Adress-Muster den Teil „-issue“ durch „-merge-request“, lassen sich über dieselbe E-Mail Merge Requests statt Issues erzeugen.
- Hängt man der Mail eine Git-Patch-Datei an, übernimmt GitLab den enthaltenen Code-Commit — auch auf geschützte Branches wie main, wenn der Token-Besitzer die nötigen Rechte hat.
- Steckt im Patch eine Änderung an der .gitlab-ci.yml, löst das eine automatische CI/CD-Pipeline aus — mit Code, den der Angreifer bestimmt, ausgeführt unter der Identität des eigentlichen Nutzers.
Besonders brisant: Aikido konfigurierte testweise ein privates Projekt so, dass nur eine einzige, nicht zum Angreifer gehörende IP-Adresse zugreifen durfte. Browser-Zugriff und Git-Klonen blockierte GitLab wie erwartet — die per E-Mail eingereichte Patch-Datei wurde trotzdem verarbeitet und landete als Commit auf main. Der E-Mail-Weg umgeht IP-Allowlists komplett, weil er technisch gar nicht über die üblichen Netzwerk-Zugangswege läuft.
GITLABS REAKTION: Nachgebessert, aber nicht gelöst
Der ursprüngliche Bericht wurde von GitLab über HackerOne zunächst als „beabsichtigtes Verhalten“ eingestuft. Erst nach weiteren Beispielen — unter anderem zu vertraulichen Repository-Themen — reagierte das Unternehmen: Irreführende Formulierungen wie „kann nicht für den Zugriff auf andere Daten verwendet werden“ wurden aus der Dokumentation entfernt, und die Oberfläche weist jetzt klarer auf die Merge-Request-Fähigkeit hin. Am eigentlichen Mechanismus — dem kontoweiten, unbefristeten Token — hat sich laut Aikido bislang nichts geändert.
Nutzern fehlen bis heute wichtige Kontrollmöglichkeiten: Es gibt keinen Schalter, um das Anlegen von Issues oder Merge Requests per E-Mail projektweise zu deaktivieren, keine Prüfung der Absenderadresse, keine Möglichkeit zum Massen-Widerruf aller E-Mail-Tokens und keine einstellbare Ablauffrist.
SO SCHÜTZT DU DEIN REPOSITORY
Bis GitLab strukturell nachbessert, hilft nur Eigeninitiative:
- Rotiere die E-Mail-Tokens deiner Projekte, wenn du die Funktion nicht aktiv nutzt.
- Durchsuche deine Repositories und internen Wikis nach versehentlich abgelegten
glimt--Adressen, etwa mit Secret-Scannern. - Verlasse dich nicht auf IP-Allowlists als alleinigen Schutz — der E-Mail-Weg hebelt sie aus.
Für Betreiber von Self-Managed-GitLab-Instanzen im Homelab oder im Unternehmen gilt dasselbe Bild wie bei der Cloud-Variante — die Schwachstelle sitzt im E-Mail-Verarbeitungsmechanismus selbst, nicht in einer bestimmten Hosting-Form.
FAZIT: Bequemlichkeit hat einen blinden Fleck
Die E-Mail-zu-Issue-Funktion war als kleine Komfort-Brücke gedacht, für Teams, die lieber aus dem Postfach als aus der Weboberfläche arbeiten. Dass sich daraus ein Weg zur kompletten Repo-Übernahme samt CI/CD-Ausführung konstruieren lässt, zeigt einmal mehr: Je mehr Nebenwege ein System für dieselbe Aktion anbietet, desto größer wird die Angriffsfläche — unabhängig davon, wie gut die Haupttür gesichert ist.