GitLab disclosed and patched CVE-2026-90970 on October 2, a critical (CVSS 3.1: 9.9) flaw in the self-hosted GitLab AI Gateway, the service that brokers GitLab Duo AI features to model backends. An authenticated user with access to the Duo Agent Platform can supply a crafted custom-flow configuration, escape the prompt template sandbox, and execute arbitrary commands on the gateway host. No in-the-wild exploitation is known and no public proof of concept has been published at the time of writing.

What happened

The AI Gateway renders prompt templates for custom flows, user-defined agent workflows in the Duo Agent Platform. Input in those flow definitions is not sufficiently neutralized before it is evaluated by the template engine. Public write-ups describe this as a Jinja2 server-side template injection: a flow configuration carrying a crafted template expression breaks out of the intended sandbox and reaches Python internals, which yields command execution in the context of the gateway process.

The CVSS 9.9 score reflects a scope change: the gateway sits between the GitLab instance, model providers, and the data they exchange. A compromised gateway process can see prompts, source code snippets, and merge request or CI context sent to the model, plus whatever API keys and service credentials it holds for upstream model providers.

Affected versions

Self-hosted AI Gateway:

  • 18.1.6 through 19.2.3
  • 19.3.0 and 19.3.1
  • 19.4.0

Fixed in 19.2.4, 19.3.2, and 19.4.1. GitLab-hosted AI Gateways were patched by the vendor and need no action.

Attack requirements and impact

The attacker needs an authenticated account with access to the Duo Agent Platform. That lowers the bar compared with an unauthenticated bug, but in many organizations Duo access is granted broadly to developers, and a stolen developer token, a compromised contractor account, or a malicious insider is enough. Once code execution is achieved on the gateway, expect:

  • Theft of model-provider API keys and gateway configuration secrets
  • Access to prompts and code context from all users routed through the gateway
  • A pivot into whatever network segment the gateway shares with GitLab, runners, or internal model endpoints
  • Persistence on a host that is often treated as low-risk “AI plumbing” and monitored less than the GitLab core

Mitigation

GitLab states there is no workaround for self-hosted deployments. Patching is the only fix.

  1. Upgrade self-hosted AI Gateway to 19.2.4, 19.3.2, or 19.4.1 or later. Container deployments should pull the new image tag and redeploy rather than patching in place.
  2. Until patched, restrict Duo Agent Platform access to the smallest set of users that need it, and disable custom flows where the feature is not in use.
  3. Review who can create or edit custom flow configurations and audit recent flow definitions for unusual template expressions (double braces containing attribute chains such as __class__, __globals__, __subclasses__, or calls to os or subprocess).
  4. Rotate model-provider API keys and any secrets mounted into the gateway if you find suspicious flows or cannot rule out misuse.
  5. Isolate the gateway: run it as a non-root user with a read-only filesystem, drop capabilities, and apply egress filtering so it can reach only the GitLab instance and approved model endpoints.
  6. Hunt for child processes spawned by the gateway’s Python process (shells, curl, wget) and unexpected outbound connections from the host.

Why it matters

This is the same bug class that has repeatedly hit LLM orchestration tooling: user-controlled template or expression languages evaluated server-side with a sandbox that is trusted to hold. Jinja2’s sandbox is a defense-in-depth layer, not a boundary you should rely on when the input is attacker-influenced. Teams deploying self-hosted AI gateways, agent runtimes, and workflow engines should treat them as code-execution surfaces, give them the same network segmentation and secrets hygiene as CI runners, and keep them on the patch cadence of the primary platform.

References