GitLab schließt kritische Code-Injection-Lücke CVE-2026-19478

Was ist passiert?

GitLab hat am 17. August 2026 Patches für zwei Sicherheitslücken veröffentlicht, wie SecurityWeek und The Hacker News berichten. Die schwerwiegendere der beiden, CVE-2026-19478, ist eine kritische Code-Injection-Schwachstelle mit einem CVSS-Score von 9,4. Sie erlaubt es einem Angreifer ohne jede Authentifizierung, über eine manipulierte GraphQL-Direktive Nutzerdaten und öffentliche Projekte zu verändern oder zu löschen.

Die zweite Lücke, CVE-2026-19650 (CVSS 7.1), betrifft eine Cross-Site-Request-Forgery-Schwachstelle (CSRF) im GraphQL-Multiplex-Query-Handler. Laut GitLabs eigenem Advisory konnte ein nicht authentifizierter Angreifer dabei unter bestimmten Bedingungen Mutationen über GET-Requests ausführen, weil die Validierung der Anfragen unzureichend war.

Betroffene Versionen

Beide Lücken betreffen GitLab Community Edition (CE) und Enterprise Edition (EE) ab den Versionslinien 18.2, 19.0, 19.1 und 19.2. GitLab.com und GitLab Dedicated wurden bereits automatisch gepatcht, hier ist kein Handeln der Nutzer nötig. Anders sieht es bei selbst gehosteten (Self-Managed) Installationen aus – hier müssen Administratoren manuell aktualisieren.

Warum das für KMU relevant ist

GitLab wird längst nicht mehr nur von großen Tech-Konzernen eingesetzt. Auch viele mittelständische IT-Abteilungen und Softwareentwickler betreiben eigene, selbst gehostete GitLab-Instanzen – sei es für interne Entwicklungsprojekte, für die Versionsverwaltung von Kundenprojekten oder als zentrale CI/CD-Plattform. Wer eine solche Self-Managed-Instanz betreibt, sollte die Schwere der Lücke nicht unterschätzen: Ein CVSS-Wert von 9,4 bei fehlender Authentifizierungspflicht bedeutet, dass praktisch jeder mit Netzwerkzugriff auf die GitLab-Instanz Daten manipulieren oder löschen könnte, ohne sich vorher anzumelden.

Besonders kritisch ist das für Unternehmen, die öffentliche Projekte oder öffentlich erreichbare GitLab-Instanzen betreiben, etwa für Open-Source-Beiträge oder externe Zusammenarbeit. Aber auch rein intern genutzte Instanzen sind gefährdet, sobald ein Angreifer bereits im internen Netzwerk Fuß gefasst hat – ein Szenario, das bei Ransomware-Angriffen regelmäßig vorkommt.

Was Admins jetzt tun sollten

GitLab selbst empfiehlt ausdrücklich, alle Self-Managed-Installationen umgehend zu aktualisieren. Die folgenden Schritte helfen bei der praktischen Umsetzung:

1. Aktuell laufende GitLab-Version über Admin Area > Overview > System Info oder per sudo gitlab-rake gitlab:env:info prüfen
2. Zielversion aus der Tabelle oben je nach eigener Versionslinie bestimmen (18.11.11, 19.0.8, 19.1.6 oder 19.2.4)
3. Vor dem Update ein vollständiges Backup erstellen: sudo gitlab-backup create
4. Bei Omnibus-Installationen das Paket-Repository aktualisieren und das Update einspielen: sudo apt update && sudo apt install gitlab-ee beziehungsweise gitlab-ce
5. Bei Docker-basierten Installationen das aktuelle Image ziehen und den Container neu starten
6. Nach dem Update die GitLab-Statusseite und die Anwendungslogs auf Fehler prüfen
7. Zugriffslogs der letzten Tage stichprobenartig auf ungewöhnliche GraphQL-Anfragen sichten, falls ein Kompromittierungsverdacht besteht
8. Kein Exploit in freier Wildbahn laut GitLab bekannt, Handlungsdruck besteht dennoch wegen der niedrigen Angriffshürde
9. Beide Lücken wurden über das GitLab-Bug-Bounty-Programm auf HackerOne gemeldet
10. Automatisierte Update-Benachrichtigungen im Admin-Bereich aktivieren, um künftige Patches schneller zu erfassen
11. Zugriff auf die GitLab-Instanz nach Möglichkeit auf VPN oder internes Netz beschränken, wenn kein öffentlicher Zugriff nötig ist

Einordnung im größeren Kontext

GitLab veröffentlicht praktisch monatlich Sicherheitsupdates, kritische Lücken mit einem CVSS-Wert über 9,0 sind aber vergleichsweise selten. Für Unternehmen, die GitLab als zentrale Plattform für Quellcode und Deployment-Pipelines nutzen, ist ein zeitnahes Patchen daher keine Kür, sondern Pflicht – ein kompromittiertes Repository kann im schlimmsten Fall auch zur Einschleusung von Schadcode in die eigene Software-Lieferkette führen.

Passende Anleitungen auf S-EDV

1. Docker Engine gegen Copy Fail absichern: Update und Container-Check
2. Microsoft Patchday Juni 2026: CVE-2026-45648 – Kritische RCE-Lücke in Active Directory Domain Services

Quellen

1. SecurityWeek: GitLab Patches Critical Code Injection Vulnerability
2. The Hacker News: Critical GitLab GraphQL Flaw Could Let Unauthenticated Attackers Delete Public Projects
3. GitLab: Critical Patch Release 19.2.4, 19.1.6, 19.0.8, 18.11.11