GitLab AI Gateway-Schwachstelle macht autorisierten Duo-Zugriff zu einem kritischen RCE-Risiko
GitLab hat eine mit 9,9 bewertete Schwachstelle in GitLab AI Gateway behoben, die autorisierten Zugriff auf die Duo Agent Platform in die Ausführung von Befehlen auf einem selbst gehosteten Gateway verwandeln kann. Der als CVE-2026-90970 geführte Fehler durchbricht eine Grenze, die das Produkt eigentlich durchsetzen sollte. Eine präparierte Flow-Konfiguration kann aus der Prompt-Template-Sandbox ausbrechen und beliebige Befehle auf dem Gateway ausführen.
Diese Einschränkung ist wichtig. Es handelt sich nicht um einen gemeldeten Zero-Click-Kompromiss jedes GitLab-Servers, und ein anonymer Internetnutzer erhält dadurch keinen unmittelbaren Zugriff. Für eine Ausnutzung sind Authentifizierung und Zugriff auf die Duo Agent Platform erforderlich. GitLabs Schweregradbewertung spiegelt jedoch wider, was nach Erfüllung dieser Bedingungen geschieht: Netzwerkausnutzung mit geringer Komplexität, keine weitere Nutzerinteraktion und potenziell schwerwiegende Folgen für Vertraulichkeit, Integrität und Verfügbarkeit.
Der Vorfall erzeugt einen direkten Konflikt zwischen Kontrolle und Verantwortung. Unternehmen hosten KI-Infrastruktur selbst, um Code, Prompts und Modellverkehr innerhalb vertrauenswürdiger Grenzen zu halten. Self-Hosting macht diese Unternehmen jedoch auch für die Aktualisierung des Dienstes verantwortlich, der dieses sensible Material verarbeitet. Von GitLab gehostete Gateways wurden bereits gepatcht, während Betreiber betroffener selbst gehosteter Gateways ihre Upgrades selbst durchführen müssen.
Was die GitLab AI Gateway-Schwachstelle verändert hat
CVE-2026-90970 macht die Berechtigung zur Konfiguration eines KI-Workflows zu einem potenziellen Weg zu Betriebssystembefehlen.
GitLab veröffentlichte die Schwachstelle am 2. Oktober 2026. Laut dem öffentlichen Schwachstelleneintrag umfassen betroffene Releases AI Gateway-Versionen ab 18.1.6 bis zu Versionen vor 19.2.4. Der 19.3-Zweig ist vor 19.3.2 betroffen, während der 19.4-Zweig vor 19.4.1 betroffen ist.
Diese Versionsgrenzen unterscheiden sich von der Release-Historie der Hauptanwendung von GitLab. Administratoren sollten daher das AI Gateway-Image oder die Bereitstellung selbst überprüfen. Die ausschließliche Prüfung der sichtbaren GitLab-Anwendungsversion kann ein falsches Sicherheitsgefühl erzeugen, wenn das Gateway einem separaten Bereitstellungszyklus folgt.
Die behobenen Versionen sind 19.2.4, 19.3.2 und 19.4.1. Betreiber sollten auf das passende behobene Release oder eine spätere unterstützte Version wechseln. Von GitLab gehostete Gateways haben die Fehlerbehebung bereits erhalten; GitLab.com und Kunden, die GitLabs verwaltetes Gateway nutzen, stehen daher nicht vor derselben Patch-Aufgabe.
Der anfällige Pfad beginnt mit einer speziell präparierten Flow-Konfiguration. Ein Flow definiert eine agentische Abfolge, die Prompts, Tools, Entscheidungen und Aktionen kombinieren kann. GitLab Duo Agent Platform verwendet diese Konfigurationen, um mehrstufige Aufgaben der Softwareentwicklung auszuführen, statt einen einzelnen isolierten Prompt zu beantworten.
Prompt-Templates wandeln die Konfiguration und Laufzeitdaten eines Flows in Anweisungen um, die ein KI-Modell verarbeiten kann. Eine Template-Sandbox ist die eingeschränkte Umgebung, die verhindern soll, dass Template-Inhalte unsichere Anwendungs- oder Betriebssystemfunktionen erreichen. CVE-2026-90970 betrifft eine unzureichende Neutralisierung innerhalb dieser Grenze.
Die Schwäche ist als CWE-1336 kategorisiert, also als unzureichende Neutralisierung spezieller Elemente in einer Template-Engine. Praktisch bedeutet dies, dass von Angreifern kontrollierte Syntax als ausführbares Template-Verhalten statt als inerte Daten interpretiert werden kann. Das genaue gefährliche Ergebnis hängt von der umgebenden Anwendung, verfügbaren Funktionen und Prozessberechtigungen ab.
Bei dieser Schwachstelle kann dies laut GitLab zur Ausführung beliebiger Befehle auf dem AI Gateway führen. Dieses Ergebnis ist schwerwiegender als die Manipulation einer KI-Antwort. Es bedeutet, dass die Schwachstelle über die Modellausgabe hinaus bis in die herkömmliche Ausführungsumgebung reicht, die das Gateway hostet.
Die Unterscheidung zwischen dem AI Gateway und einem Large Language Model ist wichtig. Das Gateway ist ein eigenständiger Anwendungsdienst, der zwischen GitLab-Funktionen und KI-Modellen positioniert ist. GitLabs Gateway-Dokumentation zufolge ermöglicht der Dienst den Zugriff auf KI-native GitLab Duo-Funktionen. Er verarbeitet Anwendungslogik und Anfragen rund um das Modell, statt selbst als Modell zu fungieren.
Folglich belegt die Schwachstelle nicht, dass ein Modell eigenständig einen Ausbruch entdeckt oder eine Sicherheitsanweisung zum Verhalten ignoriert hat. Der gemeldete Mechanismus ist eine Softwareschwachstelle in der Template-Verarbeitung. Ihre Eingabe erreicht sie lediglich über eine agentische Konfigurationsoberfläche.
Damit bleibt der Vorfall in einer vertrauten Sicherheitskategorie, doch das Umfeld erhöht den Einsatz. KI-Gateways können aus Quellcode abgeleiteten Kontext, Workflow-Anweisungen, Authentifizierungsmaterial und Verbindungen zu Modell-Backends verarbeiten. Eine Schwachstelle zur Befehlsausführung an dieser Schnittstelle kann mehr offenlegen als einen fehlerhaften Prompt oder eine unzuverlässige Antwort.
GitLab hat keine weitverbreitete Ausnutzung von CVE-2026-90970 öffentlich beschrieben. Die verfügbaren Einträge belegen auch nicht, dass Angreifer die Schwachstelle gegen Produktionsumgebungen eingesetzt haben. Administratoren sollten diese Bestätigungslücke nicht als Sicherheitsnachweis interpretieren, insbesondere nachdem die Offenlegung potenziellen Angreifern ein klareres Ziel liefert.
Die unmittelbare Veränderung ist daher operativ. Ein selbst gehostetes AI Gateway, das zuvor als kontrollierte interne Komponente behandelt wurde, erfordert nun dringend eine Versionsprüfung, Patches und eine Überprüfung nach dem Upgrade. Sein Risiko lässt sich nicht allein daraus ableiten, ob die Hauptoberfläche von GitLab öffentlich zugänglich ist.
Warum ein authentifizierter Sandbox-Ausbruch eine Bewertung von 9,9 erhält
Die Schwachstelle ist kritisch, weil ihre Voraussetzungen zwar einschränken, wer angreifen kann, ihre potenziellen Auswirkungen nach einem Sandbox-Ausbruch jedoch weitreichend bleiben.
GitLab bewertete CVE-2026-90970 mit einem CVSS-3.1-Basiswert von 9,9. Der veröffentlichte Vektor lautet AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Jedes Element erklärt, warum ein authentifizierter Fehler dennoch nahe der Spitze der Schweregradskala liegen kann.
Der Netzwerkangriffsvektor bedeutet, dass ein potenzieller Angreifer keinen lokalen Shell-Zugriff auf den Gateway-Host benötigt. Der relevante Dienst kann die bösartige Konfiguration über netzwerkzugängliche Anwendungsfunktionen empfangen. Netzwerkzugänglich bedeutet nicht zwingend, dass der Dienst dem gesamten öffentlichen Internet ausgesetzt ist, erweitert den möglichen Angriffsweg jedoch über physischen oder lokalen Zugriff hinaus.
Geringe Angriffskomplexität zeigt an, dass die Ausnutzung nicht von einer engen Race Condition oder einem ungewöhnlichen Bereitstellungszustand abhängt. Es sind geringe statt gar keine Berechtigungen erforderlich. Der Nutzer muss authentifiziert sein und Zugriff auf die Duo Agent Platform haben.
Keine Nutzerinteraktion bedeutet, dass keine weitere Person eine Datei öffnen, einen Dialog bestätigen oder einen bösartigen Link aufrufen muss, nachdem die Konfiguration den anfälligen Pfad erreicht hat. Dieses Merkmal ist in kollaborativen Entwicklungsumgebungen relevant, in denen vertrauenswürdige Automatisierung eingereichte Konfigurationen häufig ohne eine zweite menschliche Aktion verarbeitet.
Die Komponente mit geändertem Scope ist besonders bedeutsam. Sie zeigt an, dass eine Ausnutzung Ressourcen außerhalb der Sicherheitsautorität betreffen kann, die durch die ursprünglich anfällige Komponente repräsentiert wird. Hier beginnt die Template-Eingabe innerhalb eines autorisierten Agent-Workflows, kann jedoch in die Befehlsausführungsumgebung des Gateways übertreten.
Die letzten drei Metriken erfassen hohe potenzielle Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Befehlsausführung kann theoretisch das Lesen zugänglicher Informationen, das Ändern von Gateway-Ressourcen oder die Störung des Dienstes ermöglichen. Der tatsächliche Schaden hängt weiterhin von der Bereitstellungsarchitektur, Prozessberechtigungen, Netzwerkerreichbarkeit und verfügbaren Zugangsdaten ab.
Dieser Kontext verhindert zwei irreführende Interpretationen. Die Bezeichnung der Schwachstelle als „authentifiziert“ sollte nicht dazu dienen, sie als gewöhnliches Problem auf Kontoebene abzutun. Die Bezeichnung als „Remote Code Execution“ sollte nicht den Eindruck erwecken, dass jeder anonyme Besucher eine GitLab-Umgebung unmittelbar kompromittieren kann.
Der relevante Angreifer könnte bereits ein gültiger Nutzer sein. Ebenso könnte es sich um jemanden handeln, der ein kompromittiertes Konto, ein gestohlenes Token oder eine überprivilegierte Automatisierungsidentität kontrolliert. Sicherheitsgrenzen müssen auch nach der Authentifizierung weiter funktionieren, denn legitimer Zugriff ist selten gleichbedeutend mit unbegrenzter Infrastrukturautorität.
Agent-Systeme machen diese Unterscheidung dringlicher. Sie akzeptieren strukturierte Anweisungen und können Aktionsfolgen über Entwicklungsdienste hinweg ausführen. Ein Nutzer, der zum Definieren eines Flows berechtigt ist, benötigt möglicherweise umfassende Anwendungsfähigkeiten, sollte jedoch nicht die Betriebssystemberechtigungen des Dienstes erben, der den Flow interpretiert.
Die anfällige Sandbox sollte diese Trennung bewahren. Ihr Versagen macht aus einer Konfigurationssprache eine mögliche Ausführungsoberfläche. Darin liegt die zentrale Umkehrung hinter der GitLab AI Gateway-Schwachstelle: Eine Funktion, die Agent-Aktionen steuern soll, wird zu einem Weg um ihre eigene Containment-Schicht herum.
Template-Injection unterscheidet sich zudem von Prompt-Injection. Prompt-Injection manipuliert Anweisungen, die an ein Modell gesendet werden, häufig mit dem Ziel, das Verhalten des Modells umzulenken oder Kontextdaten offenzulegen. Template-Injection zielt auf die Software, die diese Prompts erstellt oder rendert. Wenn die Template-Engine unsichere Objekte oder Funktionen bereitstellt, kann das Ergebnis serverseitige Ausführung umfassen, unabhängig davon, wie das Modell reagiert.
CWE-1336 formalisiert diese Fehlerklasse. Die Schwäche in Template-Engines tritt auf, wenn Software Elemente nicht neutralisiert, die eine Template-Engine als ausführbare Syntax behandelt. Die sicherste Reaktion ist keine weitere Verhaltensanweisung für das Modell. Sie ist eine Softwarekorrektur, die verhindert, dass von Angreifern kontrollierte Daten zu ausführbarem Template-Inhalt werden.
Dieser Unterschied sollte die Vorfallsprüfung prägen. Teams müssen Anwendungsberechtigungen, Konfigurationshistorien, Gateway-Logs, Container-Aktivitäten und nachgelagerte Zugangsdaten untersuchen. Die alleinige Prüfung von KI-Konversationstranskripten würde Aktivitäten im Gateway-Prozess oder seiner umgebenden Laufzeitumgebung übersehen.
Ein Gateway nimmt häufig eine privilegierte Integrationsposition ein, selbst wenn es nicht als root läuft. Es kann mit der GitLab-Instanz, Modellservern, Observability-Systemen oder internen Netzwerkdiensten kommunizieren. Betreiber sollten diese Verbindungen abbilden, statt anzunehmen, dass Befehlsausführung in einem Container automatisch einem vollständigen Infrastrukturkompromiss entspricht.
Containerisierung kann die Auswirkungen bei guter Konfiguration verringern, beseitigt den Vorfall jedoch nicht. Ein kompromittierter Container kann weiterhin eingebundene Secrets, Service-Tokens, netzwerkzugängliche Systeme oder vom Prozess verarbeitete Daten offenlegen. Übermäßige Berechtigungen, beschreibbare Mounts und weitreichende Netzwerkpfade vergrößern diesen Schadensradius.
Die Bewertung von 9,9 beschreibt daher eine standardisierte Worst-Case-Einschätzung und ist kein Beweis dafür, dass jede betroffene Umgebung maximalen Schaden erlitten hat. Administratoren müssen diese Bewertung mit ihrer tatsächlichen Bereitstellungsarchitektur verbinden. Die richtige Schlussfolgerung ist eine dringende Untersuchung und Behebung, nicht die automatische Bestätigung eines Sicherheitsvorfalls.
Self-Hosting tauscht Datenkontrolle gegen Patch-Verantwortung
Das Sicherheitsversprechen eines selbst gehosteten Gateways bleibt nur dann gültig, wenn Kunden dieses Gateway als kritische Infrastruktur inventarisieren, isolieren, aktualisieren und überwachen können.
GitLab unterstützt verwaltete, hybride und vollständig selbst gehostete KI-Konfigurationen. In der verwalteten Variante betreibt GitLab das Gateway und verbindet es mit ausgewählten externen Modellanbietern. Eine selbst gehostete Bereitstellung platziert das Gateway und den Modellpfad innerhalb einer vom Kunden kontrollierten Infrastruktur.
Diese Architektur kann strenge Anforderungen an Datenschutz, Datenresidenz und Netzwerktrennung erfüllen. Der Leitfaden für Self-Hosting von GitLab besagt, dass Organisationen ihr eigenes Gateway und eigene Modelle betreiben können, um die vollständige Kontrolle über die KI-Infrastruktur zu behalten. Eine vollständig selbst gehostete Konfiguration kann auch in einem Netzwerk mit eingeschränktem oder keinem allgemeinen Internetzugang betrieben werden.
CVE-2026-90970 offenbart die andere Seite dieses Kompromisses. Der Kunde gewinnt Kontrolle über Standort und Datenflüsse, übernimmt aber auch die Wartung des bereitgestellten Gateways. GitLab kann einen Container, der innerhalb einer kundenseitig kontrollierten Umgebung läuft, nicht unbemerkt aktualisieren.
Diese Verantwortung kann unklar werden, weil ein KI-Gateway neben vertrauterer Entwicklungsinfrastruktur steht. Plattformteams verwalten möglicherweise die GitLab-Anwendung, während Machine-Learning-Teams den Modellserver betreuen. Eine weitere Gruppe könnte für die Containerplattform oder Netzwerksteuerungen zuständig sein.
Wenn kein Team ausdrücklich für das Gateway-Image verantwortlich ist, kann dessen Patch-Status zwischen diesen Zuständigkeitsgrenzen verloren gehen. Ein verwaltetes Gateway vermeidet dieses spezifische Koordinationsproblem, weil der Anbieter die Bereitstellung kontrolliert. Self-Hosting erfordert einen internen Prozess, der das Gateway als eigenständigen Produktionsdienst behandelt.
Das Inventar ist der erste kritische Punkt. Organisationen müssen wissen, ob sie GitLabs verwaltetes Gateway, ein selbst gehostetes Gateway oder eine hybride Einrichtung verwenden. Hybride Bereitstellungen erfordern ein Verständnis auf Funktionsebene, weil manche Anfragen Kundeninfrastruktur nutzen können, während andere über von GitLab verwaltete Dienste laufen.
Die Versionsbestimmung ist der zweite kritische Punkt. Betreiber sollten jede selbst gehostete Gateway-Instanz identifizieren, einschließlich Proof-of-Concept-Systemen und isolierten Umgebungen. Eine isolierte Bereitstellung kann weiterhin durch authentifizierte Insider oder kompromittierte Identitäten gefährdet sein, selbst wenn sie keinen direkten Internetverkehr empfangen kann.
Das Patchen ist der dritte kritische Punkt. Betroffene Installationen benötigen eine korrigierte Gateway-Version, nicht nur ein Update der sichtbaren GitLab-Anwendung. Teams sollten Bereitstellungsnachweise sichern, den vorherigen Image-Digest dokumentieren und bestätigen, dass Workloads mit der vorgesehenen Version neu gestartet wurden.
Der vierte kritische Punkt ist die Expositionsanalyse. Administratoren sollten feststellen, welche Nutzer und Dienstkonten während des anfälligen Zeitraums Zugriff auf die Duo Agent Platform hatten. Sie sollten außerdem klären, wer Flows erstellen oder ändern konnte und ob diese Aktionen verwertbare Audit-Aufzeichnungen erzeugten.
Der fünfte Punkt ist die Laufzeitprüfung. Eine Untersuchung nach dem Patch sollte das Prozessverhalten des Gateways mit seiner normalen Baseline vergleichen. Unerwartete Kindprozesse, Befehlsinterpreter, Dateiänderungen, neue ausgehende Verbindungen oder ungewöhnliche Container-Neustarts verdienen eine Untersuchung.
Secrets erfordern besondere Aufmerksamkeit. GitLabs Installationsdokumentation erklärt, dass das Gateway signierte JSON Web Tokens zur Authentifizierung von Anfragen verwendet. Selbst gehostete Dienste erhalten außerdem Konfigurationswerte und Schlüssel über ihre Laufzeitumgebung. Diese Mechanismen sind für den Normalbetrieb notwendig, doch alle Zugangsdaten, auf die ein kompromittierter Prozess zugreifen kann, müssen möglicherweise rotiert werden.
Die Installationsanleitung beschreibt außerdem AI Gateway und Duo Agent Platform als getrennte Dienste mit getrennten Signaturschlüsselpaaren. Diese Trennung bietet Verteidigern einen nützlichen Rahmen für die Überprüfung. Sie sollten beide Dienste, ihre Vertrauensbeziehung und die zwischen ihnen verwendeten Zugangsdaten bewerten.
Das Netzwerkdesign kann die Folgen erheblich verändern. Ein Gateway, das nur einen Modellserver und eng definierte GitLab-Endpunkte erreichen kann, bietet weniger Möglichkeiten als eines mit breitem Zugriff auf interne Netzwerke. Beschränkungen des ausgehenden Datenverkehrs, Workload-Identitäten, schreibgeschützte Dateisysteme und minimale Container-Berechtigungen bleiben sinnvolle Kontrollen.
Netzwerkisolation sollte das Patchen jedoch ergänzen und nicht ersetzen. Ein anfälliger interner Dienst kann von einem anderen kompromittierten internen Konto oder Workload aus angegriffen werden. Segmentierung begrenzt Bewegungen und Datenzugriff, behebt jedoch keine unsichere Template-Verarbeitung.
Betreiber sollten auch die Daten berücksichtigen, die das Gateway durchlaufen. Self-Hosting wird oft genau deshalb gewählt, weil Prompts proprietären Quellcode, Issue-Kontext oder interne Anweisungen enthalten können. Falls eine Ausnutzung stattgefunden hat, müssen Ermittler feststellen, auf welche Informationen das Gateway zugreifen konnte, und nicht nur, welche Dateien sich in seinem Container befanden.
Diese Arbeit gehört in dieselbe operative Kategorie wie der Schutz von CI-Runnern, Artefakt-Repositories und Secret-Managern. All diese Dienste übersetzen von Entwicklern kontrollierte Eingaben in automatisierte Aktionen. Ihr Nutzen beruht auf privilegierter Konnektivität, weshalb ihre Isolation und ihr Aktualisierungsrhythmus wichtig sind.
Die Lehre lautet nicht, dass verwaltete KI-Infrastruktur immer sicherer ist. Verwaltete Dienste bündeln die Verantwortung beim Anbieter und reduzieren den Patch-Aufwand der Kunden, doch Kunden akzeptieren andere Kompromisse bei Vertrauen, Datenresidenz und Abhängigkeiten. Die Lehre ist, dass Self-Hosting verändert, wer reagieren muss, wenn ein kritischer Gateway-Fehler auftritt.
Ein früherer Fehler mit CVSS 9,9 macht dies zu mehr als einem einmaligen Patch
CVE-2026-90970 ist das zweite öffentlich dokumentierte GitLab AI Gateway-Template-Problem mit einer Bewertung von 9,9 im Jahr 2026 und stärkt damit die Argumente für eine architektonische Überprüfung.
Im Februar 2026 behob GitLab CVE-2026-1868 in der Komponente Duo Workflow Service des AI Gateway. GitLabs öffentliche CVE-Zuweisung beschreibt eine unsichere Template-Expansion nutzerbereitgestellter Daten durch präparierte Flow-Definitionen der Duo Agent Platform.
Die frühere Schwachstelle hatte denselben CVSS-3.1-Vektor und denselben Schweregrad von 9,9. Zu den korrigierten Releases gehörten die AI-Gateway-Versionen 18.6.2, 18.7.1 und 18.8.1. GitLab schrieb die Entdeckung dieses Fehlers einem internen Teammitglied zu.
Die neue Schwachstelle betrifft laut aktuellem Eintrag spätere Release-Linien ab Version 18.1.6 bis hinein in die 19.4-Serie. Öffentliche Beschreibungen beider Probleme beziehen sich auf präparierte Flow-Definitionen oder Konfigurationen, Template-Verarbeitung, authentifizierten Zugriff mit geringen Berechtigungen und mögliche Befehlsausführung.
Diese Ähnlichkeit beweist nicht, dass die Patches auf dieselbe Weise versagten. Öffentliche Schwachstellenzusammenfassungen sind zu begrenzt, um festzustellen, ob CVE-2026-90970 eine Regression, eine unvollständige frühere Behebung oder einen eigenständigen unsicheren Template-Pfad darstellt. Diese Möglichkeiten als bestätigt zu behandeln, würde die Beweislage überdehnen.
Dennoch sollten Verteidiger die Offenlegung im Oktober nicht isoliert bewerten. Zwei kritische Befunde an derselben breiten Vertrauensgrenze deuten darauf hin, dass die Verarbeitung von Flow-Konfigurationen eingehender getestet werden sollte. Ein einzeiliges Versionsupgrade kann den offengelegten Pfad schließen, während umfassendere Designfragen unbeantwortet bleiben.
Der Hauptkonflikt dieser Geschichte liegt zwischen dem Governance-Versprechen der Plattform und der Realität einer ausführbaren Konfigurationsoberfläche. GitLab positioniert agentische Flows als kontrollierte Automatisierungen, die innerhalb etablierter Entwicklungsprozesse arbeiten. Diese Kontrollen verlieren an Wert, wenn autorisierte Flow-Autoren zu Befehlen auf Gateway-Ebene übergehen können.
Das Problem ist nicht auf GitLabs Produktkategorie beschränkt. KI-Gateways, Agent-Orchestratoren und Workflow-Engines übersetzen alle flexible Nutzereingaben in privilegierte Operationen. Ihre Konfigurationsformate können zu Programmiersprachen werden, selbst wenn Produktoberflächen sie als deklarative Dateien darstellen.
Diese Flexibilität schafft einen wiederkehrenden Sicherheitskompromiss. Kunden wollen anpassbare Agenten, die Repositories untersuchen, Tools aufrufen, auf Ereignisse reagieren und mehrstufige Ziele erfüllen können. Jedes neue Tool, jeder Ausdruck, jede Template-Variable oder jedes Plugin erweitert, was die Orchestrierungsschicht sicher interpretieren muss.
Eine strikte Konfigurationssprache kann Risiken reduzieren, begrenzt aber die Anpassungsmöglichkeiten der Kunden. Eine flexible Sprache unterstützt mehr Workflows, erfordert jedoch ausgereiftes Sandboxing, Parser-Kontrollen, Berechtigungsgrenzen und Sicherheitstests. Das Risiko steigt, wenn ein einzelner Prozess sowohl nicht vertrauenswürdige Templates rendert als auch über wertvollen Infrastrukturzugriff verfügt.
Die Verteidigung benötigt daher mehrere unabhängige Ebenen. Der Parser sollte nicht vertrauenswürdige Werte als Daten behandeln. Die Template-Umgebung sollte die kleinstmögliche Objektmenge bereitstellen. Die Autorisierung sollte beschränken, wer Flows einreichen darf. Die Gateway-Laufzeit sollte nur minimalen Zugriff auf Dateisystem, Netzwerk und Zugangsdaten haben.
Auditierbarkeit bietet eine weitere Ebene. Ereignisse zur Erstellung und Änderung von Flows sollten bestimmten menschlichen oder Dienstidentitäten zugeordnet werden können. Organisationen sollten eine eingereichte Konfiguration mit nachfolgender Gateway-Aktivität verbinden können. Ohne diese Kette wird die Bestätigung oder der Ausschluss einer Ausnutzung erheblich schwieriger.
Die frühere Schwachstelle verändert auch die Art, wie Teams die Upgrade-Verifizierung handhaben sollten. Es reicht nicht aus, festzustellen, dass das aktuellste korrigierte Image erfolgreich gestartet ist. Betreiber sollten bestätigen, dass alte Replikate, zwischengespeicherte Images, Testcluster und Disaster-Recovery-Umgebungen keine betroffenen Versionen behalten.
Getrennte Umgebungen können besonders trügerisch sein. Ihr fehlender allgemeiner Internetzugang reduziert einige externe Bedrohungen, kann jedoch die Zustellung von Sicherheitsmeldungen und Patches verzögern. Ein autorisierter Nutzer innerhalb dieser Umgebung kann weiterhin die für die Schwachstelle erforderliche Anwendungsfunktionalität erreichen.
Eine skeptische Bewertung muss auch anerkennen, was unbekannt bleibt. Öffentliche Einträge liefern bislang weder einen Proof of Concept noch einen detaillierten Aufrufpfad oder bestätigte Telemetrie zu Ausnutzungen. Sie identifizieren keine universelle Menge an Indikatoren nach einer Ausnutzung für jede Bereitstellung.
Diese Lücken beschränken belastbare Aussagen über beobachtete Angriffe, schwächen jedoch nicht die Patch-Empfehlung. Ein vom Anbieter bestätigter Fehler zur Befehlsausführung mit einer Bewertung von 9,9 stellt genug Risiko dar, um eine sofortige Behebung zu rechtfertigen. Auf öffentliche Belege für eine Ausnutzung zu warten, würde Unsicherheit gegen vermeidbare Exposition eintauschen.
Die stärkere langfristige Frage lautet, ob Template-Verarbeitung in ihrem aktuellen Vertrauenskontext weiterhin notwendig ist. GitLab kann zukünftige Risiken verringern, indem es mehr technische Details veröffentlicht, nachdem Kunden Zeit zum Patchen hatten. Informationen zur Grundursache würden Betreibern helfen zu verstehen, welche Grenzen versagt haben und welche kompensierenden Kontrollen am wichtigsten sind.
Kunden sollten benutzerdefinierte Agent-Flows derweil wie Code behandeln. Sie verdienen Überprüfung, Verantwortlichkeit, Change Control und Tests, die mit CI-Konfiguration vergleichbar sind. Eine visuelle oder deklarative Oberfläche macht einen Workflow nicht nicht ausführbar, wenn die Plattform seinen Inhalt in Aktionen umsetzt.
Worauf Verteidiger als Nächstes achten sollten
Die nächste Bewertung sollte von drei Signalen abhängen: Patch-Adoption, GitLabs Offenlegung der Grundursache und Belegen für eine Ausnutzung in der Praxis.
Das erste Signal ist, ob selbst gehostete Betreiber rasch korrigierte AI-Gateway-Versionen erreichen. GitLab kontrolliert seinen gehosteten Dienst, kann jedoch nicht jede Kundenbereitstellung innerhalb privater Infrastruktur messen. Sicherheitsteams sollten eigene Abschlussnachweise etablieren, statt anzunehmen, dass die übliche Berichterstattung über Softwareupdates das Gateway einschließt.
Diese Nachweise sollten die Bereitstellung, die vorherige Version, das Ersatz-Image, den Neustartzeitpunkt und das Validierungsergebnis identifizieren. Sie sollten auch Entwicklungs- und Disaster-Recovery-Systeme abdecken. Wenn Organisationen Schwierigkeiten haben, dieses Inventar zu erstellen, offenbart der Vorfall ein Verantwortungsproblem, das über die Schwachstelle selbst hinausgeht.
Eine schnelle Patch-Adoption würde die Annahme stärken, dass Unternehmen selbst gehostete KI-Komponenten wie herkömmliche Produktionsinfrastruktur verwalten können. Eine langsame oder nicht gemessene Adoption würde das Kontrollargument hinter privater Bereitstellung schwächen. Datenlokalität bietet begrenzten Schutz, wenn kritische Middleware unnachverfolgt bleibt.
Das zweite Signal ist eine umfassendere technische Erklärung von GitLab. Verteidiger müssen wissen, ob CVE-2026-90970 einen neuen Template-Pfad, eine Regression oder eine unvollständige Abschwächung des früheren Fehlers darstellt. Diese Unterscheidung beeinflusst das Vertrauen in die umgebende Architektur und Teststrategie.
Eine hilfreiche Offenlegung würde die betroffene Komponente, die berührte Privilegiengrenze und die Änderungen zur Eindämmung erklären, ohne unnötige Exploit-Details preiszugeben. Sie sollte außerdem klarstellen, ob die getrennten Dienste Agent Platform und AI Gateway unterschiedliche Maßnahmen nach dem Vorfall erfordern.
Die Bestätigung einer eigenständigen Ursache würde darauf hindeuten, dass eine breit angelegte Härtung von Vorlagen über mehrere Erkenntnisse hinweg wirkt. Hinweise auf eine Umgehung einer früheren Gegenmaßnahme würden dagegen schärfere Fragen dazu aufwerfen, ob die ursprüngliche Sicherheitsgrenze umfassend konzipiert war.
Das dritte Signal sind glaubwürdige Belege für eine Ausnutzung. GitLab und Sicherheitsbehörden sollten auf Kompromittierungsindikatoren, Listen bekannter aktiv ausgenutzter Schwachstellen oder aktualisierte Reaktionsleitlinien beobachtet werden. Unabhängige Vorfallberichte wären ebenfalls relevant, sofern sie überprüfbare Telemetriedaten enthalten.
Bis solche Belege vorliegen, sollten Artikel CVE-2026-90970 nicht als aktiv ausgenutzt bezeichnen. Das Fehlen öffentlicher Bestätigung ist nicht gleichbedeutend mit der Bestätigung, dass keine Ausnutzung stattgefunden hat. Organisationen müssen ihre Reaktionsentscheidungen anhand von Exposition und Auswirkungen treffen, nicht allein anhand von Schlagzeilen.
Teams können mit vier praktischen Fragen beginnen. Betreiben wir ein selbstgehostetes AI Gateway? Laufen alle Instanzen mit 19.2.4, 19.3.2, 19.4.1 oder neuer? Wer konnte im betroffenen Zeitraum Duo-Agentenabläufe ändern? Auf welche Systeme und Geheimnisse konnte das Gateway zugreifen?
Die Antworten sollten zusammen mit Vorfallakten, Konfigurationshistorien und relevanten Logs aufbewahrt werden. Teams, die Bereitstellungsnotizen, Verantwortungsentscheidungen und Prüfnachweise miteinander verknüpfen müssen, können eine durchsuchbare Wissensdatenbank pflegen. Dokumentation behebt die Schwachstelle nicht, doch fragmentierte Nachweise können die Eindämmung und spätere Audits verzögern.
Die Schwachstelle im GitLab AI Gateway prüft letztlich, ob Agenteninfrastruktur mit derselben operativen Disziplin behandelt wird wie CI-Systeme und andere Dienste zur Codeausführung. Patchen Sie das betroffene Gateway, verifizieren Sie das laufende Image, prüfen Sie autorisierte Änderungen an Abläufen, rotieren Sie exponierte Zugangsdaten, wenn die Belege dies rechtfertigen, und reduzieren Sie die Berechtigungen des Gateways.
Stellen Sie dann die schwierigere Frage: Falls eine weitere Agentenkonfiguration im nächsten Monat eine Vertrauensgrenze überschreitet, kann Ihr Team den Verantwortlichen, die betroffenen Versionen, erreichbare Assets und den Reaktionsweg identifizieren, ohne das Inventar erst während des Vorfalls neu aufbauen zu müssen?
