GitLab AI Gateway Has a 9.9 Sandbox Escape — Your AI Agent Can Become the
- The Mess: GitLab patched a critical flaw in its self-hosted AI Gateway that could let an authenticated user escape the prompt-template sandbox through a crafted flow configuration and execute arbitrary commands on the gateway.
- The Damage: A compromised AI Gateway can turn an AI automation layer into a direct command-execution point inside the infrastructure running it.
- The Fix: Upgrade self-hosted GitLab AI Gateway to 19.2.4, 19.3.2 or 19.4.1 immediately if running an affected version.
AI security usually gets reduced to prompt injection, malicious instructions and poisoned models.
That is only one part of the problem.
GitLab’s latest AI Gateway vulnerability shows another attack surface: the infrastructure executing the AI workflow itself.
CVE-2026-90970 affects the GitLab Self-Hosted AI Gateway and has a CVSS 9.9 Critical rating. Under certain conditions, an authenticated user with access to the Duo Agent Platform could escape the prompt-template sandbox using a specially crafted flow configuration.
The result can be arbitrary command execution on the AI Gateway.
That’s not a theoretical concern about an AI model saying something it shouldn’t.
That’s code execution.
The attack starts with an authenticated user
There is an important limitation.
This isn’t an unauthenticated remote RCE.
The attacker needs authenticated access and access to the Duo Agent Platform.
But once those conditions are met, GitLab says a specially crafted flow configuration can break out of the prompt-template sandbox.
That distinction matters.
The security boundary isn’t simply:
user → AI prompt
It becomes:
user → agent flow → template sandbox → AI Gateway → operating system
Break the sandbox, and the attacker crosses from manipulating an AI workflow into executing commands on the underlying gateway.
What GitLab actually fixed
GitLab describes the vulnerability as an Improper Neutralization issue in a custom flow prompt template.
Affected AI Gateway versions include:
- versions from 18.1.6 before 19.2.4
- 19.3 before 19.3.2
- 19.4 before 19.4.1
GitLab released:
- 19.2.4
- 19.3.2
- 19.4.1
as fixed versions.
GitLab also says the fix has already been deployed to its hosted AI Gateway.
That means GitLab.com, GitLab Dedicated and self-managed installations using the GitLab-hosted AI Gateway are protected from this specific issue without the customer needing to patch a self-hosted gateway.
The people who need to care immediately are organizations running their own AI Gateway.
Why the sandbox matters
A sandbox exists to contain something that shouldn’t have unrestricted access to the host.
In this case, the relevant object is the prompt-template processing used by custom AI flows.
If an attacker can manipulate that processing and escape its intended boundary, the AI layer becomes a bridge to the host environment.
That changes the security model completely.
The interesting question is no longer:
“Can the AI agent be tricked?”
It becomes:
“What can the agent execute if its sandbox is gone?”
That depends on how the AI Gateway is deployed.
A gateway running with excessive privileges, broad network access, mounted credentials or access to internal services gives an attacker a much larger playground.
The self-hosted problem
GitLab’s AI Gateway is a standalone service used to provide AI-native GitLab Duo features. Organizations can deploy their own AI Gateway alongside GitLab Self-Managed.
That creates another security boundary administrators need to think about.
The AI Gateway is not just a user interface.
It is infrastructure.
And infrastructure running AI workloads deserves the same hardening applied to other services that can execute code.
That means:
- minimal container privileges,
- restricted network access,
- minimal credentials,
- controlled access to internal services,
- monitored outbound connections,
- isolated runtime environments,
- current security patches.
A vulnerability like CVE-2026-90970 makes those controls much more important.
Don’t confuse this with GitLab.com
This is where administrators can easily waste time.
If the organization uses GitLab.com and the GitLab-hosted AI Gateway, this specific self-hosted gateway patch is not something administrators need to deploy themselves.
GitLab says the hosted gateway has already received the fix.
But if the organization operates a GitLab Self-Hosted AI Gateway, the situation is different.
Check the version.
Then patch.
GitLab explicitly recommends upgrading affected installations immediately.
AI agents are becoming infrastructure
This vulnerability also points at a broader problem.
AI agents increasingly execute workflows rather than simply generate text.
They interact with:
- source repositories,
- CI/CD systems,
- APIs,
- databases,
- cloud services,
- files,
- shell commands,
- deployment environments.
Every new capability adds another security boundary.
The AI model doesn’t need to be compromised for the infrastructure around it to become the target.
A vulnerable template processor is enough.
A weak sandbox is enough.
An overprivileged container is enough.
And once those boundaries fail, the “AI feature” starts looking a lot like another remote code execution surface.
What administrators should do
For organizations running GitLab Self-Hosted AI Gateway:
- Check the installed AI Gateway version.
- Determine whether it falls into the affected ranges.
- Upgrade to 19.2.4, 19.3.2 or 19.4.1, depending on the deployment branch.
- Review who has access to Duo Agent Platform functionality.
- Review custom flow configurations.
- Check gateway logs for unexpected command execution or abnormal activity.
- Review outbound connections from the gateway.
- Verify that the gateway does not have unnecessary credentials or network privileges.
- If compromise is suspected, preserve logs and investigate the host before simply rebuilding it.
GitLab’s installation documentation also recommends keeping the AI Gateway container image current and paying attention to image update behavior in Kubernetes and Helm deployments, where IfNotPresent can prevent an updated image from being pulled when the tag hasn’t changed.
The uncomfortable part
The security industry spent years talking about isolating untrusted code from the host.
Now AI agents are bringing another category of untrusted input into the same problem.
A prompt can influence an agent.
A flow configuration can influence how that agent operates.
A vulnerable sandbox can turn that influence into code execution.
That’s why AI security cannot stop at model behavior.
The runtime is part of the attack surface.
Bugstoday opinion: CVE-2026-90970 is exactly the kind of AI vulnerability defenders should take seriously: no sci-fi scenario, no magical “AI hacked itself” nonsense — just a security boundary around an AI workflow that could be escaped and turned into command execution. If you’re running the self-hosted gateway, patch it and then ask the uncomfortable question: what else can that gateway reach?
Technical Sources
- GitLab — Critical Patch Release: GitLab AI Gateway 19.2.4, 19.3.2 and 19.4.1
- GitLab — CVE-2026-90970
- GitLab Documentation — AI Gateway
- GitLab Documentation — Install the GitLab AI Gateway
- CVE.org — CVE-2026-90970
