Wie gefährlich ist die GitLab-Lücke CVE-2026-19478?

GitLab schließt die Lücke, die öffentliche Projekte ohne Anmeldung löscht

Michael Dobler

Autor Dr. Web

18. August 2026

3 Min. Lesezeit

GitLab hat am 17. August 2026 vier Fassungen außer der Reihe nachgeschoben. Der Anlass steckt in einer GraphQL-Direktive: Ohne Konto und ohne Anmeldung lassen sich darüber öffentliche Projekte samt Nutzerdaten verändern oder löschen. Betroffen ist ausschließlich die selbst betriebene Fassung. Genau die läuft in vielen Unternehmen im DACH-Raum.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Ein CVSS-Wert von 9,4 steht selten in einem GitLab-Advisory. Die Lücke CVE-2026-19478 erlaubt einem nicht angemeldeten Angreifer, über eine GraphQL-Direktive Code einzuschleusen und damit öffentliche Projekte samt Nutzerdaten zu verändern oder zu löschen. GitLab.com und GitLab Dedicated laufen bereits auf dem Patch, jede eigene Installation ab Version 18.2 noch nicht.

Das Wichtigste in Kürze

CVE-2026-19478 kommt auf CVSS 9,4 und erlaubt ohne Anmeldung das Verändern und Löschen öffentlicher Projekte samt Nutzerdaten.
Gepatcht sind die Fassungen 19.2.4, 19.1.6, 19.0.8 und 18.11.11, freigegeben am 17. August 2026.
Verwundbar bleibt jede selbst betriebene Community oder Enterprise Edition ab Version 18.2. GitLab.com und GitLab Dedicated hat der Anbieter bereits aktualisiert.
Eine zweite Lücke, CVE-2026-19650 mit CVSS 7,1, lässt schreibende Aufrufe per GET-Anfrage durch.

Warum braucht der Angriff kein einziges Konto?

Aktenvernichter mit der Aufschrift „Kein Passwort nötig“ und Papierreste — GitLab-Sicherheitslücke CVE-2026-19478 ermöglicht Code-Einschleusung über GraphQL-Direktive ohne Authentifizierung

GitLab führt CVE-2026-19478 mit dem Vektor AV:N/AC:L/PR:N/UI:N, also Zugriff über das Netz, geringe Komplexität, keine Rechte und keine Nutzerinteraktion.^[1] Eingeschleust wird der Code über eine GraphQL-Direktive; die Anmeldung entfällt dabei vollständig. Auf der Liste der verwundbaren Fassungen steht auch die junge Hauptversion 19.2, die GitLab erst kürzlich mit geprüften KI-Agenten gegen die Flut an KI-Code ausgestattet hat.

Aufschlussreicher als die 9,4 ist deren Zusammensetzung. Der Vektor weist der Vertraulichkeit nur geringe Auswirkung zu, der Integrität und der Verfügbarkeit dagegen hohe.^[1] Ein Angreifer sieht demnach wenig und zerstört viel. Für Betreiber verschiebt sich die Priorität damit weg vom Datenabfluss hin zu der Frage, wie schnell ein gelöschtes Repository samt Historie zurückkehrt.

Was verrät der zweite Fehler über GitLabs GraphQL-Schicht?

Im selben Paket steckt CVE-2026-19650 mit CVSS 7,1. Die Schwachstelle sitzt im Multiplex-Handler, der mehrere GraphQL-Abfragen in einer einzigen HTTP-Anfrage bündelt. Wegen mangelhafter Prüfung passieren dort Mutationen per GET, also schreibende Aufrufe über eine Methode, die als rein lesend gilt.^[1]

Auf genau dieser Annahme ruhen die üblichen Schutzmechanismen gegen Cross-Site Request Forgery. Ein präparierter Link genügt deshalb, sofern das Opfer angemeldet ist; der Vektor führt hier UI:R für Nutzerinteraktion. Gemeldet haben beide Fehler externe Forscher über GitLabs Programm bei HackerOne, hiimguardian die kritische und kreep die hohe Lücke.^[1]

Eine Lücke, die löscht statt liest, landet bei der Wiederherstellung und nicht beim Datenschutzbeauftragten. An einem GitLab-Server hängt die gesamte Historie jedes Projekts, das dort liegt.
— Markus Seyfferth, Chefredakteur Dr. Web

Die beiden Schwachstellen

CVE-2026-19478, kritisch

9,4

CVSS-Wert für den Code-Einschub über eine GraphQL-Direktive, ohne Anmeldung und ohne Nutzerinteraktion

CVE-2026-19650, hoch

7,1

CVSS-Wert für die Mutation per GET-Anfrage im Multiplex-Handler, hier muss das Opfer angemeldet sein

Fassungen mit dem Patch

19.2.4, 19.1.6, 19.0.8 und 18.11.11, freigegeben am 17. August 2026

Wer den Patch einspielen muss

Verwundbare Versionsspanne

ab 18.2

jede selbst betriebene Community oder Enterprise Edition bis hinauf zu 18.11.10, 19.0.7, 19.1.5 und 19.2.3

Nötige Rechte für den Angriff

der Vektor führt PR:N und UI:N, also kein Konto und keine Nutzerinteraktion bei der kritischen Lücke

GitLab im CISA-Katalog bekannter ausgenutzter Schwachstellen

Der Katalog listet Schwachstellen, für die Angriffe belegt sind. GitLab-Server stehen dort seit 2021, zuletzt kamen zwei ältere Einträge nach.

GitLab-Einträge insgesamt, darunter die Kontoübernahme CVE-2023-7028 und die Code-Ausführung CVE-2021-22205

Februar 2026

damals trug CISA die beiden SSRF-Lücken CVE-2021-39935 und CVE-2021-22175 nach, beide von 2021

Was sollten Betreiber im DACH-Raum jetzt tun?

Angriffe auf GitLab-Server sind kein neues Phänomen. Im Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA stehen vier GitLab-Einträge, darunter die Kontoübernahme CVE-2023-7028 und die Code-Ausführung CVE-2021-22205. Zwei ältere SSRF-Lücken kamen erst im Februar 2026 dazu, beide aus dem Jahr 2021.^[2] Wie unauffällig ein solcher Fix durchlaufen kann, zeigte im Juli ein GitLab-Patch ganz ohne CVE-Nummer.

Das Zeitfenster fällt knapp aus. Bei SAP Commerce Cloud griffen Angreifer drei Tage nach dem Patch zu, bei Fortinet genügte ein beliebiges Passwort für den Admin-Zugang. Für regulierte Einrichtungen zielt § 30 Absatz 2 BSIG auf genau diesen Fall: Nummer 3 verlangt Backup-Management und Wiederherstellung, Nummer 5 das Management von Schwachstellen bei Entwicklung und Wartung.^[3] Welche Pflichten daraus im Betrieb folgen, zeigt der Blick darauf, wie NIS2 die Produktionshalle zur Haftungsfalle macht.

Ein Upgrade auf 19.2.4, 19.1.6, 19.0.8 oder 18.11.11 schließt beide Lücken. Solange das Fenster offen steht, lohnt der Blick in die Zugriffsprotokolle des vorgelagerten Proxys auf Aufrufe gegen den Pfad /api/graphql, dazu die Probe, ob sich das jüngste Backup auf einer Ersatzinstanz tatsächlich einspielen lässt. Wie ein belastbarer Grundschutz für kleinere Betriebe aussieht, ordnen die Cybersecurity-Grundlagen für KMU ein.