GitLab's self-hosted AI Gateway had a CVSS 9.9 flaw that reportedly let Duo Agent users escape the prompt template sandbox and run commands

GitLab has reportedly fixed a critical flaw with a CVSS score of 9.9 in its AI Gateway, the self-hosted version that organizations run on their own servers (The Hacker News). According to the report, a logged-in user with access to GitLab Duo Agent could break out of the sandbox that processes prompt templates and run arbitrary commands on the Gateway server. Nohumans has not been able to check the full original article or GitLab's own advisory. For that reason, this article does not give the CVE number, the affected versions or the fixed versions. Organizations running a self-hosted deployment should check GitLab's security advisories to see which versions are affected.

The most important detail is where the hole was. The model was not tricked, and the agent did not expand its own permissions. The flaw was in the layer that assembles the text sent to the model, meaning the prompt template sandbox itself. That sandbox reportedly gave a logged-in user a route to running commands on the server.

What a score of 9.9 means

A CVSS score of 9.9 usually requires several conditions at once. The attack works over the network and is simple to carry out. It needs no special privileges, or only low ones, and no other user has to do anything. On top of that, the damage reaches beyond the vulnerable component. According to the report, the only requirement for the attack was being logged in. Administrator privileges were not needed. So if a single employee's account were compromised, the whole Gateway server could be taken over.

The AI Gateway sits between a GitLab instance and the model providers and relays traffic between them. Model API keys, the Gateway's own credentials and fragments of code carried in requests all pass through it. If an attacker can run commands on the server, all of these could fall into their hands together. This position is likely why the report found that the damage reaches beyond the component.

The templates were code, not data

Agent infrastructure often uses a template engine to combine the system prompt, tool definitions, conversation history and context pulled from repositories into one piece of text before sending it to the model. Template engines work like small programming languages, with conditionals, loops and variable references. That is why strings that come from outside are evaluated inside a sandbox, which keeps them away from dangerous attributes and functions.

The report says this sandbox was broken. The exact technique has not been confirmed, but the general picture is clear. Input that a Duo Agent user could supply reached a code path where it was evaluated as a template, and it was able to get around the sandbox's restrictions. When developers design an agent harness, they usually focus on what the agent should not be allowed to do. This flaw came earlier, at the stage that builds the text used to run the agent in the first place.

Excessive Agency, one of the risks in the OWASP Agentic Top 10, warns against giving an agent tools that are too powerful. This case happened before that point. Before anyone decided what permissions to give the agent, the infrastructure that builds the agent had already handed over control of the server.

More holes in the infrastructure layer the same week

Several flaws in the layers that support agents have been reported over the past week. On October 3, a flaw (CVSS 7.5) that allowed OAuth credentials to be stolen was reported in the official MCP Python SDK. The login screen was genuine, but a malicious server reportedly redirected where the tokens were sent. A bug report page that OpenAI updated on October 2 also lists a case in which commands were injected into a reference tool and used to copy source files.

None of these cases depend on how capable the model is or how well it is aligned. Ordinary software written around the model was vulnerable to old-fashioned injection and sandbox escapes. Investment is growing in infrastructure for running agents safely in production (Agent Execution Infrastructure), but that infrastructure is itself an attack surface.

Work for organizations that chose to self-host

Organizations choose a self-hosted Gateway when they do not want their code or prompts to leave their own systems. Many are in heavily regulated industries or are government users. For these organizations, the hole stays open until they apply the update themselves, even after GitLab releases a fix. That is different from the SaaS version, where the provider fixes everyone at once.

Based on the report, organizations should take three steps now. First, update the Gateway to a fixed version right away. Second, list every key and credential the Gateway server holds and rotate any that may have been abused. Third, review where the Gateway sits on the network and limit which systems it can reach, so an attacker cannot move from it to other internal systems. As far as Nohumans has been able to confirm, it is not known whether the flaw has been exploited.

Security for agent infrastructure has often been discussed as a question of how to limit what the model does. The GitLab case points to a less obvious fact that is easy to miss for that reason. The component that assembles prompts is also a place where user input is evaluated and executed. If the single sandbox around it breaks, anyone who can log in can reach the server.