LONDON (IT BOLTWISE) – GitLab stellt Nutzern eine private E-Mail-Adresse zum Einreichen von Arbeiten per E-Mail bereit. Gelangt diese Adresse in fremde Hände, kann der Absender Patches so versenden, dass GitLab sie als vom Opfer signiert verarbeitet. Dazu zählen sogar das Starten von CI/CD-Jobs und das Ausführen von Änderungen bis hin zu main. Kritisch: Die E-Mail-Funktion umgeht laut Bericht IP-Einschränkungen und kann 2FA überschreiten.
GitLab nutzt bei der Funktion „Email work item to this project“ eine private E-Mail-Adresse als Zugangsschlüssel: Wer diese Adresse kennt, kann per Mail nicht nur einen Fehler melden, sondern auch Inhalte einreichen, die GitLab danach automatisiert übernimmt. Der Knackpunkt liegt in der Form der Adresse: Im Bericht wird die Zeichenkette als Token beschrieben, das an ein Benutzerkonto gebunden ist und laut GitLab-Dokumentation nicht abläuft. Damit verwandelt sich eine vermeintlich harmlose „E-Mail an das Projekt“-Adresse faktisch in eine maschinenlesbare Authentifizierung, die GitLab ohne verifizierende Prüfung des Absenders als Berechtigung akzeptiert.
Technisch funktioniert das nach dem beschriebenen Muster besonders gefährlich, weil GitLab die eingehende E-Mail nicht als „unbekanntes Kommunikationssignal“ behandelt, sondern als direkte Eingabe in den Projekt-Workflow. Beim Mail-Einlauf erzeugt GitLab ein Issue im Zielprojekt, wobei das Dokument als von der jeweiligen Kontoidentität des Tokens verfasst gilt. Noch mehr Angriffsfläche entsteht durch die beobachtete Token-Generierung: Aikido Security fand, dass die Adresse-Tokens über unterschiedliche Projekte hinweg dasselbe Token teilen können, solange das betroffene Konto diese Projekte öffnen darf. Für Angreifer heißt das: Sie brauchen nicht zwingend „die richtige Projektadresse“, sondern können mit dem Token breite Rechte über mehrere Projekte ausnutzen.
Die eigentliche Eskalation passiert, wenn der Token nicht nur Issues, sondern auch Merge Requests steuern kann. Der Bericht zeigt, dass sich die Zielaktion über die Adresssuffix-Variante umschalten lässt, indem „-issue“ in „-merge-request“ geändert wird. Danach öffnet GitLab statt eines Issues einen Merge Request, und entscheidend ist: Der enthaltene Code liegt im gepatchten Inhalt, den GitLab auf einen Ziel-Branch anwendet. Der Patch wird auf den angegebenen Branch geschrieben, der Branch wird bei Bedarf automatisch erstellt, und der Commit landet laut Beschreibung als Commit „authored by“ der Kontoidentität des Tokenbesitzers. Wenn dieser Branch auch main enthalten kann und wenn die Rollenrechte es zulassen, kann der Prozess bis in produktionsnahe Bereiche reichen.
Damit ist auch die CI/CD-Stufe adressiert: Wird die Patch-Änderung auf Konfigurationen wie die Datei .gitlab-ci.yml ausgerichtet und die Rolle des Opfers besitzt entsprechende Rechte, kann GitLab die Job-Ausführung im Kontext des Tokenbesitzers starten. Besonders brisant ist dabei, dass E-Mail-Eingänge nach Bericht nicht den üblichen IP-Einschränkungen unterliegen; GitLab dokumentiere, dass eingehende E-Mail nicht an IP-Allowlists gebunden sei. Der Report beschreibt zudem einen konkreten Fall, in dem ein privates Projekt eigentlich auf eine einzelne IP-Adresse gelockt war: Der Browserzugriff und ein Git-Clone wurden blockiert, aber die Merge-Request-per-E-Mail-Verarbeitung wurde dennoch akzeptiert und der Commit landete auf main. Das wird umso relevanter, weil die gleiche Passage laut Bericht auch 2FA umgehen kann: Die Incoming-E-Mail-Funktionen würden ohne Zwei-Faktor-Authentifizierung arbeiten, selbst wenn eine Instanz 2FA als verpflichtend konfiguriert.
Für die Risikoeinschätzung nennen die Autoren zwei wichtige Bremsen. Erstens bestimmt die Berechtigungsstufe des Tokeninhabers, wie weit ein Angreifer überhaupt kommen kann: Ein geleakter Token für ein Gastkonto sei „nahezu wirkungslos“, während ein Token für eine Rolle wie Maintainer offenbar Zugang zu geschützten Branches und CI/CD-Secrets ermöglichen kann. Zweitens muss ein Angreifer nicht nur Tokenwissen haben, sondern auch das Zielprojekt präzise adressieren. GitLab ermittle den Zielbezug aus Projektpfad und numerischer ID; öffentliche Projekte veröffentlichen beide Werte, private Projekte benötigen offenbar eine separate Leakinformation, wobei die Projekt-IDs laut Bericht eher einfach zu erraten seien. Zusätzlich unterscheidet der Bericht zwischen GitLab.com und selbst gehosteten Instanzen: Generell sei die Funktion auf GitLab.com standardmäßig aktiv, während GitLab Dedicated nicht getestet worden sei.
Praktische Gegenmaßnahmen lassen sich dennoch greifen, auch wenn man die generelle E-Mail-Workflow-Fähigkeit Dritter nicht vollständig „abschalten“ kann. Empfohlen wird, den Incoming-E-Mail-Token über die personal access tokens im Profil zu resetten; der Reset ersetze laut Beschreibung Adressen für alle Projekte gleichzeitig, wodurch eine aktiv genutzte Adresse sofort ausfällt, bis die neue Adresse verteilt wurde. Unternehmen und Teams sollten zudem nach veröffentlichten Mail-Adressen in READMEs, Contributing-Guides und Support-Dokumentationen suchen. Auf einer selbstverwalteten Instanz könne ein Administrator die Incoming-E-Mail-Funktion serverweit deaktivieren; pro Nutzer soll es hingegen keine Einstellung geben, um E-Mail-basierte Issue- oder Merge-Request-Erstellung gezielt zu stoppen. Auch nach dem Report habe GitLab den Token-Text angepasst (z. B. nun mit expliziter Nennung von Issues und Merge Requests statt nur „work items“), die beschriebenen Kernmechanismen blieben jedoch unverändert: Token läuft nicht ab, der Absender wird nicht geprüft, und es gibt keinen individuellen Switch. Gleichzeitig arbeitet GitLab laut Bericht an Überlegungen, eingehende Mails nur aus verifizierten Absenderadressen zu akzeptieren – im Kern also eine stärkere Bindung des E-Mail-Workflows an die Kontoinhaber-Identität.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Leaked GitLab Issue-Token erlaubt CI/CD und Commits unter fremdem Namen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Leaked GitLab Issue-Token erlaubt CI/CD und Commits unter fremdem Namen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Leaked GitLab Issue-Token erlaubt CI/CD und Commits unter fremdem Namen« bei Google Deutschland suchen, bei Bing oder Google News!