GitLab behebt kritische GraphQL-Sicherheitslücke, über die sich Projekte ändern oder löschen lassen

Kritische Schwachstelle in Self-Managed-Instanzen

GitLab hat am 17. August 2026 ein außerplanmäßiges Sicherheitsupdate veröffentlicht – fünf Tage nach dem vorherigen regulären Release. Das Paket behebt zwei Schwachstellen in den Editionen Community Edition (CE) und Enterprise Edition (EE), die unterschiedlich schwerwiegend sind, aber beide mit der Nutzung von GraphQL zusammenhängen.

Die schwerwiegendste ist CVE-2026-19478, die GitLab als Critical einstuft und mit CVSS 9.4 bewertet. Unter bestimmten Bedingungen könnte ein nicht authentifizierter Remote-Angreifer über eine GraphQL-Direktive öffentliche Projekte und Benutzerdaten ändern oder löschen.

Das Unternehmen hat weder mitgeteilt, welche Direktive betroffen ist, noch welche Bedingungen für einen erfolgreichen Angriff erfüllt sein müssen. Der CVSS-Vektor weist jedoch auf einen über das Netzwerk ausführbaren Angriff ohne Zugangsdaten und ohne Interaktion des Opfers hin:

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

Die Bewertung spiegelt vor allem die Auswirkungen auf Integrität und Verfügbarkeit der Daten wider. Die Vertraulichkeitsauswirkungen werden dagegen als geringer eingestuft.

Bis zum 18. August 2026 hatte GitLab keine Ausnutzung der Schwachstelle gemeldet. Zudem war auf GitHub kein öffentlicher Exploit-Code zu CVE-2026-19478 verfügbar. Ob die Lücke in den KEV-Katalog (Known Exploited Vulnerabilities) der CISA aufgenommen wurde, ist nicht bekannt.

Das zweite Problem betrifft GraphQL-Mutations über GET

Die zweite Schwachstelle ist CVE-2026-19650, die als High eingestuft und mit CVSS 7.1 bewertet wird:

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

Die Schwachstelle besteht in einer Cross-Site-Request-Forgery-(CSRF)-Schwäche im Handler für Multiplex-GraphQL-Abfragen. Unter bestimmten Bedingungen hätte eine unzureichende Validierung der Anfragen es einem nicht authentifizierten Benutzer ermöglichen können, Änderungsoperationen – sogenannte Mutations – über HTTP-GET-Anfragen auszuführen.

Im Gegensatz zur kritischen Lücke erfordert dieses Szenario eine Interaktion des Benutzers. Das Opfer müsste daher eine Aktion ausführen, durch die die vom Angreifer vorbereitete Anfrage von der GitLab-Instanz verarbeitet wird.

Das Problem entspricht nicht automatisch einem vollständigen Serverzugriff. Das Risiko betrifft jedoch die unbefugte Ausführung von Operationen, die Daten verändern können, mit möglichen Folgen für Projekte, Konfigurationen und von der Plattform verwaltete Ressourcen. GitLab hat nicht genügend Details veröffentlicht, um den Angriffsablauf genau nachzuvollziehen.

Betroffene und korrigierte Versionen

Die Korrekturen wurden in folgenden Versionen veröffentlicht:

• 19.2.4
• 19.1.6
• 19.0.8
• 18.11.11

Betroffen sind:

• alle 18.2-Versionen vor 18.11.11;
• 19.0-Versionen vor 19.0.8;
• 19.1-Versionen vor 19.1.6;
• 19.2-Versionen vor 19.2.4.

Betreiber der Zweige 18.2 bis 18.10 erhalten keine erweiterte Korrektur für diese Zweige und sollten ein Upgrade auf eine unterstützte und korrigierte Version planen. Die genau installierte Version lässt sich über die Administrationsseite der Instanz oder mithilfe der Verwaltungstools des verwendeten Pakets überprüfen.

Die Korrektur betrifft ausschließlich Self-Managed-Installationen. GitLab.com und GitLab Dedicated verwenden bereits korrigierte Versionen; Kunden dieser Dienste müssen keine manuellen Updates durchführen.

Das Update führt keine neuen Migrationen ein und sollte in Multi-Node-Installationen keine Ausfallzeit erfordern. Die üblichen betrieblichen Prüfungen bleiben dennoch erforderlich, insbesondere in Umgebungen mit verteilten Nodes, Proxys oder GraphQL-Komponenten, die über individuell konfigurierte Infrastrukturen erreichbar sind.

Was Administratoren tun sollten

Als Gegenmaßnahme empfiehlt GitLab das Update auf eine der vier korrigierten Versionen. Gleichwertige Alternativen – etwa die vorübergehende Deaktivierung einer bestimmten GraphQL-Direktive oder eine WAF-Regel, die beide Probleme zuverlässig blockiert – wurden nicht genannt.

Administratoren sollten daher:

1. die Version der Self-Managed-Instanz überprüfen;
2. auf 19.2.4, 19.1.6, 19.0.8 oder 18.11.11 aktualisieren;
3. Anwendungs- und Zugriffsprotokolle auf ungewöhnliche GraphQL-Anfragen prüfen;
4. unerwartete Änderungen an öffentlichen Projekten, Repositories, Issues, Konfigurationen und Benutzerdaten untersuchen;
5. ungewöhnliche GET-Anfragen im Zusammenhang mit GraphQL-Operationen prüfen, die Änderungen bewirken.

Das Briefing nennt keine spezifischen Indicators of Compromise, Kampagnennamen oder bereits beobachteten Netzwerk-Muster. Die Protokolle ermöglichen daher nicht zwangsläufig die Unterscheidung zwischen einem erfolgreichen Angriff und legitimer Aktivität, ohne URLs, Identitäten, Zeitpunkte und vorgenommenen Änderungen miteinander zu korrelieren.

Organisationen, die nicht sofort aktualisieren können, sollten die externe Angriffsfläche ihrer Instanz entsprechend den betrieblichen Anforderungen reduzieren. Diese Maßnahme ersetzt jedoch nicht den Patch und bietet keinen garantierten Schutz, wenn die Instanz aus nicht vertrauenswürdigen Netzen erreichbar bleiben muss.

Technische Veröffentlichung in den kommenden Monaten erwartet

GitLab hat angekündigt, die Details zu den Schwachstellen 90 Tage nach Veröffentlichung der Korrektur im eigenen Issue-Tracker offenzulegen. Für diese beiden Probleme wird die technische Veröffentlichung daher etwa Mitte November 2026 erwartet.

Der Zeitplan steht nicht vollständig im Einklang mit einer früheren Mitteilung vom 10. Juni 2026, in der ein Zeitraum von 30 Tagen genannt wurde. Bis zur Veröffentlichung der Details bleiben die betroffene GraphQL-Direktive der kritischen Lücke, die vollständigen Voraussetzungen für eine Ausnutzung sowie die Methoden zum Umgehen der Validierung von GET-Anfragen unbekannt.

Der Vorfall folgt auf einen Bericht vom Juli 2026 über eine andere GitLab-Schwachstelle. Damals hatten Sicherheitsforscher funktionierenden Exploit-Code für Self-Managed-Server veröffentlicht. Das Unternehmen reagierte nicht umgehend auf eine Bitte um Stellungnahme zu diesem neuen Update.

Für Administratoren bleibt die Priorität unverändert: Instanzen in den betroffenen Versionsbereichen identifizieren und schnellstmöglich auf eine korrigierte Version aktualisieren, ohne die spätere Veröffentlichung der technischen Details abzuwarten.