GitLab CVE-2026-19478: kritischer Patch, CVSS 9,4

GitLab patcht normalerweise zweimal im Monat, nach Plan. Wenn ein Patch außer der Reihe kommt, ist das immer ein Signal. Und dieses Signal ist laut.

Am 17. August hat GitLab die Versionen 19.2.4, 19.1.6, 19.0.8 und 18.11.11 für Community und Enterprise Edition veröffentlicht. Grund ist CVE-2026-19478 — eingestuft als kritisch, CVSS 9,4.

GEFAHR: Fremde können deine Projekte löschen

Die Lücke steckt in der Behandlung von GraphQL-Direktiven. Unter bestimmten Bedingungen erlaubt sie es Angreifern, öffentliche Projekte und Nutzerdaten aus der Ferne zu verändern oder zu löschen.

Warum die Bewertung so hoch ausfällt, macht ein Blick auf die Angriffsvoraussetzungen klar:

Über das Netzwerk ausnutzbar — der Angreifer muss nicht im selben Netz sitzen
Keine Zugangsdaten nötig — kein Account, kein Token, kein gestohlenes Passwort
Keine Nutzerinteraktion — niemand muss auf irgendetwas klicken

Diese Kombination ist der Grund, warum 9,4 auf der Skala steht. Es gibt kein Zeitfenster, in dem du „ein bisschen“ verwundbar bist.

WER JETZT HANDELN MUSS — und wer nicht

Die Unterscheidung ist einfach:

Betroffen: alle selbst gehosteten Instanzen. Egal ob GitLab CE im Homelab-Container oder GitLab EE auf dem Firmenserver — wenn du die Instanz selbst betreibst, musst du aktiv werden. GitLab empfiehlt ausdrücklich, sofort zu aktualisieren.

Nicht betroffen: GitLab.com und GitLab Dedicated. Diese Umgebungen laufen bereits auf der gepatchten Version. Wer dort arbeitet, muss nichts tun.

SO PRÜFST DU IN 2 MINUTEN, ob du dran bist

Deine Version findest du am schnellsten im Browser unter /help auf deiner Instanz. Alternativ auf der Kommandozeile:

sudo gitlab-rake gitlab:env:info

Für Docker-Installationen:

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

Liegt deine Version unterhalb von 19.2.4, 19.1.6, 19.0.8 beziehungsweise 18.11.11, bist du in der Gefahrenzone.

EXTRA-TIPP: erst sichern, dann updaten

GitLab-Updates greifen tief in die Datenbank ein. Bevor du aktualisierst, gehört ein frisches Backup dazu — bei Omnibus-Installationen mit gitlab-backup create, dazu eine Kopie von /etc/gitlab/gitlab-secrets.json und /etc/gitlab/gitlab.rb. Ohne diese beiden Dateien lässt sich ein Backup im Ernstfall nicht sauber zurückspielen.

Und ganz wichtig: Nicht über mehrere Hauptversionen auf einmal springen. GitLab schreibt für größere Sprünge einen Upgrade-Pfad vor. Wer den überspringt, riskiert eine kaputte Migration — und die ist schmerzhafter als die Lücke.

WARUM DAS AUCH DEIN HOMELAB ANGEHT

Selbst gehostetes GitLab ist im Homelab beliebter, als viele denken: als Code-Ablage, als CI-Runner für den eigenen Kram, als Container-Registry. Genau diese Instanzen bekommen erfahrungsgemäß am seltensten Updates — weil sie „ja nur intern“ laufen.

Nur: Wenn deine Instanz per Reverse Proxy aus dem Internet erreichbar ist, ist sie eben nicht nur intern. Und automatisierte Scanner finden GitLab-Instanzen zuverlässig.

FAZIT: das ist ein Sofort-Update

Ein außerplanmäßiger Patch, CVSS 9,4, kein Login nötig, keine Interaktion nötig. Deutlicher kann eine Empfehlung nicht ausfallen. Backup ziehen, aktualisieren, fertig — und dann bitte gleich prüfen, ob deine Instanz automatische Sicherheitsupdates bekommt.

Häufige Fragen

Welche GitLab-Versionen beheben CVE-2026-19478?

Gepatcht sind 19.2.4, 19.1.6, 19.0.8 und 18.11.11, jeweils für Community und Enterprise Edition. Alles darunter in der jeweiligen Reihe gilt als verwundbar. GitLab hat die Fixes am 17. August 2026 als außerplanmäßigen Critical Patch Release veröffentlicht, also außerhalb des sonst üblichen Rhythmus von zwei Patch-Terminen pro Monat.

Wie merke ich, ob meine Instanz verwundbar ist?

Ruf auf deiner Instanz die Adresse /help auf, dort steht die laufende Version. Auf der Kommandozeile liefert sudo gitlab-rake gitlab:env:info dieselbe Information. Liegt die Version unter der jeweiligen Patch-Version deiner Reihe, ist die Instanz betroffen. Eine zuverlässige Erkennung eines bereits erfolgten Angriffs gibt es nicht — deshalb zählt Tempo.

Muss ich bei GitLab.com auch etwas tun?

Nein. GitLab.com und GitLab Dedicated laufen laut Hersteller bereits auf der gepatchten Version. Handeln müssen ausschließlich Betreiber selbst gehosteter Instanzen, also alle Self-Managed-Installationen — vom Docker-Container im Homelab bis zum Enterprise-Server im Rechenzentrum.

Was macht diese Lücke so gefährlich?

Die Kombination der Voraussetzungen. Der Angriff funktioniert über das Netzwerk, ohne dass der Angreifer Zugangsdaten besitzt, und ohne dass ein Nutzer irgendetwas anklicken muss. In der Folge lassen sich unter bestimmten Bedingungen öffentliche Projekte und Nutzerdaten verändern oder löschen. Deshalb die Einstufung mit CVSS 9,4.

Kann ich das Update aufschieben, wenn meine Instanz nur im LAN läuft?

Das Risiko sinkt, verschwindet aber nicht. Viele Homelab-Instanzen sind über einen Reverse Proxy doch erreichbar, und im internen Netz bleibt jedes kompromittierte Gerät ein möglicher Ausgangspunkt. Da der Patch keine Funktionsänderung mit sich bringt, gibt es wenig Gründe zu warten — ein Backup vorab genügt als Absicherung.

NOTFALL-PATCH! Eine 9,4er-Lücke lässt Fremde deine GitLab-Projekte löschen — updaten, sofort