GitLab: kritische Lücke mit CVSS 9,9 im selbst gehosteten AI Gateway

Der Befund: CVSS 9,9 auf dem Gateway, das mit den Modellen spricht

CVE-2026-90970 trägt einen CVSS-Wert von 9,9 von 10 und trifft das AI Gateway von GitLab. Das Unternehmen hat sie am 2. Oktober 2026 offengelegt, mit einem Advisory, das sie als kritisch einordnet.

Das Gateway ist der Dienst, der eine GitLab-Instanz mit den KI-Modellen verbindet. Nach dem Advisory, aufgegriffen von The Hacker News^[1], kann ein bereits authentifizierter Nutzer mit Zugang zur Duo Agent Platform unter bestimmten Bedingungen Befehle auf dem Gateway ausführen.

Die korrigierten Versionen sind drei: 19.2.4, 19.3.2 und 19.4.1. GitLab hat die selbst betriebenen Gateways bereits aktualisiert. Der Alarm gilt für alle, die das Gateway in der eigenen Infrastruktur betreiben, und BleepingComputer^[2] hat den Fall als kritische Schwachstelle zur Remote-Code-Ausführung aufgegriffen.

Das Unternehmen hat diese Kunden direkt informiert, bevor es den öffentlichen Text veröffentlichte. Die Empfehlung lautet, sofort zu aktualisieren.

Wer handeln muss, und wer bereits abgedeckt ist

Die Liste derjenigen, die stillhalten können, ist klar. GitLab.com, GitLab Dedicated und die self-managed Instanzen, die ein von GitLab gehostetes Gateway nutzen, gelten laut Erklärung des Unternehmens als bereits sicher.

Ungeschützt bleibt, wer den anderen Weg gewählt hat. GitLab bietet self-managed Kunden die Möglichkeit, das Gateway im eigenen Haus zu betreiben, sodass Anfragen und Antworten an die Modelle innerhalb des Unternehmensperimeters bleiben. Diese Wahl entsteht aus Gründen der Datenvertraulichkeit.

Hier kippt die Rechnung. Wer sich entschieden hat, die KI-Daten im eigenen Haus zu halten, besitzt nun auch die anfällige Komponente, den Patch-Zyklus und das operative Risiko. Das Gateway kommt als Docker-Image oder als Helm-Chart, mit einem Aktualisierungspfad, der von dem von GitLab getrennt ist.

Zwei Teams und zwei Kalender treffen auf einen einzigen Punkt der Exposition.

Was dem Angreifer genügte

Die Schwere einer Lücke misst sich auch an der Liste dessen, was unter den Voraussetzungen fehlt. Hier ist die Liste kurz.

Der Angreifer braucht ein gültiges Konto auf der Instanz und den Zugang zur Duo Agent Platform. Zudem müssen bestimmte Bedingungen vorliegen, die das Advisory bewusst allgemein hält.

Außerhalb der Liste bleiben Administratorrechte, eine Exploit-Kette über Dritte und eine Mitwirkung des Opfers. Ein Wert von 9,9 auf einer Oberfläche, die ein authentifizierter interner Nutzer erreicht, beschreibt genau das: den Sprung von der Anwendungsebene auf die Ausführungsebene des Gateways.

Der genaue technische Mechanismus bleibt zurückgehalten, und diese Entscheidung ist richtig. Es zählt die Problemklasse: eine Komponente, die zur Vermittlung von Prompts und Antworten entstanden ist, öffnet einen Weg zur Befehlsausführung. Wer die Advisories von 2026 zu agentischen Frameworks gelesen hat, erkennt das wiederkehrende Motiv.

Die korrigierten Versionen, und die Leere unterhalb von 19.2.4

Die Versionstabelle verdient langsames Lesen, denn sie sagt mehr als die technische Beschreibung.

Wer ein Gateway ab 18.1.6 bis 19.2.4 nutzt, muss auf 19.2.4 wechseln. Die Linie 19.3 schließt mit 19.3.2 ab, die Linie 19.4 mit 19.4.1. Bei einem Docker-Deployment führt das Verfahren über das Stoppen des Containers, das Entfernen und das Pull des neuen Images, zum Beispiel self-hosted-v19.4.1-ee. Helm verlangt den neuen Tag in der Einstellung image des Charts.

Unterhalb von 19.2.4 endet die Tabelle. Alle Releases von 18.1.6 bis zur Linie 19.1 fallen in den betroffenen Bereich, und für diese Linien fehlt eine korrigierte Version.

Die Installationsanleitung verlangt, das Gateway-Image zu verwenden, das zur minor version von GitLab passt. Das Advisory schweigt zu einem praktischen Punkt: der Kompatibilität zwischen einem Gateway 19.2.4 und einem GitLab 19.1 oder älter. Zum 2. Oktober führt die maintenance policy 19.4, 19.3 und 19.2 als Linien auf, die Sicherheitsfixes erhalten, dieselben drei, die den Patch für das Gateway bekommen haben.

Die eigentliche Bedingung: der gewählte Perimeter wird zum Ziel

Die Grenze, die zum Schutz der Daten gebaut wurde, wird zur Grenze, die verteidigt werden muss. Das gilt für das Self-Hosting des Gateways, wie es für Egress-Proxys und für Vaults on premise gilt.

Die Security Posture von KI-Systemen läuft der Reife der Infrastruktur, die sie beherbergt, zwei bis drei Jahre nach: das bleibt eine der Positionen dieses Desks, und der Fall bestärkt sie. Ein AI Gateway ist eine privilegierte Netzkomponente, mit Zugangsdaten für die Modelle und Einblick in die Prompts. Es verdient die Behandlung eines Bastion Hosts.

Die gängige Praxis verortet es oft anderswo, im Backlog des Plattformteams.

Hier kommt auch die Identität des Agenten ins Spiel, die Kontrollebene des Jahres 2026. Eine Duo Agent Platform, die ein authentifizierter Nutzer erreicht, erbt das Vertrauen dieses Nutzers und trägt es auf einen Dienst, der ausführt. Die Grenze zwischen dem, der anfragt, und dem, der ausführt, gehört auf der Autorisierungsebene ausdrücklich gezogen.

Wozu das Advisory schweigt

Zwei Lücken im Text wiegen mehr als die technische Beschreibung.

Die erste: Es fehlt ein Workaround für die Gateways, die auf das Update warten. Wer lange Change-Management-Fenster hat, steht vor einer harten Wahl zwischen dem Abschalten des Dienstes und der Annahme des Risikos.

Die zweite: Das Advisory schweigt dazu, wie ein Missbrauch vor dem Patch zu prüfen ist. Null Kompromittierungsindikatoren und null Hinweise auf zu prüfende Logs. Null Signaturen. Ein Administrator, der heute aktualisiert, schließt die Tür und bleibt blind für die Vergangenheit.

Zur Ausnutzung hat die US-Behörde CISA am 2. Oktober eine Bewertung zum CVE-Eintrag ergänzt und weist die Ausnutzung dort als nicht vorhanden aus. Die zwei weiteren vorgesehenen Werte decken das Vorliegen eines öffentlichen Proof of Concept und die aktive Ausnutzung ab. Die Momentaufnahme gilt für dieses Datum und ist bei jeder Aktualisierung des Eintrags neu zu lesen.

Drei Fragen an das KI-Team im Unternehmen

Der Patch-Zyklus dieser Komponente gehört vom Zyklus von GitLab gelöst, im Asset-Register wie im operativen Kalender. Ein separates Docker-Image ist ein separates Asset, mit einem Eigentümer, der für seinen Zustand einsteht.

1. Welche Version läuft heute auf dem AI Gateway in Produktion, und wer aktualisiert sie?
2. Fällt das Gateway in das Fenster 18.1.6-19.1, für das eine korrigierte Version fehlt?
3. Welche Logs des Gateways werden aufbewahrt, und für wie viele Tage?

Wer auf alle drei Fragen mit einer genauen Versionsnummer antwortet, schließt den Tag ab. Wer «hängt vom Team ab» antwortet, hat den eigentlichen Befund gefunden, und er betrifft die interne Governance noch vor dem Patch.

Die dritte Frage ist die teuerste. Fehlen aufbewahrte Logs, bleibt die nachträgliche Prüfung unmöglich, und dieselbe Lücke kehrt beim nächsten Advisory zur gleichen Komponentenklasse zurück.

Entscheidungen für den nächsten Planungszyklus

Für den CTO ist die Frage eine des Inventars, noch vor der Sicherheit. Die Liste der selbst gehosteten KI-Komponenten mit Zugangsdaten für die Modelle gehört ausdrücklich geführt, mit Eigentümer und Version neben jeder Zeile.

Für den Leiter Engineering ist der Hebel die Aktualisierungszeit. Ein Docker-Image, das in einer Stunde austauschbar ist, verändert das Risikoprofil einer Lücke mit 9,9; eines, das drei Wochen braucht, vervielfacht es.

Für den CFO ist der Kostenpunkt die technische Schuld des Self-Hostings. KI-Daten im eigenen Haus zu halten hat laufende Wartungskosten, und diese Kosten gehören neben den Nutzen der Vertraulichkeit in die Bilanz.

Für das Einkaufsgremium ist der vertragliche Punkt die Benachrichtigung. GitLab hat die Kunden mit selbst gehostetem Gateway vor der Veröffentlichung informiert: eine Zusage dieser Art verdient einen Platz im Vertrag, mit definierten Fristen und erklärtem Kanal.

Die falsifizierbare Prognose lautet: innerhalb von zwölf Monaten erhält mindestens ein weiteres selbst gehostetes AI Gateway eines großen Anbieters ein kritisches Advisory derselben Form, also ein authentifizierter Nutzer, der zur Ausführung gelangt. Das Architekturmodell macht das wahrscheinlich.