GitLab AI Gateway CVE-2026-90970: Patch Critical Duo Sandbox Escape RCE

What GitLab says happened​

BleepingComputer reports that GitLab's advisory describes an issue where, under certain conditions, an authenticated user with Duo Agent Platform access could escape the prompt template sandbox through a specially crafted flow configuration. The result is arbitrary command execution on the AI Gateway itself.

The CVE record gives the weakness as CWE-1336, improper neutralization of special elements used in a template engine. One security-feed site (TheHackerWire) labels it server-side template injection. That label is the site's own interpretation. It is a reasonable shorthand for the class of bug: attacker-controlled template content gets evaluated in a way the sandbox was supposed to prevent.

Severity at a glance​

The vector explains the score. It means network-reachable, low complexity, low privileges, no user interaction, and a changed scope with high impact on confidentiality, integrity and availability. The only real gate is a valid account with Duo Agent Platform access. In many organizations that group is broad.

Who needs to act​

The answer depends on how you run Duo. GitLab's documentation describes two setups for Self-Managed customers:

• GitLab.com AI Gateway (the default). Your instance sends requests to the GitLab-managed gateway, which talks to external AI vendors such as Google Vertex or Anthropic. GitLab says customers on a GitLab-hosted gateway are already protected and need to do nothing.
• Self-hosted AI Gateway. You deploy and manage the gateway and models in your own infrastructure. This is the group GitLab told to update immediately. It says it had already done targeted outreach to these customers before publishing.

Platform versions and gateway versions are separate things. GitLab's install documentation describes the AI Gateway as a combination of two services: the AI Gateway service and the GitLab Duo Agent Platform service, usually deployed as its own container or Helm release. Updating your GitLab CE/EE instance does not by itself update a separately deployed gateway. I could not find a GitLab statement on this specific point, so confirm it in your own environment.

What to do now​

1. Find out which setup you use. In Admin settings under GitLab Duo, check whether your instance points at a gateway URL you operate. If it uses the default GitLab-managed gateway, no action is needed per GitLab.
2. Inventory the gateway version separately. Look at the image tag or Helm chart deployment, not just the GitLab version.
3. Upgrade to a fixed release. Move to 19.2.4, 19.3.2, 19.4.1 or later on the branch you track. Confirm the artifact against GitLab's own release notes.
4. Watch for stale images. GitLab's docs warn that Helm chart versions before 0.7.0 default to a pull policy that won't fetch a changed image under an unchanged tag. If you pin by tag, make sure the new image was actually pulled. GitLab recommends using image digests.
5. Review who holds Duo Agent Platform access. This is general least-privilege advice, not a documented fix for this CVE. GitLab's agent security documentation also advises scoping agents narrowly and limiting tool access.

Hardening is not a substitute for patching​

GitLab's install guide recommends restricting the gateway container's outbound network access. Only your GitLab instance and your chosen model provider endpoints should be allowed. That is sound practice, and it could limit what an attacker does after getting code execution. The documentation does not claim it mitigates this flaw, and the CVE record says no additional mitigations are specified beyond applying the official patches. Treat egress filtering as damage control only.

What we don't know​

• Exploitation. The sources I reviewed show no sign of in-the-wild exploitation. Feed sites list it as not in the CISA KEV catalog with no public PoC detected. That was true at publication time and could change quickly, because the bug was disclosed only today.
• Indicators of compromise. I found no published guidance on how to detect past abuse. If you ran an affected gateway with broad Duo Agent Platform access, reviewing flow configurations and gateway host activity is reasonable, but that is general incident-response practice and not GitLab guidance.
• Version numbering. GitLab's main platform patch releases and these AI Gateway fix versions use similar numbers but are different artifacts. I could not retrieve GitLab's own advisory page. The affected ranges and fix versions come from BleepingComputer's report and match the CVE record mirrored by several feeds.

Why it matters​

This is the kind of bug that agentic AI features invite. A gateway that renders user-supplied flow definitions through a templating layer is, in effect, running semi-trusted input on a server that holds credentials for GitLab and model providers. The sandbox is the only thing between a low-privilege user and the host. Here it failed.

The caveat is that this is not a pre-authentication bug, and hosted customers are untouched. A cautious reading is that the practical risk is highest where many developers hold Duo Agent Platform access and the gateway sits on a network with broad reach. Even so, a 9.9 score on a service you host yourself is a prompt to patch, not to debate.

If you run a self-hosted AI Gateway, confirm your gateway version today and upgrade to 19.2.4, 19.3.2 or 19.4.1 or later. If you use GitLab's managed gateway, GitLab says you are already covered.