GitLab AI Gateway Sandbox Escape Vulnerability: Command Execution Risk for Self-Hosted Instances

GitLab has patched a critical security vulnerability tracked as CVE-2026-90970, carrying a CVSS score of 9.9. The flaw exists in the GitLab AI Gateway component and allows authenticated users with access to the Duo Agent Platform to escape the prompt template sandbox through a specially crafted flow configuration, ultimately achieving arbitrary command execution on the gateway.

This vulnerability deserves close attention from enterprise security teams — not only because of its near-perfect CVSS score, but because it exposes a growing problem: as development platforms continue integrating AI capabilities, those AI components are becoming attractive targets for attackers, often before enterprise asset inventories have caught up.

What CVE-2026-90970 Actually Allows

GitLab's official description of the vulnerability is concise and precise, worth parsing carefully: under certain conditions, it "may allow an authenticated user with access to the Duo Agent Platform to escape the prompt template sandbox through a crafted flow configuration, allowing arbitrary command execution on the AI Gateway."

Reading that description closely sketches the full picture. The attacker must be an authenticated user — no anonymous requests involved. What gets manipulated is the flow configuration, a normal user-facing construct within the Duo Agent Platform. Prompt templates and multi-step flows are things developers are explicitly expected to write. The sandbox surrounding those templates is the control mechanism meant to keep executed flows within their intended process boundary — and this flaw lets a carefully crafted configuration break through that boundary.

The severity assessment aligns with that reading. A CVSS score of 9.9 with a "scope change" means the impact escapes the security boundary of the affected component rather than staying contained, with high impact across confidentiality, integrity, and availability. The vulnerability was responsibly disclosed by a HackerOne researcher.

A note on CVSS scoring: The Common Vulnerability Scoring System is an industry-standard framework for rating vulnerability severity on a scale of 0 to 10. Scores are determined by a set of base metrics including attack vector (local/adjacent/network), attack complexity, required privilege level, user interaction requirements, and impact on confidentiality, integrity, and availability. "Scope Change" is a key indicator signifying that the vulnerability's impact can cross the security boundary of the affected component and reach other security domains — for example, escaping from the application layer to the operating system layer. Because scope change significantly amplifies real-world impact, it tends to push scores toward the high end. CVE-2026-90970's 9.9 score reflects the compounding effect of several high-risk factors: network-reachable, triggerable by a low-privilege authenticated user, with spillover impact beyond the affected component.

Why the AI Gateway Holds Privileged Credentials

A gateway sitting between a development platform and one or more model providers is not a simple traffic forwarder. It is a service that holds credentials for those providers and terminates requests from the platform. In self-hosted deployments, it controls the entire inference path — no prompt, code input, or model response leaves the customer's network, which is precisely why enterprises choose self-hosting in the first place.

What Command Execution Actually Means

That design decision is what makes this vulnerability's significance exceed its CVSS number. Executing commands on the gateway means executing them inside the component that holds every model key the platform connects to, and inside the component that sees every prompt and every response. The "scope change" is, in other words, a description of the blast radius that security teams would be forced to define after a successful exploit.

GitLab's documentation clearly distinguishes between several deployment options. A self-hosted AI Gateway using self-hosted models runs entirely within customer infrastructure, with full control over the AI path. Hybrid configurations combine a self-hosted gateway with GitLab-managed models on a per-feature basis. The GitLab.com AI Gateway using vendor models requires no additional infrastructure at all. Each option carries its own maintenance obligations, and only the first two place gateway versioning under the customer's own change management.

What is the GitLab Duo Agent Platform? GitLab Duo Agent Platform is GitLab's built-in AI-assisted development feature set, allowing users to define multi-step automated flows that orchestrate tasks like code review, test generation, and documentation writing into repeatable agent workflows. Prompt templates are the core building blocks of these flows — developers define agent behavior instructions in templates, and the platform substitutes variables at runtime before sending them to the model. The sandbox mechanism exists to isolate the rendering and execution environment for templates, preventing template content from accessing underlying system resources outside its permitted scope. What CVE-2026-90970 reveals is a flaw in that isolation boundary: a carefully crafted flow configuration can deceive the sandbox into executing OS-level commands that should never have been permitted.

Which Instances Are Affected and Which Are Safe

The affected version range spans AI Gateway 18.1.6 through 19.2.3, 19.3.0 through 19.3.1, and 19.4.0. The corresponding fixed versions are 19.2.4, 19.3.2, and 19.4.1.

The critical dividing line is how the gateway is hosted. GitLab-hosted AI Gateways were patched before the release notes were published, so GitLab.com, GitLab Dedicated, and self-managed instances using the GitLab-hosted AI Gateway require no action. The real exposure is concentrated among self-managed customers running their own self-hosted gateways.

Two easy-to-miss consequences follow from this. First, upgrading the GitLab application itself does not necessarily update the AI Gateway, since the two have independent release lines — the fix versions are named in gateway version numbers, not application version numbers. Second, an asset inventory that lists "GitLab" as a single entry obscures the component that actually matters here. If the gateway runs as a container or service alongside your already-patched application, it needs its own entry, its own version field, and its own upgrade owner.

Remediation Sequence for Self-Managed Gateways

The first remediation step is identification, because it determines whether any subsequent work applies. Locate every instance running a self-hosted AI Gateway, record the version number, and confirm whether any features are routed to a GitLab-managed gateway — GitLab's documentation describes a hybrid mode in which certain features use managed models, and those features are entirely outside your gateway's scope.

Then upgrade affected gateways to the fixed versions along the branch that matches your deployment. GitLab's guidance recommends immediate updates and notes that self-managed customers were notified before the public release, so teams following vendor notification processes may already be aware.

From there, treat the gateway as a privileged component in your own documentation. Rotate any provider credentials the gateway holds if you cannot confirm the upgrade landed promptly; bring gateway logs into your monitoring visibility; and add a version check to whatever monthly asset inventory report your team produces. A gateway that does not appear on any inventory will silently fail the same check after every patch cycle.

What Self-Hosted AI Platforms Add to the Attack Surface

Consider a concrete scenario (noted as hypothetical): a 30-person product team migrates Duo to a self-hosted AI Gateway for data residency reasons — code and prompts must stay within EU infrastructure, and the gateway is the component that makes that possible. There is nothing wrong with that deployment decision. What changes is the asset inventory: a service that did not exist in the patching calendar a year ago now sits on the path of every code suggestion, holds credentials for the model backend, and has its own independent release line.

That last point generalizes to every AI component modern development platforms now ship. Inference gateways, retrieval indexes, vector databases, agent runtimes — each is a distinct service with its own versioning, its own credential set, and its own CVE feed. Treating them as features of the platform they connect to is exactly what turns a seemingly reasonable upgrade story into "patched application running alongside an unpatched gateway." Detecting that state is a monitoring problem, not a scanning problem.

This broader pattern connects directly to the risks facing AI-assisted coding supply chains: as development platforms absorb AI capabilities, those AI components become part of what attackers probe, because they are newer than the surrounding application and hold credentials the application itself never needed. The fix for this particular vulnerability is available and straightforward to verify. The real remaining work is making sure your team knows the gateway exists.

On vector databases and agent runtimes: Vector databases and retrieval indexes are foundational components in modern AI applications, especially those built on the RAG (Retrieval-Augmented Generation) architecture. In a RAG setup, the system first retrieves document chunks semantically similar to a user's query from a vector database, then sends those chunks along with the user input to a large language model, enabling the model to answer based on private knowledge bases. In development platform contexts, those knowledge bases often contain highly sensitive internal assets — code repositories, internal documentation, and historical issues. Agent runtimes are execution environments responsible for scheduling and executing multi-step agent tasks, typically holding permissions to invoke external tools and APIs. Like the AI Gateway, these components each have independent versioning, independent credential sets, and independent security advisory feeds — yet they are frequently misclassified as platform features rather than as distinct attack surfaces in their own right.