Absicherung des GitLab AI Gateway gegen Remote Code Execution

Große Unternehmen geben Millionen aus, um ihre KI-Workloads hinter privaten Firewalls und selbst gehosteten Gateways zu isolieren. Sie erwarten die volle Kontrolle über ihren Datenfluss und einen gehärteten Perimeter gegen externe Bedrohungen. Die tatsächliche Ausnutzbarkeit der GitLab AI Gateway Version 19.4 zeigt jedoch, dass selbst die isoliertesten Umgebungen anfällig für einfache Eingabefehler bleiben. Ein einzelner angemeldeter Benutzer mit Zugriff auf die Duo Agent Platform kann die Sandbox umgehen, die eigentlich KI-Prompts eingrenzen soll. Dieser Ausbruch führt direkt zur Ausführung beliebiger Befehle auf dem Server, der die Verbindung der Organisation zu großen Sprachmodellen verwaltet.

Ich habe Jahre damit verbracht zu analysieren, wie Entwickler Template-Engines als Sicherheitszonen betrachten. Es gibt das weit verbreitete Missverständnis, dass das Risiko eines Sandbox-Ausbruchs zweitrangig ist, wenn ein Benutzer bereits authentifiziert ist. Diese Denkweise ist gefährlich. Im Fall von CVE-2026-90970 bewertete GitLab die Schwachstelle mit 9,9 von 10 Punkten auf der CVSS-Skala. Dieser Wert ist ein klarer Indikator dafür, dass die Sicherheits-Community dies als kritischen Fehler betrachtet. Die Schwachstelle ist keine subtile Speicherbeschädigung oder ein komplexer Timing-Angriff. Es handelt sich um einen Fehler im Prompt-Template eines benutzerdefinierten Flows – einer Funktion, die zur Automatisierung mehrstufiger Aufgaben entwickelt wurde.

Das architektonische Risiko sensibler Signierschlüssel

Das GitLab AI Gateway fungiert als bruchsicherer digitaler Tresor für die Verbindung zwischen einer internen GitLab-Instanz und externen KI-Anbietern. Konstruktionsbedingt verwaltet dieses Gateway JSON Web Token (JWT) Signierschlüssel. Diese Schlüssel sind sensible Anmeldedaten, die eine sichere Kommunikation ermöglichen. Wenn ein Angreifer Befehle auf dem Gateway ausführt, ist er nicht mehr nur ein Benutzer innerhalb einer Sandbox. Er besitzt dieselben Berechtigungen wie der Gateway-Dienst selbst. Diese Zugriffsebene erlaubt es einem böswilligen Akteur, Anfragen abzufangen oder potenziell die KI-Antworten zu manipulieren, auf die sich andere Entwickler im Unternehmen für die Code-Generierung und Sicherheits-Scans verlassen.

Aus Risikoperspektive ist die Auswirkung systemisch. Ein selbst gehostetes Gateway wird oft gezielt gewählt, um Daten innerhalb einer kontrollierten Umgebung zu halten. Wenn dieses Gateway kompromittiert wird, wird genau das Werkzeug, das die Privatsphäre verbessern sollte, zum Brückenkopf für ein größeres Eindringen. Das Gateway verbindet sich mit den KI-Modellanbietern der Organisation und der primären GitLab-Instanz. Eine Kompromittierung an dieser Stelle ist eine Kompromittierung der Vertrauensbeziehung zwischen der Entwicklungsumgebung und der Intelligenzschicht, die sie antreibt.

Dekonstruktion des Sandbox-Ausbruchs durch Prompt Injection

Die technische Realität dieser Schwachstelle liegt in CWE-1336, was die unsachgemäße Neutralisierung von Direktiven in Webseiten-Templates abdeckt. GitLab erlaubt es Benutzern, benutzerdefinierte Flows auf der Duo Agent Platform zu erstellen. Diese Flows verwenden Prompt-Templates, um zu strukturieren, wie die KI Informationen verarbeitet. Ein Benutzer mit legitimem Zugriff kann eine Flow-Konfiguration erstellen, die die Template-Engine dazu verleitet, Code außerhalb ihrer vorgesehenen Grenzen auszuführen. Dies ist der klassische Sandbox-Ausbruch. Das System behandelt die bösartige Eingabe des Angreifers als Befehl und nicht als Daten.

Hinter den Kulissen versäumt es das Gateway, die Struktur des Prompt-Templates ordnungsgemäß zu validieren. Ich erinnere mich an einen ähnlichen Fall, den ich letztes Jahr mit einem White-Hat-Hacker über eine Signal-Verbindung besprochen habe. Wir untersuchten eine Template-Engine, die es Benutzern ermöglichte, Systemfunktionen aufzurufen, wenn sie ihre Klammern auf eine bestimmte Weise verschachtelten. Es war ein einfaches Versäumnis im Parser. Die jüngste Geschichte von GitLab deutet darauf hin, dass dies ein wiederkehrendes Thema ist. Im Februar patchten sie CVE-2026-1868, eine weitere 9,9-Schwachstelle, die ebenfalls manipulierte Flow-Definitionen betraf. Die Wiederholung dieser Schwachstellenklasse zeigt, dass Template-Sicherheit eine schwierige Hürde für KI-integrierte Plattformen bleibt.

Bewertung der Angriffsfläche für selbst gehostete Instanzen

Nur Organisationen, die ihr eigenes AI Gateway hosten, müssen handeln. GitLab verwaltet das Gateway für Kunden auf GitLab.com und GitLab Dedicated. Proaktiv gesehen sind diese Kunden bereits geschützt, da GitLab seine eigene Infrastruktur vor der öffentlichen Bekanntgabe aktualisiert hat. Die Last der Verteidigung liegt nun auf den Schultern der Systemadministratoren, die ihre eigenen Docker-Images oder Helm-Charts verwalten.

Auf architektonischer Ebene ist das Gateway ein eigenständiger Dienst. Es wird nicht automatisch aktualisiert, wenn Sie die Hauptinstanz von GitLab aktualisieren. Diese Trennung ist wichtig. Eine häufige Falle besteht darin, anzunehmen, dass eine gepatchte GitLab-Rails-Anwendung eine gepatchte KI-Umgebung bedeutet. Das Gateway ist ein separates Docker-Image mit eigener Versionierung und eigenem Lebenszyklus. Wenn Sie eine Version zwischen 18.1.6 und 19.2.4 oder eine Version in den Linien 19.3 und 19.4 vor den neuesten Versionen ausführen, sind Sie anfällig.

Manuelle Update-Schritte für Docker und Helm

Das Patchen ist die einzige wirksame Gegenmaßnahme, da GitLab keinen Workaround bereitgestellt hat. Um eine Docker-basierte Bereitstellung zu sichern, müssen Sie den vorhandenen Container stoppen und entfernen. Anschließend ziehen Sie das aktualisierte Image-Tag. Für die meisten Unternehmenskunden wird dies das Tag self-hosted-v19.4.1-ee oder das entsprechende Pendant für die Linien 19.2 und 19.3 sein.

Für diejenigen, die Kubernetes verwenden, umfasst der Prozess die Aktualisierung der Image-Einstellung im Helm-Chart. Die folgende Tabelle fasst die notwendigen Update-Pfade für betroffene Versionen zusammen:

Die Wartungsrichtlinie von GitLab deckt im Allgemeinen das aktuelle und die beiden vorherigen Minor-Releases ab. Folglich sind die Fixes für die Linien 19.2, 19.3 und 19.4 verfügbar. Wenn Sie eine ältere Version wie 19.1 ausführen, ist kein offizieller Fix aufgeführt. Dieser Mangel an Unterstützung für ältere Versionen ist ein wichtiges Detail, das Administratoren nicht übersehen dürfen. Das Ausführen einer nicht unterstützten Version des Gateways bedeutet effektiv, den digitalen Tresor unverschlossen zu lassen.

Forensische Einschränkungen und das Fehlen von Ausnutzungen

Bis heute listet die U.S. Cybersecurity and Infrastructure Security Agency (CISA) die Ausnutzung dieser Schwachstelle als "keine". Es gibt keinen öffentlichen Proof of Concept und keine Beweise für eine aktive Ausnutzung in freier Wildbahn. Der Sicherheitshinweis bietet jedoch keine Methode, um zu prüfen, ob ein Gateway vor dem Update angegriffen wurde. Dieser Mangel an forensischer Sichtbarkeit ist eine erhebliche Lücke. Ohne spezifische Log-Signaturen oder Kompromittierungsindikatoren müssen Administratoren rätseln, ob auf ihre Signierschlüssel während des Zeitfensters der Verwundbarkeit zugegriffen wurde.

Im Falle einer Sicherheitsverletzung bei einem Tool wie diesem ist das Ziel oft eine unauffällige Persistenz. Ein Angreifer bringt das Gateway möglicherweise nicht zum Absturz. Stattdessen könnte er heimlich die JWT-Signierschlüssel exportieren, um später unbefugten Zugriff auf KI-Modelle zu ermöglichen. Aus diesem Grund ist die sofortige Rotation sensibler Anmeldedaten nach einem Patch eine branchenübliche Praxis. Das Flicken des Lochs im Schiffsrumpf ist der erste Schritt, aber man muss auch prüfen, ob Ladung über Bord geworfen wurde, während das Loch offen war.

Das menschliche Element in der KI-Sicherheit

Wir behandeln KI oft als eine futuristische Schicht, die über unserem bestehenden Code liegt. In Wirklichkeit sind KI-Dienste wie das GitLab Gateway nur weitere Software. Sie unterliegen denselben klassischen Schwachstellen wie Command Injection und Template-Escapes. Die menschliche Firewall bleibt die erste Verteidigungslinie. Die Benutzer, die Zugriff auf die Duo Agent Platform haben, sind diejenigen, die diese Schwachstelle erreichen können. Den Zugriff auf diese Plattformen nur auf diejenigen zu beschränken, die ihn unbedingt benötigen, folgt dem Prinzip der geringsten Privilegien.

Zero Trust ist wie ein VIP-Club-Türsteher an jeder internen Tür. Selbst wenn ein Benutzer im Gebäude ist, sollte der Türsteher seine Anmeldedaten prüfen, bevor er ihn in die Nähe der Template-Engine-Konfiguration lässt. Wenn Ihre Organisation jedem Entwickler erlaubt, ohne Aufsicht benutzerdefinierte KI-Flows zu erstellen, vergrößern Sie Ihre Angriffsfläche. Die Komplexität dieser KI-Integrationen macht eine granulare Zugriffskontrolle eher zu einer Anforderung als zu einem Vorschlag.

Erkenntnisse für die sofortige Schadensbegrenzung

Um diese kritische Schwachstelle zu beheben, sollten Administratoren eine bestimmte Abfolge von Maßnahmen befolgen. Identifizieren Sie erstens die genaue Version des AI Gateway-Images, das derzeit in der Umgebung ausgeführt wird. Gehen Sie nicht davon aus, dass die Version mit der GitLab-Hauptanwendung übereinstimmt. Wenden Sie zweitens den relevanten Patch sofort mit den von GitLab bereitgestellten Docker- oder Helm-Verfahren an. Ziehen Sie drittens die Rotation der JWT-Signierschlüssel in Betracht, falls das Gateway vor dem Patch nicht vertrauenswürdigen internen Benutzern ausgesetzt war.

Überprüfen Sie abschließend die Liste der Benutzer, die die Berechtigung haben, benutzerdefinierte Flows auf der Duo Agent Platform zu konfigurieren. Wenn ein Benutzer keinen geschäftskritischen Grund hat, diese Konfigurationen zu ändern, entziehen Sie ihm den Zugriff. Die Reduzierung der Anzahl der Personen, die die Schwachstelle erreichen können, ist ebenso wichtig wie die Behebung des Codes selbst. Sicherheit ist ein kontinuierlicher Prozess der Verfeinerung, kein einmaliges Update.

Quellen

• GitLab Security Advisory (CVE-2026-90970)
• CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
• CWE-1336: Improper Neutralization of Directives in Web Page Templates
• NIST Guide to Enterprise Patch Management Strategies

Haftungsausschluss: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken. Er ersetzt kein professionelles Cybersicherheits-Audit oder einen Incident Response Service. Konsultieren Sie immer die offizielle Dokumentation des Herstellers, bevor Sie System-Updates durchführen.