CVE-2026-19478: Kritische GitLab-Lücke — ohne Anmeldung Projekte löschen

GitLab hat am 17. August 2026 ein außerplanmäßiges Patch-Release veröffentlicht — nicht zum regulären Termin, sondern weil eine der beiden geschlossenen Lücken kritisch ist. CVE-2026-19478 erlaubt es unter bestimmten Bedingungen einem unangemeldeten Angreifer, öffentliche Projekte und Nutzerdaten aus der Ferne zu verändern oder zu löschen.

Wenn Sie GitLab selbst betreiben, ist das der Artikel, den Sie heute lesen sollten. Wenn Sie GitLab.com nutzen, sind Sie bereits abgesichert — dazu gleich mehr.

Die Kurzfassung

Merkmal	Angabe
Betroffen	GitLab CE und EE ab 18.2, alle Versionen vor 18.11.11 · 19.0 vor 19.0.8 · 19.1 vor 19.1.6 · 19.2 vor 19.2.4
Behoben in	18.11.11, 19.0.8, 19.1.6, 19.2.4
Nicht betroffen	Versionen älter als 18.2 sowie GitLab.com und GitLab Dedicated
Bewertung	CVSS 9.4 (kritisch), CWE-94 Code Injection
Angriffsvoraussetzung	Netzwerkzugang — keine Anmeldung, kein Zutun eines Nutzers
Bekannte Angriffe	Bisher keine (Stand 18.08.2026)

Im selben Release steckt eine zweite Lücke: CVE-2026-19650 (CVSS 7.1, hoch), ein Cross-Site-Request-Forgery-Problem im GraphQL-Multiplex-Handler. Sie betrifft dieselben Versionen und wird mit demselben Update geschlossen — Sie müssen also nichts zusätzlich tun, sollten sie aber kennen, falls jemand nach der zweiten Nummer fragt.

Was genau ist passiert?

GitLab beantwortet einen Großteil seiner Anfragen über GraphQL — eine Abfragesprache, bei der der Client nicht eine feste Adresse aufruft, sondern eine Abfrage formuliert und der Server sie ausführt. Zu GraphQL gehören sogenannte Direktiven: kleine Anweisungen innerhalb einer Abfrage, die steuern, wie der Server sie abarbeitet.

Genau dort lag der Fehler. Über eine präparierte Direktive ließ sich Code einschleusen, den der Server anschließend ausgeführt hat — die Einstufung CWE-94, Code Injection, benennt das. Vereinfacht gesagt: Der Server hat eine Eingabe nicht als Daten behandelt, sondern als Anweisung.

Mehr Details gibt es derzeit nicht, und das ist Absicht. Der zugrunde liegende HackerOne-Bericht ist gesperrt, und GitLab öffnet die technischen Tickets zu Sicherheitslücken grundsätzlich erst 90 Tage nach dem Patch. Gefunden hat die Lücke ein Forscher unter dem Namen hiimguardian über das Bug-Bounty-Programm von GitLab.

Was der CVSS-Vektor verrät

Ein Blick auf die Einzelwerte lohnt sich, weil er zeigt, welche Art von Schaden hier droht:

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

PR:N und UI:N — keine Rechte nötig, kein Klick eines Nutzers nötig. Der Angriff läuft vollständig ohne Mitwirkung von innen.
AC:L — geringe Komplexität. Keine besonderen Umstände, kein Glück, kein Timing.
C:L — die Vertraulichkeit ist nur gering betroffen. Es geht hier also nicht in erster Linie um Datendiebstahl.
I:H und A:H — Integrität und Verfügbarkeit sind hoch betroffen.

Das ist ein ungewöhnliches Profil. Die meisten kritischen Lücken sind Diebstahl-Lücken. Diese hier ist eine Zerstörungs-Lücke: Der Angreifer liest wenig, aber er kann verändern und löschen. Für ein GitLab heißt das im schlimmsten Fall: Repositories, Tickets, Merge Requests und Nutzerkonten — weg.

Und noch ein Wert aus der Bewertung der US-Behörde CISA ist erwähnenswert: Automatable: yes. Angriffe dieser Art lassen sich maschinell über viele Instanzen hinweg fahren. Bekannte Ausnutzung gibt es bisher nicht, aber die Voraussetzungen dafür sind günstig — und öffentlich erreichbare GitLab-Instanzen lassen sich leicht finden.

Betrifft mich das überhaupt?

Die entscheidende Frage lautet: Betreiben Sie GitLab selbst?

Nein, wir nutzen GitLab.com. Dann sind Sie fein raus. GitLab.com und GitLab Dedicated liefen laut Hersteller bereits vor der Veröffentlichung auf der abgesicherten Version. Sie müssen nichts tun.

Ja, wir haben eine eigene Instanz. Dann handeln Sie heute. Das gilt für alle Betriebsarten gleichermaßen — Omnibus-Paket, Docker, Helm-Chart oder Installation aus dem Quellcode.

Und es gilt ausdrücklich auch dann, wenn Ihre Instanz nur im Firmennetz erreichbar ist. Der Angriff braucht keine Anmeldedaten — er braucht nur Netzwerkzugang. Ein infizierter Arbeitsplatzrechner oder ein Gerät im Gäste-WLAN genügt unter Umständen bereits.

Version herausfinden

Am schnellsten im Browser: Rufen Sie /help auf Ihrer Instanz auf — die Version steht oben. Auf dem Server geht es direkt:

sudo gitlab-rake gitlab:env:info

Bei einer Installation in Docker entsprechend im Container:

docker exec -it gitlab gitlab-rake gitlab:env:info

Was jetzt zu tun ist

1. Aktualisieren

Für Omnibus-Installationen unter Debian oder Ubuntu:

sudo apt update && sudo apt install gitlab-ee

Bei der Community Edition heißt das Paket gitlab-ce. Unter RHEL, Alma oder Rocky nehmen Sie dnf install statt apt install.

GitLab weist ausdrücklich darauf hin, dass diese Patches keine neuen Datenbank-Migrationen enthalten und bei Mehrknoten-Installationen keine Ausfallzeit nötig ist. Das Omnibus-Paket hält den Dienst beim Update trotzdem kurz an — das ist normal.

2. Achtung beim Versionssprung

Ein Punkt, der in der Eile gern übersehen wird: Wenn Ihre Instanz noch auf 18.2 oder 18.5 läuft, können Sie nicht einfach auf 19.2.4 springen. GitLab schreibt für größere Sprünge Zwischenversionen vor, die zwingend eingehalten werden müssen — sonst bleiben Migrationen unvollständig und die Instanz startet im schlimmsten Fall nicht mehr.

Das nächstgelegene Ziel für den 18er-Zweig ist 18.11.11. Für den konkreten Pfad hat GitLab ein Upgrade-Path-Werkzeug, das Ihnen die nötigen Stationen ausgibt. Und vor jedem größeren Sprung gilt ohnehin: erst sichern.

sudo gitlab-backup create

Vergessen Sie dabei die Konfiguration nicht — /etc/gitlab/gitlab.rb und /etc/gitlab/gitlab-secrets.json liegen nicht im Backup und sind ohne einander wertlos.

3. Wenn Sie nicht sofort aktualisieren können

Einen Workaround nennt GitLab nicht — es gibt keine Einstellung, die das Problem entschärft. Bleibt nur, die Angriffsfläche zu verkleinern: Nehmen Sie die Instanz vom offenen Internet, bis das Update läuft. VPN, IP-Filter im vorgelagerten Webserver oder schlicht die Firewall. Da der Angriff ohne Anmeldung funktioniert, ist die Erreichbarkeit die einzige verbliebene Hürde.

4. Nachsehen, ob etwas passiert ist

Da die Lücke seit 18.2 besteht, war das Zeitfenster lang. Ein Update allein beantwortet die Frage nicht, ob Ihre Instanz in dieser Zeit angefasst wurde. Diese Protokolle sind der richtige Anlaufpunkt:

/var/log/gitlab/gitlab-rails/graphql_json.log — hier landen die GraphQL-Abfragen. Auffällig sind Abfragen ohne angemeldeten Nutzer, die dennoch schreibende Wirkung hatten.
/var/log/gitlab/gitlab-rails/audit_json.log — Änderungen an Projekt- und Gruppeneinstellungen sowie an Mitgliedschaften.
/var/log/gitlab/gitlab-rails/application_json.log — angelegte Nutzer und ähnliche Ereignisse.
/var/log/gitlab/gitlab-rails/production_json.log — die Anfragen an die Anwendung insgesamt.

Suchen Sie außerdem im Blinden nach dem Offensichtlichen: fehlende oder umbenannte Projekte, neue Konten mit Administratorrechten, geänderte Sichtbarkeiten, frische Deploy-Keys, Personal Access Tokens und Runner-Registrierungen, die niemand angelegt hat.

Was wir daraus mitnehmen

GraphQL ist eine eigene Angriffsfläche. Zwei Lücken in einem Release, beide im GraphQL-Bereich, eine davon kritisch — das ist kein Zufall. Wo der Client die Abfrage formuliert und der Server sie ausführt, ist die Grenze zwischen Daten und Anweisung besonders schmal. Für Sie als Betreiber heißt das nicht, GraphQL zu meiden, sondern: Solche Komponenten verdienen bei Updates Vorrang.

„Nur intern erreichbar” ist keine Absicherung. Es ist eine Verzögerung. Bei einer Lücke, die ohne Anmeldung auskommt, entscheidet allein, wer das Netz erreicht.

Ein Backup, das Sie nie zurückgespielt haben, ist eine Vermutung. Diese Lücke zielt auf Löschen und Verändern — genau den Fall, für den Sicherungen existieren. Der beste Zeitpunkt, eine Wiederherstellung einmal zu proben, ist der Tag, an dem sie noch niemand braucht.

Eigene GitLab-Instanz und keine Zeit für den Umstieg?

Wir prüfen Ihre Version, planen den Upgrade-Pfad mit den nötigen Zwischenstationen, sichern vorher ab und sehen die Protokolle auf Spuren durch. Für Kunden mit Wartungsvertrag ist das bereits angestoßen.

Schreiben Sie uns — bei einer Lücke ohne Anmeldung zählt der Tag, nicht die Woche.

Quellen: GitLab Critical Patch Release vom 17.08.2026 (Versionen 19.2.4, 19.1.6, 19.0.8, 18.11.11) sowie der CVE-Eintrag CVE-2026-19478. Die Einstufung „Automatable: yes” stammt aus der SSVC-Bewertung der CISA vom 17.08.2026.