GitLabs AI Gateway ermöglichte es einer gezielt erstellten Flow-Konfiguration, aus ihrer Prompt-Sandbox auszubrechen.

Am 2. Oktober 2026 veröffentlichte GitLab eine kritische Patch-Version für sein AI Gateway – die Middleware, die Anfragen zwischen einer GitLab-Instanz und den Sprachmodellen, die seine Duo-Funktionen aufrufen, überträgt – und nannte CVE-2026-90970 und bewertete die Schwachstelle mit 9,9 von 10. Der Fehler hätte – nach GitLabs eigenen Worten – „einem authentifizierten Benutzer mit Zugriff auf die Duo Agent Platform ermöglichen können, über eine speziell gestaltete Flow-Konfiguration die Prompt-Template-Sandbox zu verlassen, was zur Ausführung beliebiger Befehle auf dem AI Gateway führen konnte“. Nur Organisationen, die ein selbst gehostetes AI Gateway betreiben, mussten handeln: GitLab hatte die Gateways, die es für GitLab.com, GitLab Dedicated und selbst verwaltete Kunden betreibt, die ein von GitLab gehostetes Gateway nutzen, bereits behoben und dies in der Sicherheitsmitteilung mitgeteilt. GitLabs Mitteilung besagt nicht, dass der Fehler jemals ausgenutzt wurde, und die von der US-amerikanischen Cybersecurity and Infrastructure Security Agency am selben Tag dem CVE-Eintrag beigefügte Bewertung führt die Ausnutzung als „none“ auf. Die Entdeckung wurde dem HackerOne-Forscher zugeschrieben, der als invisiblemeerkat bekannt ist. GitLabs Sicherheitsmitteilung, der NVD-Eintrag und die darauf folgende Berichterstattung stimmen darin überein, worin der Fehler bestand und welche Versionen ihn enthielten; sie stimmen ebenso darin überein, was nicht bekannt ist, nämlich ob ihn jemals jemand genutzt hat. Dieser Eintrag steht neben den anderen dokumentierten Schwachstellen der Agenteninfrastruktur in dem AI-Vorfallarchiv, wo jeder Eintrag seine eigenen Quellen, seinen Schweregrad, seine Konfidenzstufe und seine Kennzeichnung als umstritten trägt.

Was der Hinweis tatsächlich sagt – und was er auslässt

Der Sicherheitshinweis ist kurz. Veröffentlicht auf GitLabs Dokumentationsseite unter dem Titel „GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2 und 19.4.1“, listet er eine Sicherheitskorrektur auf, überschrieben mit „Improper Neutralization issue in custom flow prompt template impacts AI Gateway“ und als Kritisch eingestuft. Er gibt den CVSS-3.1-Vektor als AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H an — über das Netzwerk erreichbar, geringe Angriffskomplexität, geringe erforderliche Berechtigungen, keine Benutzerinteraktion, geänderter Scope und hohe Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Dieser Vektor ist lesenswert, weil er präzise zum Angreifer ist: geringe Berechtigungen, aber eben doch Berechtigungen. Der Sicherheitshinweis sagt „ein authentifizierter Benutzer mit Zugriff auf die Duo Agent Platform“ und hört dort auf. Er nennt weder die Rolle noch die Berechtigung noch die Bedingungen, auf die sich seine eigene Formulierung „unter bestimmten Bedingungen“ bezieht.

Es veröffentlicht keinen Proof of Concept, beschreibt nicht die speziell gestaltete Flow-Konfiguration und bietet keine Problemumgehung für Gateways, die nicht sofort aktualisiert werden können. The Hacker News stellt in ihrem Bericht vom 2. Oktober dieselben Lücken fest und ergänzt eine, die operativ relevant ist: Die Sicherheitsempfehlung bietet keine Möglichkeit zu prüfen, ob ein Gateway angegriffen wurde, bevor es gepatcht wurde. Security Affairs vermerkt am darauffolgenden Tag dieselben Lücken.

Der dem CVE zugeordnete Eintrag der Common Weakness EnumerationCWE-1336, die unsachgemäße Neutralisierung spezieller Elemente, die in einer Template-Engine verwendet werden. Der Sicherheitshinweis von GitLab verwendet das Wort Jinja nie. Die Repository-Dokumentation des AI Gateway selbst hingegen schon: Ihr Prompt-Registry-Dokument beschreibt Prompt-Konfigurationsdateien, die „Jinja-Ausdrücke für mehrere Rollen wie Benutzer und System unterstützen“, und beschreibt eine Prompt-Klasse, die „Jinja verwendet, um die Prompt-Vorlagen mit den Eingabeargumenten zu interpolieren“. Die vom CVE beschriebene Lücke ist genau die, für die diese Klasse von Engines bekannt ist – vom Benutzer bereitgestellter Text, der eine Vorlage erreicht, die ausgewertet statt ausgegeben wird.

Warum ein Befehl auf diesem speziellen Host 9,9 wert ist

Das AI Gateway ist kein Sidecar. Laut der Self-Hosted-Dokumentation von GitLab empfängt es Anfragen von GitLab, stellt die Prompts zusammen und kommuniziert mit dem Modell-Backend – einem vLLM-Server, Amazon Bedrock, Azure OpenAI oder einem externen Anbieter – und in einer vollständig selbstgehosteten Bereitstellung ist es die Komponente, die Prompts und Antworten im eigenen Netzwerk der Organisation hält. Die Installationsanleitung für das AI Gateway von GitLab weist Administratorinnen und Administratoren außerdem an, ein Signaturschlüsselpaar zu erzeugen und die beiden Hälften als Umgebungsvariablen an den Dienst zu übergeben, und zwar als AIGW_SELF_SIGNED_JWT__SIGNING_KEY und AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (mit entsprechenden Äquivalenten für Duo Workflow). Security Affairs macht die Konsequenz explizit: Befehlsausführung auf dem Gateway bringt einen Angreifer auf einen Host, der JWT-Signaturmaterial enthält und auf dem Pfad zwischen der GitLab-Instanz und der Modellinfrastruktur liegt.

Das ist der Unterschied zwischen einem Sandbox-Ausbruch in einer Spielerei und einem in der Produktion. Der Ausbruch muss kein Modell erreichen; er muss den Prozess erreichen, der die Schlüssel hält, mit denen die Modellaufrufe signiert werden.

GitLabs Produktdokumentation gibt – getrennt vom Advisory – an, dass das Erstellen oder Bearbeiten eines benutzerdefinierten Flows die Rolle „Maintainer“ oder „Owner“ im verwaltenden Projekt erfordert und dass das Ausführen eines solchen Flows mindestens die Rolle „Developer“ voraussetzt. Das Advisory bestätigt diese Zuordnung nicht, und The Hacker News merkt an, dass keine Rolle über „Duo Agent Platform access“ hinaus genannt wird. Wer sein eigenes Risiko einschätzt, sollte die Dokumentation als Berechtigungsmodell des Produkts und das Schweigen des Advisories genau als das behandeln: Schweigen, nicht als Widerspruch.

Etabliert und nicht etabliert

Die eigenen Felder des Datensatzes stimmen mit allem oben Gesagten überein und fügen nichts hinzu, was nicht im Hinweis steht. Was folgt, ist die Aufteilung, die ein Leser aus einer einzeiligen Zusammenfassung nicht entnehmen kann.

• Festgestellt: eine Schwachstelle mit kritischer Schwere in GitLab AI Gateway, offengelegt am 2. Oktober 2026, CVSS 9.9, CWE-1336, erreichbar durch einen authentifizierten Benutzer der Duo Agent Platform über eine manipulierte Flow-Konfiguration, was zur Befehlsausführung auf dem Gateway-Host führt.

• Festgestellt: der betroffene Bereich – alle AI Gateway-Versionen von 18.1.6 bis vor 19.2.4, 19.3 bis vor 19.3.2 und 19.4 bis vor 19.4.1 – sowie die korrigierten Versionen 19.2.4, 19.3.2 und 19.4.1.

• Bestätigt: Von GitLab gehostete Gateways wurden vor der Veröffentlichung gepatcht, und ihre Kunden müssen nichts unternehmen; Betreiber von Self-Hosted-Instanzen wurden direkt vor dem Release-Beitrag kontaktiert, was GitLab im Advisory selbst angibt.

• Festgestellt: die Nennung von invisiblemeerkat als Melder und das Fehlen jeglicher Aussage über eine Ausnutzung in freier Wildbahn.

• Nicht geklärt: ob jemand sie ausgenutzt hat. Eine CISA-SSVC-Bewertung vom 2. Oktober 2026, die im NVD-Datensatz sichtbar ist, gibt Ausnutzung als „none“, Automatisierbarkeit als „no“ und technische Auswirkung als „total“ an; der CISA-Katalog „Known Exploited Vulnerabilities“ führte CVE-2026-90970 in seiner Revision vom 20. Oktober 2026 nicht auf, was ich direkt überprüft habe. Das EPSS-Modell von FIRST bezifferte die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen am 21. Oktober 2026 auf 0,94 Prozent — niedrig und nicht null.

• Nicht geklärt: wie viele selbst gehostete Gateways existieren, wie viele exponiert waren oder ob irgendeines vor dem Patchen angegriffen wurde. Keine Quelle in diesem Datensatz nennt eine Anzahl, und GitLabs Sicherheitshinweis enthält keine Erkennungsmethode.

Der betroffene Bereich und die Versionen, für die keine Korrektur aufgeführt ist

Die Versionsarithmetik ist weniger ordentlich, als die drei korrigierten Releases vermuten lassen. Der betroffene Bereich beginnt bei 18.1.6, und auf keiner Linie unter 19.2.4 ist ein korrigiertes Release veröffentlicht. Jedes Gateway von 18.1.6 bis einschließlich der 19.1-Serie liegt daher innerhalb des angegebenen betroffenen Bereichs, ohne dass eine gepatchte Version dafür genannt wird. The Hacker News weist auf dieselbe Konsequenz und die daraus folgenden Fragen hin: In der Installationsdokumentation von GitLab werden Administratoren angewiesen, das Gateway-Image auszuführen, dessen Version ihrer GitLab-Minor-Version entspricht, und der Advisory sagt weder, ob ein Gateway 19.2.4 mit GitLab 19.1 oder älter funktioniert, noch ob Fixes für die älteren Linien geplant sind. Die Richtlinie von GitLab zu unterstützten Versionen listet, wie The Hacker News anmerkt, derzeit 19.4, 19.3 und 19.2 auf — dieselben drei Linien, die Fixes erhalten haben.

Die Behebung erfolgt durch einen Container-Austausch statt durch einen Patch: Das Gateway wird als eigenes Docker-Image oder Helm-Chart ausgeliefert. Die Installationsanleitung von GitLab beschreibt das Stoppen und Entfernen des laufenden Containers, das Abrufen des neuen Images mit einem self-hosted-vX.Y.Z-ee-Tag und das erneute Starten mit unveränderten Umgebungsvariablen; bei Helm-Bereitstellungen wird das Tag im image-Feld des Charts gesetzt. Weder die Sicherheitsmitteilung noch die Installationsanleitung bietet eine Signatur oder einen Indikator, der ein angegriffenes Gateway von einem sauberen unterscheiden würde.

Dieselbe Fehlerklasse, acht Monate früher

Dies ist nicht das erste Mal, dass GitLab eine 9.9 für Template-Injection im AI Gateway veröffentlicht hat. Am 6. Februar 2026 veröffentlichte es AI Gateway 18.6.2, 18.7.1 und 18.8.1 für CVE-2026-1868, in diesem Advisory als „Insecure Template expansion issue“ beschrieben, bei dem die Komponente Duo Workflow Service „anfällig für unsichere Template-Expansion von benutzerbereitgestellten Daten über manipulierte Duo Agent Platform Flow-Definitionen“ war, was sich für Denial of Service oder Codeausführung auf dem Gateway nutzen lässt. Der CVSS-Vektor ist identisch mit dem von Oktober, Zeichen für Zeichen, und ebenso die CWE. Die meldende Person war eine andere: Dieser Fall wurde intern entdeckt, von GitLab-Teammitglied Joern Schneeweisz.

Die Oktober-Meldung erwähnt die Februar-Meldung nicht, und The Hacker News sagt das ausdrücklich. Ob beide dieselbe Ursache haben, eine Korrektur, die nicht hielt, oder lediglich eine Sprache und ein Bedrohungsmodell teilen, beantwortet keines der beiden öffentlichen Dokumente. Fest steht, dass eine Template-Engine in einer KI-Middleware-Komponente nun innerhalb desselben Jahres zwei kritische Sicherheitshinweise zur Befehlsausführung mit derselben Bewertung hervorgebracht hat und dass der zweite nur von einem externen Forscher gefunden wurde.

Was sich geändert hat – und was Betreiber noch entscheiden müssen

Die konkrete Änderung besteht aus drei Image-Tags und einer direkten Kontaktrunde. GitLab gibt an, vor der Veröffentlichung mit Kunden des selbst gehosteten Gateways Kontakt aufgenommen zu haben, und der Sicherheitshinweis wurde am selben Tag zusammen mit den korrigierten Images veröffentlicht. Für alle anderen – GitLab.com, GitLab Dedicated und selbst verwaltete Instanzen, die auf ein von GitLab gehostetes Gateway zeigen – war die Korrektur bereits serverseitig angewendet worden, und nach GitLabs Darstellung war nichts erforderlich.

Für einen Betreiber einer selbst gehosteten Instanz ist die Entscheidung enger und unbequemer als ein normaler Patchzyklus. Für ein Gateway, das nicht sofort umgestellt werden kann, gibt es keine Problemumgehung. Es gibt keine veröffentlichte Methode, um festzustellen, ob der Host zuvor kompromittiert wurde, was bedeutet, dass die einzige rückblickende Option die übliche ist: den Container als ein System zu behandeln, dessen Integrität nicht erwiesen ist, und nach Anzeichen für eine Ausführung außerhalb seines normalen Verhaltens zu suchen. Und für Gateways mit 18.x oder 19.1 nennt der Sicherheitshinweis überhaupt keine Zielversion – eine Auslassung, über die The Hacker News berichtet und auf die GitLabs Mitteilung nicht eingeht.

Die eigene Klassifizierung des Archivs ist bewusst enger gefasst als die des Anbieters. Es führt diesen Eintrag als Schwachstelle, mit Konfidenz A und übereinstimmenden Quellen, nicht umstritten, ohne verzeichneten tatsächlichen Schaden und mit einem Schweregradfeld von „high“ gegenüber „critical“ bei GitLab und NVD. Das sind Antworten auf unterschiedliche Fragen: Die Bewertung beschreibt, was der Fehler ermöglichen würde, und die Einstufung des Archivs beschreibt, was bekanntermaßen geschehen ist. In der öffentlichen Aufzeichnung ist nichts geschehen – keine Ausnutzung, keine Opfer, kein Vorfallbericht. Der Wert des Eintrags liegt darin, dass er mit einer CVE-Nummer und einer behobenen Version genau dokumentiert, wie eine Prompt-Vorlage in der Middleware, auf der Unternehmens-KI-Funktionen beruhen, zu einer Kommandozeile wurde.