GitLab hat ausserplanmässige Sicherheitsupdates für die Community Edition (CE) und Enterprise Edition (EE) veröffentlicht. Die Patches beheben eine kritische Schwachstelle zur Umgehung der Zwei-Faktor-Authentifizierung (2FA) sowie mehrere Denial-of-Service-Sicherheitslücken (DoS). Betreiber selbst gehosteter GitLab-Instanzen sollten die Updates umgehend einspielen, um Kontenübernahmen und Ausfälle ihrer DevSecOps-Plattform zu verhindern.
CVE-2026-0723: Kontenübernahme trotz aktivierter Zwei-Faktor-Authentifizierung
Die als CVE-2026-0723 registrierte Schwachstelle betrifft sowohl GitLab CE als auch GitLab EE. Ursache ist eine fehlerhafte Verarbeitung von Rückgabewerten in den Authentifizierungs-Services. Kennt ein Angreifer die Konto-ID eines Zielbenutzers, kann er den Rückgabewert eines 2FA-Geräts manipulieren und so die Zwei-Faktor-Prüfung umgehen.
In der Praxis bedeutet dies: Verfügt ein Angreifer bereits über gültige Zugangsdaten (Nutzername und Passwort) – etwa durch Phishing, Credential-Stuffing oder Datenlecks –, ermöglicht CVE-2026-0723 die vollständige Übernahme des Accounts trotz aktivierter 2FA. Damit fällt die Zwei-Faktor-Authentifizierung als zentrale Schutzmassnahme praktisch weg.
Warum ein 2FA-Bypass GitLab-Umgebungen besonders hart trifft
GitLab fungiert in vielen Organisationen als Kernkomponente der DevSecOps- und Software-Supply-Chain-Infrastruktur: Quellcode-Repository, CI/CD-Pipelines, Verwaltung von Secrets, Container-Images und Build-Artefakten sind häufig direkt angebunden. Laut GitLab nutzen über 30 Millionen registrierte Anwender die Plattform, darunter mehr als 50 % der Fortune-100-Unternehmen.
Wird ein einzelnes Entwickler- oder DevOps-Konto kompromittiert, kann ein Angreifer unbemerkt Schadcode in Repositories, Pipelines oder Container-Images einschleusen. Wie prominente Supply-Chain-Vorfälle der vergangenen Jahre gezeigt haben, können derartige Manipulationen sich schnell auf Kunden, Partner und ganze Ökosysteme ausweiten. Internationale Stellen wie ENISA und NIST weisen seit Jahren darauf hin, dass SCM- und CI/CD-Plattformen zu den attraktivsten Zielen für Angreifer gehören.
Drei DoS-Angriffsvektoren gegen GitLab-Server
CVE-2025-13927 und CVE-2025-13928: Kritische DoS-Schwachstellen ohne Anmeldung ausnutzbar
Neben dem 2FA-Bypass wurden zwei weitere kritische Denial-of-Service-Schwachstellen geschlossen, die Angriffe durch nicht authentifizierte Akteure ermöglichen. Die Lücke CVE-2025-13927 erlaubt es, GitLab durch spezifisch präparierte Anfragen mit ungültigen Authentifizierungsdaten zu überlasten. Die Serverprozesse investieren unverhältnismässig viele Ressourcen in die Verarbeitung dieser Requests, was in eine Dienstunverfügbarkeit münden kann.
Die zweite kritische Schwachstelle, CVE-2025-13928, resultiert aus unzureichender Zugriffskontrolle auf API-Endpunkte. Angreifer können ohne Benutzerkonto eine Sequenz von API-Anfragen erzeugen, die einen DoS-Zustand auslöst. Für Unternehmen, deren Build- und Release-Prozesse stark von GitLab-CI/CD abhängen, bedeutet dies ein erhebliches Risiko für Entwicklungsstillstände und verzögerte Releases.
CVE-2025-13335 und CVE-2026-1102: DoS über Wiki-Inhalte und SSH-Authentifizierung
Zwei weitere Schwachstellen werden als mittelschwer eingestuft, können aber ebenfalls zu einem Denial of Service führen. CVE-2025-13335 betrifft die Verarbeitung von Wiki-Seiten. Speziell gestalteter Wiki-Content kann Prüfmechanismen für zyklische Abhängigkeiten umgehen und zu ressourcenintensiven Verarbeitungsschleifen führen. Problematisch ist, dass auch Benutzer mit eingeschränkten Rechten potenziell entsprechenden Inhalt einbringen können.
CVE-2026-1102 liegt in der SSH-Authentifizierung begründet. Durch wiederholtes Senden fehlerhafter SSH-Loginversuche lässt sich der GitLab-Server so stark belasten, dass neben der Anwendung selbst auch die zugrunde liegende Netzwerk-Infrastruktur beeinträchtigt wird. Angriffe auf SSH-Dienste sind laut zahlreichen Incident-Reports von CERTs und Shadowserver ohnehin ein häufig beobachtetes Muster.
Betroffene GitLab-Versionen, Patches und Umfang der Exposition
Zur Behebung aller beschriebenen Sicherheitslücken hat GitLab die Versionen 18.8.2, 18.7.2 und 18.6.4 für CE und EE veröffentlicht. Betreiber selbst gehosteter Instanzen sollten ihre aktuelle Version prüfen, ein Backup anlegen und zeitnah auf eine dieser Versionen aktualisieren.
Die gehostete Plattform GitLab.com wurde nach Angaben des Herstellers bereits aktualisiert; Kunden von GitLab Dedicated erhalten die Patches im Rahmen des Managed Service automatisch.
Die Angriffsfläche ist erheblich: Der Sicherheitsdienst Shadowserver meldet derzeit rund 6000 öffentlich erreichbare GitLab-CE-Instanzen, während der Suchdienst Shodan mehr als 45 000 mit GitLab in Verbindung stehende Systeme identifiziert. Ungepatchte Systeme in diesem Bestand sind potenziell direkt angreifbar.
Empfehlungen: So sichern Unternehmen ihre GitLab-Umgebung ab
1. Sofortige Aktualisierung einplanen. Admins sollten umgehend ein kurzes Wartungsfenster ansetzen, ein vollständiges Backup erstellen und auf GitLab 18.8.2, 18.7.2 oder 18.6.4 aktualisieren – je nach verwendeter Release-Linie.
2. Externen Zugriff minimieren. GitLab sollte, wo immer möglich, nur über VPN, Reverse-Proxy, WAF oder restriktive IP-Allowlists erreichbar sein. Dies gilt insbesondere für Admin-Oberflächen und SSH-Zugänge, um DoS- und Brute-Force-Angriffe zu erschweren.
3. Authentifizierung weiter verhärten. Trotz des jetzt geschlossenen 2FA-Bypasses bleibt Zwei-Faktor-Authentifizierung eine essenzielle Schutzmassnahme. Ergänzend sollten Unternehmen SSO mit einem zentralen Identity Provider, starke Passwort-Richtlinien und die Überwachung auffälliger Login-Muster etablieren.
4. Monitoring und Alarmierung ausbauen. Ein zentrales Logging für GitLab, SSH-Server und Web-Frontend ist entscheidend. Auffällige Peaks bei Anfragen, Authentifizierungsfehlern oder Ressourcenverbrauch sollten automatisierte Alerts auslösen, um DoS- und Angriffskampagnen frühzeitig zu erkennen.
5. Vulnerability Management fest verankern. Sicherheitsbulletins von GitLab und einschlägigen CERTs sollten in den regulären Patch- und Change-Management-Prozess integriert werden. Kritische CVEs wie CVE-2026-0723 erfordern priorisierte Behandlung und klare interne SLAs für die Einspielung von Sicherheitsupdates.
Die aktuellen GitLab-Schwachstellen verdeutlichen, dass DevSecOps-Plattformen selbst zu hochwertigen Zielen für Angreifer geworden sind. Wer GitLab als zentrale Entwicklungs- und CI/CD-Infrastruktur nutzt, sollte jetzt die eigene Versionslage prüfen, Updates einspielen und grundlegende Sicherheitsmechanismen wie Segmentierung, starke Authentifizierung und kontinuierliches Monitoring konsequent umsetzen. Auf diese Weise lassen sich sowohl das Risiko einer Kontenkompromittierung als auch die Wahrscheinlichkeit schwerwiegender Ausfälle in der Softwarelieferkette signifikant reduzieren.
