GitLab-E-Mail-Tokens ermöglichen Code-Pushes und CI-Ausführung ohne Authentifizierung

Sicherheitsforscher von Aikido Security haben eine erhebliche Schwachstelle in der eingehenden E-Mail-Funktion von GitLab identifiziert, die es Angreifern ermöglicht, Code zu pushen und CI/CD-Jobs allein unter Verwendung einer geleakten E-Mail-Adresse auszuführen. Der im Jahr 2026 gemeldete Fehler betrifft sowohl GitLab.com als auch selbst verwaltete Instanzen, bei denen eingehende E-Mails aktiviert sind. Dabei wird ein statischer E-Mail-Token effektiv als hochprivilegierte Zugangsdaten behandelt, die Standard-Sicherheitskontrollen wie Zwei-Faktor-Authentifizierung und IP-Allowlists umgehen.

Was passiert ist

Der Kern des Problems liegt darin, wie GitLab die Konvertierung von E-Mails in Arbeitselemente (Work Items) handhabt. Jedes Benutzerkonto bei GitLab erhält einen eindeutigen, nicht ablaufenden Token, der in eine E-Mail-Adresse eingebettet ist, die zur Erstellung von Issues verwendet wird. Obwohl diese Adresse spezifisch für ein einzelnes Projekt erscheint, hat Aikido Security entdeckt, dass der zugrunde liegende Token über alle Projekte hinweg geteilt wird, auf die dieser Benutzer Zugriff hat. Folglich kann jeder, der diese E-Mail-Adresse erlangt, mit jedem öffentlichen oder privaten Projekt interagieren, auf das der Benutzer Zugriff hat – unabhängig davon, in welchem Projekt die Adresse ursprünglich angezeigt wurde.

Die Schwachstelle geht über die einfache Issue-Erstellung hinaus. Durch Änderung des Suffixes der E-Mail-Adresse von -issue zu -merge-request kann ein Angreifer Patches direkt an ein Repository senden. Wenn der Angreifer den Pfad und die numerische ID des Zielprojekts kennt, kann er eine E-Mail mit einem angehängten Code-Patch senden. GitLab verarbeitet diese E-Mail als Merge Request und wendet den Patch auf den angegebenen Branch an. Wenn der Benutzer die Berechtigung hat, in diesen Branch zu pushen – einschließlich geschützter Branches wie main –, wird der Code unter der Identität des Benutzers committet. Darüber hinaus führt GitLab die resultierenden CI/CD-Jobs mit den Berechtigungen des Benutzers aus, wenn der Patch die Datei .gitlab-ci.yml ändert, was potenziell Secrets offenlegt oder die Infrastruktur kompromittiert.

Wichtige Details

• Geteilter Token: Der E-Mail-Token ist für alle Projekte identisch, auf die ein Benutzer zugreifen kann. Ein Leak aus einem Projekt gefährdet daher den Zugriff auf alle anderen.
• Keine Absenderüberprüfung: GitLab überprüft die E-Mail-Adresse des Absenders nicht gegen den Kontoinhaber. Dadurch kann jede Mailbox als der Benutzer agieren.
• Umgehung von Sicherheitskontrollen: Aktionen per eingehender E-Mail sind von IP-Restriktionen und Anforderungen zur Zwei-Faktor-Authentifizierung ausgenommen, selbst wenn diese anderswo durchgesetzt werden.
• Abhängig vom Privileg: Die Auswirkung skaliert sich nach der Rolle des Benutzers; Guest-Konten haben begrenzte Auswirkungen, während Maintainer in geschützte Branches pushen und auf CI-Secrets zugreifen können.
• Zielidentifikation: Angreifer benötigen neben dem Token den Projektpfad und die numerische ID, obwohl IDs leicht erratbar und Pfade oft öffentlich sind.
• Kein Deaktivieren auf Benutzerebene: Einzelne Benutzer können die erstellung von Issues oder Merge Requests per E-Mail nicht deaktivieren; nur Instanzadministratoren können die Funktion global ausschalten.

Hintergrund

Die Funktion für eingehende E-Mails bei GitLab ist darauf ausgelegt, Workflows zu optimieren, indem sie Benutzern erlaubt, Issues oder Merge Requests über E-Mail-Clients zu erstellen. Dies ist besonders nützlich für Teams, die Triage über E-Mail-Schnittstellen verwalten oder die Hürde für externe Mitwirkende senken möchten, um Bugs zu melden. Das System basiert auf einer eindeutigen E-Mail-Adresse für jede Benutzer-Projekt-Kombination, die einen versteckten Token enthält, der die Aktion authentifiziert.

Allerdings erfordern Authentifizierungs-Tokens im Allgemeinen strenge Vertraulichkeits- und Rotationsrichtlinien. In diesem Fall ist der Token jedoch statisch und läuft nie ab. Während GitLab dies als Standard-Zugangsdaten betrachtet, entsteht durch die Integration in das E-Mail-System eine blinde Stelle. Traditionelle Sicherheitsmaßnahmen wie IP-Whitelisting, die den Zugriff auf bekannte Netzwerke beschränken, gelten nicht für eingehenden E-Mail-Traffic. Ebenso wird die Zwei-Faktor-Authentifizierung (2FA), die Logins eine zweite Verifizierungsebene hinzufügt, umgangen, da das E-Mail-System dem Token implizit vertraut, ohne den Absender herauszufordern.

Warum das wichtig ist

Für Teams, die selbst gehostete GitLab-Instanzen betreiben oder GitLab.com nutzen, hebt diese Schwachstelle eine kritische Lücke in der Supply-Chain-Sicherheit hervor. Entwickler teilen Kontaktinformationen häufig in README-Dateien, Contributing-Guides oder Support-Seiten, um die Bug-Meldung zu erleichtern. Wenn diese Dokumente die spezielle GitLab-E-Mail-Adresse enthalten, veröffentlichen sie unbeabsichtigt Zugangsdaten, die Schreibzugriff auf Code gewähren. Aikido Security fand etwa ein Dutzend solcher live veröffentlichten Adressen, darunter auch in weit verbreiteten Open-Source-Projekten.

Die Fähigkeit, IP-Restriktionen zu umgehen, ist besonders besorgniserregend für Unternehmen, die sich auf netzwerkseitige Sicherheit verlassen, um ihre Codebasen zu schützen. Ein Angreifer außerhalb des Unternehmensnetzwerks kann weiterhin bösartigen Code in den Main-Branch pushen, wenn er im Besitz des E-Mail-Tokens ist. Dies untergräbt die Annahme, dass interne Branches vor externen Bedrohungen sicher sind. Zusätzlich kann die Ausführung von CI/CD-Jobs als kompromittierter Benutzer zu weiterer lateraler Bewegung innerhalb der Infrastruktur führen, insbesondere wenn diese Jobs Zugriff auf Deployment-Keys oder Cloud-Zugangsdaten haben.

Was Sie tun können

• Token zurücksetzen: Gehen Sie auf Ihre persönliche Access-Token-Seite in GitLab und setzen Sie Ihren Token für eingehende E-Mails zurück. Dies invalidiert sofort alle bestehenden Projektadressen.
• Öffentliche Dokumentation prüfen: Durchsuchen Sie Ihre Projekt-READMEs, Contributing-Guides und Support-Seiten nach veröffentlichten GitLab-E-Mail-Adressen und entfernen Sie diese.
• Eingehende E-Mails deaktivieren: Wenn Sie Administrator einer selbst verwalteten Instanz sind, erwägen Sie, die Funktion für eingehende E-Mails global auszuschalten, falls sie für Ihren Workflow nicht essenziell ist.
• Merge Requests überwachen: Behalten Sie Merge Requests, die per E-Mail erstellt wurden, genau im Auge, insbesondere solche, die auf geschützte Branches zielen oder CI-Konfigurationsdateien ändern.
• Teammitglieder schulen: Informieren Sie Entwickler darüber, dass die in der Oberfläche angezeigte E-Mail-Adresse Zugangsdaten darstellt, die Schreibzugriff auf Code gewähren.