GitLab-E-Mail-Token in READMEs können Angreifern das Pushen von Code ermöglichen
Private GitLab-E-Mail-Adressen, eine integrierte Funktion, mit der Entwickler per E-Mail Issues oder Aufgaben erstellen können, wurden laut einem Bericht von BleepingComputer vom 24. September 2026 über Forschungsergebnisse des Anwendungssicherheitsunternehmens Aikido in öffentlicher Dokumentation zahlreicher Projekte offengelegt. Die Adressen sind Teil einer GitLab-Funktion namens „Email work item to this project“ und enthalten ein langlebiges Token, das mit dem Konto des Entwicklers verknüpft ist.
Die Funktion generiert diese privaten Adressen automatisch. Jede Adresse enthält eine geheime Zeichenfolge, die wie ein Passwort wirkt. Wenn ein externer Client eine E-Mail an eine dieser Adressen sendet, analysiert GitLab die Nachricht und erstellt daraus ein Projekt-Issue oder eine Aufgabe. Aikido fand mehrere private Adressen in öffentlichen READMEs, Beitragsrichtlinien und Support-Seiten, und die Forscher warnen, dass das damit verbundene Risiko ernst ist. Ein Angreifer, der eine solche Adresse kennt, kann damit GitLab-Konten kompromittieren, indem er Code in geschützte Branches privater Repositories pusht, Quellcode stiehlt, Geheimnisse aus CI/CD-Variablen sammelt oder auf vertrauliche Issues zugreift.
Aikidos Analyse zeigt, dass jede private Adresse eine Zeichenfolge „glimt-“ enthält, die als Anmeldeinformation für den Zugriff auf das Projekt dient. Dieselbe Anmeldeinformation bleibt über alle ähnlichen Adressen hinweg bestehen, die für dieses Projekt generiert werden. Laut den Forschern führt das Ändern des Suffixes „-issue“ in der E-Mail-Adresse zu „-merge-request“ dazu, dass GitLab einen Merge Request öffnet. Grundsätzlich würde die Prüfung, ob die Absenderadresse mit der E-Mail-Adresse des Token-Inhabers übereinstimmt, eine zusätzliche Verteidigungsebene bieten, aber GitLab tut dies derzeit nicht, obwohl das Unternehmen dies nun in Erwägung zieht. Die Forscher stellen außerdem fest, dass jedes Postfach im Internet an diese Adresse senden kann und GitLab die Nachricht als der Token-Inhaber verarbeitet. Aikidos Tests zeigten, dass der Angriff auch IP-Adressbeschränkungen umgeht.
Die Zugriffsebene hängt von den Berechtigungen des Kontos ab, dem das Token gehört. Ein Angreifer könnte damit Code in geschützte Branches pushen, CI/CD-Jobs ausführen, auf private Repositories zugreifen oder Geheimnisse aus gespeicherten Variablen erlangen. CI/CD-Variablen sind Einstellungen, die von automatisierten Build-, Test- und Deployment-Pipelines verwendet werden und oft Passwörter und andere Geheimnisse enthalten. Aikido merkt an, dass ein Angreifer neben der Berechtigungsbeschränkung, die nicht umgangen werden kann, auch den Pfad und die ID des Zielprojekts benötigt. In öffentlichen Projekten sind diese Informationen öffentlich verfügbar, während in privaten Projekten die ID durch Brute-Force ermittelt werden kann, also durch wiederholtes Raten, bis die richtige gefunden ist, aber der Pfad müsste geleakt werden.
Die GitLab-Dokumentation warnt, dass diese Adressen privat sind und „nur für Sie generiert“ werden. Sie rät Benutzern, die Adresse für sich zu behalten, da jeder, der sie kennt, Issues oder Merge Requests so erstellen kann, als wäre er der Eigentümer, und das Token sofort zurückzusetzen, wenn sie vermuten, dass es geleakt wurde. An einem Nachmittag fanden Aikido-Forscher ein Dutzend aktiver GitLab-Eingangs-E-Mail-Adressen in öffentlichen READMEs, Beitragsrichtlinien und Support-Seiten. Die Forscher sagen, die Adressen wurden absichtlich in öffentliche Dokumentation aufgenommen, um Fehlerberichte von Benutzern zu sammeln. In vielen Fällen betraf die Offenlegung beliebte Open-Source-Projekte, was Lieferkettenrisiken für große Nutzerbasen schuf. Einige gehörten zu sehr beliebten Open-Source-Projekten, so Aikido. Aikido meldete das Problem im Mai 2026 über HackerOne, eine Plattform zum Melden von Sicherheitslücken, an GitLab, aber GitLab schloss es als beabsichtigtes Verhalten. Eine zweite Benachrichtigung im Juni 2026 veranlasste GitLab, seine Benutzeroberfläche zu aktualisieren, um Merge Requests zu erwähnen, falsche Aussagen über den Token-Datenzugriff zu entfernen und zu dokumentieren, dass eingehende E-Mails IP-Beschränkungen umgehen. Projektbetreuer sollten aufhören, diese Informationen freiwillig in öffentlicher Dokumentation offenzulegen, und Token für Projekte zurücksetzen, in denen sie sie in der Vergangenheit offengelegt haben.
Für Website-Betreiber und IT-Teams, die öffentlichen Code oder Dokumentation pflegen, lautet die praktische Konsequenz, jede Projekt-E-Mail-Adresse als Anmeldeinformation zu behandeln, nicht als öffentlichen Kontakt. AEU-I, der sicherheitsorientierte IT- und Infrastrukturberatungsdienst der AEU Group, kann Organisationen dabei helfen, ihren öffentlich zugänglichen Code und ihre Dokumentation auf offengelegte Projekt-Token zu überprüfen, bevor ein Angreifer sie findet. Die beste Verteidigung besteht darin, die Adressen von öffentlichen Seiten zu entfernen und alle Token zurückzusetzen, die dort bereits aufgetaucht sind.