GitLab's AI Gateway flaw: when the sandbox around an AI feature turns out to be the weak point

TechScripts Nepal · Kathmandu · October 26, 2026 · 6 min read

On October 2, 2026, GitLab patched CVE-2026-90970, a critical flaw in its self-hosted AI Gateway. The score is 9.9 out of 10, close to the maximum. The short version: a logged-in user with access to GitLab's Duo Agent Platform could craft a flow configuration that broke out of a sandbox meant to contain AI prompt templates, and run arbitrary commands on the machine hosting the gateway.

It isn't the biggest vulnerability of the month, but it's a revealing one. As more companies bolt AI features onto existing infrastructure, the components that connect those features to models and internal systems are becoming privileged, high-value targets. This flaw is a clean example of why.

What the AI Gateway is

GitLab's AI Gateway is the service that connects GitLab's AI features and agentic workflows to language models. In a self-hosted deployment, you run it yourself, and its runtime environment may be able to reach internal services, credentials, mounted files, and model provider resources. That reach is what makes it useful, and what makes a bug in it dangerous.

The Duo Agent Platform is the set of agent features that rely on it. Users who have access to those features can define flows, which are configurations describing how an agent should behave.

What the bug is

According to GitLab's description and security vendor analysis (including SOCRadar), an authenticated user with Duo Agent Platform access could submit a specially crafted flow configuration that escaped the prompt-template sandbox. The flaw is classified as a template engine neutralization issue (CWE-1336), which is the family of bugs usually called template injection: user-influenced text is processed by a template engine in a way that lets it do more than just fill in blanks.

The pattern is old; the setting is new. Template engines have turned user-controlled strings into code execution for years, and sandboxes meant to prevent that have a long history of being escaped. What changes with AI features is that "flow configurations" and "prompt templates" now look like harmless configuration, so they tend to be treated with less suspicion than code would be.

GitLab has not disclosed the exact payload or code path, and public descriptions don't spell out the conditions that make the escape possible. So the precise exposure of a given deployment isn't fully knowable from outside.

Why the score is so high

CVSS 3.1 vector, as published by SOCRadar: network-reachable, low attack complexity, low privileges required, no user interaction, scope changed, and high impact on confidentiality, integrity, and availability.

Two parts of that are worth reading carefully. "Low privileges" means an ordinary authenticated user with the right feature access, not an administrator. And "scope changed" means the impact extends beyond the vulnerable component itself. A command running on the gateway host can reach whatever the gateway can reach, which, as above, may include credentials and internal services. That is why a bug that needs a login still scores 9.9.

Who is affected

Only self-hosted AI Gateway deployments need action. GitLab says it already fixed GitLab-hosted gateways, so GitLab.com, GitLab Dedicated, and Self-Managed instances that use a GitLab-hosted gateway are protected.

For self-hosted gateways:

• Affected: 18.1.6 up to (but not including) 19.2.4; 19.3 before 19.3.2; 19.4 before 19.4.1.
• Fixed in: 19.2.4, 19.3.2, and 19.4.1.
• GitLab lists no patched build for the 18.x, 19.0, or 19.1 branches, so those need to move to one of the fixed releases.

A practical trap: check the AI Gateway's container image or Helm deployment separately from your main GitLab version. The gateway is its own deployment, and it's easy to assume it was upgraded along with everything else.

The Hacker News reports this is the second AI Gateway template-related flaw rated 9.9 this year, following CVE-2026-1868 in February. If that's accurate, it suggests the sandbox design has been under sustained scrutiny rather than a one-off lapse.

Exploitation status

At the time of the early reporting (around October 5), there were no confirmed attacks and the flaw was not in CISA's Known Exploited Vulnerabilities catalog. That reporting is about three weeks old, so check CISA's catalog and GitLab's advisory for the current picture before relying on it.

What to do

1. Upgrade self-hosted gateways to 19.2.4, 19.3.2, 19.4.1, or later, and verify the deployed image or Helm tag after the change.
2. Limit who can use Duo Agent Platform and write custom flows. The attacker needs that access. Grant it to people who need it, and review recently created accounts and recent flow changes.
3. Restrict the gateway's network access to the GitLab services, model providers, and admin networks it actually needs. This reduces the damage if something goes wrong; it doesn't replace patching.
4. Review what the gateway can reach. List the tokens, credentials, and mounted files available to it. If you suspect compromise, rotate those after investigating.
5. Hunt for odd behavior, as SOCRadar suggests: unexpected changes to flows or templates, unusual Duo activity, unexpected child processes, shells, or interpreters on the gateway host, and unusual outbound connections. No flaw-specific indicators have been published, so this is general guidance.

The wider lesson

Three themes from our recent coverage meet in this one flaw.

First, AI components are infrastructure, and should be secured like infrastructure. The gateway is a service with network access and credentials, not a feature toggle. The questions we raised about Google's enterprise agent platform, such as what an agent can touch and who can configure it, apply equally to the plumbing underneath.

Second, user-supplied configuration is code. A flow definition that gets interpreted by a template engine deserves the same scrutiny as a script, including who can write one and what it can reach if the sandbox fails.

Third, a sandbox is a layer, not a guarantee. The Gemini test that escaped its environment and this flaw both show what happens when everything depends on one boundary holding. Defense in depth, meaning least-privilege credentials, network limits, and monitoring, is what keeps a failed sandbox from becoming a breach.

If your team is rolling out AI features faster than it can review how they're wired into your systems, that's a good moment to bring someone in who has done it before. Reviewing how AI components are isolated and scoped, or embedding an engineer for the rollout itself, is the kind of work our technical-partner and forward-deployed engineering services are set up for.