GitLab AI Gateway: CVE-2026-90970 mit CVSS 9.9 im Self-Hosting

GitLab hat am 2. Oktober 2026 eine kritische Lücke im GitLab AI Gateway geschlossen. CVE-2026-90970 trägt einen CVSS-Wert von 9.9 und erlaubt es einem angemeldeten Benutzer mit Zugriff auf die Duo Agent Platform, unter bestimmten Bedingungen Befehle auf dem Gateway auszuführen. Betroffen sind ausschließlich selbst gehostete Gateways – und genau die stehen oft bei Unternehmen, die ihre KI-Daten absichtlich im eigenen Haus halten wollen.

Welche Versionen die GitLab AI Gateway Lücke betrifft

Laut Hersteller-Advisory sind alle Gateway-Versionen ab 18.1.6 vor 19.2.4 betroffen, dazu 19.3 vor 19.3.2 und 19.4 vor 19.4.1. Gefixt ist die Lücke in 19.2.4, 19.3.2 und 19.4.1. Einen Workaround nennt GitLab nicht.

Der Fehler sitzt im Prompt-Template eines sogenannten Custom Flow – also eines selbst zusammengestellten, mehrstufigen KI-Arbeitsablaufs. Über eine manipulierte Flow-Konfiguration konnte ein Angreifer aus der Sandbox des Prompt-Templates ausbrechen; das Ergebnis ist beliebige Befehlsausführung auf dem Gateway. GitLab stuft das als „Improper Neutralization of Special Elements Used in a Template Engine“ ein – Fehlerklasse CWE-1336 – und nennt HackerOne-Nutzer invisiblemeerkat als Melder.

Wichtig für die Einordnung: Wer GitLab.com, GitLab Dedicated oder eine selbstverwaltete Instanz mit einem von GitLab betriebenen Gateway nutzt, muss nichts tun. Der Hersteller hat diese Gateways bereits gepatcht. Handeln müssen nur Betreiber eigener Gateways – die laut GitLab vor Veröffentlichung des Advisory direkt informiert wurden.

Wird die Lücke ausgenutzt?

Dafür gibt es derzeit keinen Beleg. Das Advisory sagt nichts über Angriffe, und laut The Hacker News trug die CISA am 2. Oktober eine Bewertung in den CVE-Datensatz ein, die Ausnutzung mit „none“ ausweist – also kein bekannter Angriff. Das ist eine Momentaufnahme, keine Garantie.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Was das für dich bedeutet

Ein AI Gateway ist kein harmloses Zusatzmodul. Es sitzt als eigener Dienst zwischen GitLab und den Modellanbietern – jede Duo-Anfrage läuft über diesen Host. Nach der Installationsdokumentation von GitLab liegen dort Signaturschlüssel für JSON Web Tokens, die wie Zugangsdaten zu behandeln sind. Dazu kommen die Verbindungen zur GitLab-Instanz selbst und zu den Modellanbietern. Wer Befehle auf diesem Host ausführt, steht also nicht am Rand der Pipeline, sondern an einer Stelle mit Vertrauen in zwei Richtungen.

Aus 25 Jahren Betriebserfahrung heraus ist mir an diesem Fall ein anderes Muster wichtiger als der einzelne CVE: Das Gateway wird als eigenes Docker-Image oder Helm-Chart ausgerollt und hat seinen eigenen Aktualisierungsweg. Es fällt damit genau aus dem Prozess heraus, über den die GitLab-Instanz gepatcht wird. Solche Nebenkomponenten sind in Inventaren notorisch unterrepräsentiert – man weiß, dass es sie gibt, aber niemand ist zuständig. Es ist bereits die zweite als 9.9 bewertete Template-Engine-Lücke in diesem Gateway: Im Februar wurde CVE-2026-1868 mit derselben Fehlerklasse CWE-1336 behoben. Zwei Treffer derselben Art in einem Bauteil sind ein Hinweis auf die Architektur, nicht auf Pech.

Und noch ein Punkt, der in der Praxis bitter wird: Für die Linien unterhalb von 19.2 listet GitLab keinen Fix. Wer ein Gateway aus dem Bereich 18.1.6 bis 19.1 betreibt – und die Installationsdokumentation verlangt ein Image, das zur eigenen GitLab-Minor-Version passt –, kann die Lücke nicht durch ein schnelles Tag-Update schließen, sondern nur über ein GitLab-Upgrade. Dass genau diese Linien laut Maintenance-Policy ohnehin keine Security-Fixes mehr erhalten, ist konsistent, macht die Lage aber nicht angenehmer. Das Advisory äußert sich dazu nicht.

Konkrete Handlungsempfehlung

• Erst klären, ob du überhaupt betroffen bist. Relevant ist allein ein von dir selbst betriebenes AI Gateway – unabhängig davon, ob du eigene Modelle fährst oder nur die Anfragedaten im Haus halten wolltest. Prüfbar am Deployment: läuft bei dir ein eigener AI-Gateway-Container beziehungsweise das zugehörige Helm-Chart? Wer ein von GitLab betriebenes Gateway nutzt, ist nicht betroffen.
• Gateway-Version separat erheben – und das passende Fix-Tag wählen. Nicht die GitLab-Version zählt, sondern das Image-Tag des Gateways. Laut Installationsdokumentation muss das Gateway-Image zur GitLab-Minor-Version passen: auf GitLab 19.4.x also self-hosted-v19.4.1-ee, auf 19.3.x die 19.3.2 und auf 19.2.x die 19.2.4. Bei Docker: Container stoppen und entfernen, neues Tag ziehen und starten. Bei Helm: Image-Tag im Chart setzen.
• JWT-Signaturschlüssel rotieren, wenn ein betroffenes Gateway längere Zeit erreichbar war. Das Advisory bietet keine Möglichkeit, einen früheren Angriff nachzuweisen – also im Zweifel die Schlüssel als verbrannt behandeln.
• Zugriff auf die Duo Agent Platform prüfen. Die Lücke setzt einen angemeldeten Benutzer voraus. Wer dort Rechte hat, sollte überprüft und auf das Nötige reduziert werden.
• Nebenkomponenten ins Patch-Inventar aufnehmen. Gateways, Runner, Sidecars, Exporter: alles, was ein eigenes Update-Verfahren hat, braucht einen Verantwortlichen.

Wer über eigene KI-Infrastruktur im Haus nachdenkt, findet die Hardware-Seite in meinem Ratgeber zu Hardware für lokale KI und LLMs. Zur Vorgeschichte passt der Beitrag über die GitLab-Lücke CVE-2026-85706, bei der schon einen Tag nach dem Patch gescannt wurde.

Fazit

CVE-2026-90970 ist kein Massenproblem – die Zielgruppe ist klein und wurde vorab gewarnt. Interessant ist die Lücke trotzdem, weil sie zeigt, wo KI-Komponenten im eigenen Rechenzentrum neue Angriffsfläche schaffen: nicht im Modell, sondern in der Klebeschicht drumherum. Wer selbst hostet, kauft Datenhoheit gegen Patch-Pflicht. Das ist ein fairer Handel, aber man muss ihn auch einhalten.

Quellen

• GitLab: AI Gateway Critical Patch Release 19.2.4, 19.3.2, 19.4.1
• CVE-Record CVE-2026-90970
• The Hacker News: GitLab Patches Critical 9.9 AI Gateway Flaw (2. Oktober 2026)