GitLab AI Gateway sandbox escape: what pentest actually catches

On October 2, GitLab fixed a flaw in its AI Gateway that let an authenticated user with access to the agent platform escape the prompt template sandbox and execute arbitrary commands on the server. CVSS 9.9, maximum severity. What interests me is not the number. It’s that the flaw was not a disobedient model, not a malicious prompt, not someone without credentials. It was someone with perfectly good credentials doing something they should not have, crossing a boundary nobody had tested. That is pentest work, and it is close to the only kind nobody is hiring for right now.

What you get out of this: why “prompt sandbox” is not a security control, and what to put in the test scope of any AI application before pentest becomes unfashionable.

What GitLab reported

According to GitLab’s own advisory, the flaw is CVE-2026-90970, titled “Improper Neutralization issue in custom flow prompt template impacts AI Gateway,” rated critical with a CVSS of 9.9.

The advisory text is precise, and it is worth reading closely, because it describes exactly the sort of thing most of the market still files under “AI vulnerability”: “under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway.”

In plain terms: an authenticated user with legitimate platform access supplied a flow configuration built for the purpose. The sandbox that was supposed to contain the prompt template did not contain it. What sat on the other side was not an inappropriate model response. It was command execution on the host.

Credit for the responsible report goes to invisiblemeerkat through HackerOne. GitLab says it contacted customers running their own instance directly, before publishing the advisory.

Fixed versions are 19.2.4, 19.3.2, and 19.4.1. Every version from 18.1.6 up to those releases is affected. Anyone on GitLab’s hosted AI Gateway, through GitLab.com, Dedicated, or Self-Managed, is already protected and needs to do nothing. If you run the self-hosted instance, that one is your problem.

One thing needs to be stated clearly, because this story will circulate badly: the advisory does not say this flaw was exploited. No active exploitation is declared. What exists is a critical vulnerability in a component millions of companies run in production.

The point nobody will write up: a prompt is not a boundary

There is a convenient belief in the market that an AI application stays secure because the model refuses malicious instructions. The belief is intuitive and wrong in exactly the place that matters.

A model is not an access control. A model is a component that produces text. What stops a user from doing something they should not is authorization, input validation, and a process boundary, tested with a valid credential.

CVE-2026-90970 is that proof in advisory form: the vector is a malformed flow configuration, the attacker is an authenticated user with platform access, and the outcome is a sandbox escape into command execution. None of that requires the model to be manipulated. The model was just there, doing its job, inside a structure everyone assumed was safe.

Teams running AI in production usually have two things: the app team tested the API with malformed input, and the security team tested the infrastructure. The middle layer, the one that decides what an authenticated user may do inside the AI flow, almost nobody looks at. That is precisely where GitLab was exposed.

GitLab’s company

Two serious issues in one month at the same vendor is not a coincidence. In September, GitLab patched CVE-2026-85706, a maximum-severity path traversal flaw that let unauthenticated attackers read credentials and other secrets from vulnerable servers. CISA added it to its known exploited vulnerabilities catalog and gave federal agencies three days to remediate, under directive BOD 26-04.

Since November 2021, CISA has tagged five GitLab vulnerabilities as exploited, according to BleepingComputer, one of them by ransomware groups.

Two serious flaws in the same product, inside a month, one of them already in attackers’ hands. That is not a market statistic. It is evidence that the attack surface of a fast-growing platform is growing faster than the testing that goes with it.

And patching is still not the end of the conversation. Even with the fixed version deployed, you still need to know whether your instance is exposed some other way and whether someone else has access to it. Current version is the start of the conversation, not the end.

What I would put in the scope of any AI application

This is not an OWASP checklist. It is what I would ask to be tested, and the order matters.

First, authorization per step, not per session. An authenticated user should be able to do exactly what their role allows. In practice, the model stays “has access, therefore can.” Test every state transition in the flow with a lower-privilege credential and see whether it passes.

Second, a process boundary that holds. If your backend has an AI layer handling templates, user data, and tool calls, that boundary has to exist outside the prompt. A prompt that tries to forbid something is a prompt that can be allowed.

Third, configuration as attack surface. In GitLab’s case the vector was configuration, not the request. Custom flow, agent, tool definition, template, environment variable: each of those is input someone controls and deserves the same treatment as an API parameter. Most teams treat configuration as an internal engineering decision. It is a user decision.

Fourth, a report that separates what was tested from what was not. This is where AI complicates everything, because it generates new surface faster than any test cycle can absorb. An honest report that lists what was not covered is worth more than a pretty report that hides the hole.

What to do now

• Put the authorization layer of the AI flow in the scope of your next test, not just the API and the infrastructure.
• Treat agent configuration, templates, and tool definitions as untrusted input, and test them with a low-privilege user.
• Check whether a process boundary exists between the AI layer and what it can reach. If the answer is “the prompt says it shouldn’t,” you don’t have a control, you have a suggestion.
• Ask for a report that states what was not tested, and a retest after the fix, as always.
• If you run the self-hosted GitLab AI Gateway, upgrade to 19.2.4, 19.3.2, or 19.4.1. If you use the hosted one, you need to do nothing.

Worth being clear about what PentestBR does not do: we do not test the model, we do not run prompt red teaming, and we do not promise to know what the AI “thinks.” We test the application. The boundary between what a user can and cannot do belongs to the application, and that is exactly what broke at GitLab.

Prompt injection is the topic everyone wants to argue about. Sandbox escape by an authenticated user is what actually takes services down. The first has become a genre. The second has a CVE number and a publication date.