A Prompt Template Was The Blast Radius
A specially crafted flow configuration in GitLab's self-hosted AI Gateway escapes the prompt-template sandbox and runs commands on the gateway host. CVSS 9.9. The customers who need to patch are the ones who self-hosted on purpose.
On October 2, GitLab shipped patches for CVE-2026-90970, a critical flaw in its self-hosted AI Gateway. The CVSS is 9.9. The vulnerable primitive is not a model. It is not a prompt-injection payload reaching the model. It is the piece of the gateway whose entire job is to keep user-supplied text from reaching the host — the prompt-template sandbox for custom flows in the Duo Agent Platform — and the escape is a flow configuration the user is allowed to author in the normal course of using the product.
The outcome, per GitLab's own characterization reported by The Hacker News and summarized at SQ Magazine and Cybersecurity News: "a specially crafted flow configuration could let a user escape the prompt template sandbox," which "leads to arbitrary command execution on the AI Gateway." No workaround is listed. Only the upgrade helps.
What the vulnerable surface actually is
The GitLab AI Gateway is the self-hosted service that mediates between GitLab Duo clients — Duo Chat, the Duo Agent Platform — and the LLM provider on the backend. Inside Duo Agent Platform, custom flows let an authenticated user define a multi-step AI-powered workflow by writing a flow configuration that the gateway renders through a prompt-template engine.
That engine is the whole trust boundary. The flow configuration is user-authored. The gateway treats everything on the other side of the template as system-controlled. The template is the piece that is supposed to keep those two apart.
The flaw is in the template, not in the model. A specially crafted flow configuration escapes the sandbox and executes commands on the gateway host. Mallory.ai's story frames it the same way: "sandbox escape allowing arbitrary command execution." The attacker does not need an adversarial model, a jailbreak, a prompt injection against someone else's conversation, or a compromised dependency. The attacker needs permission to author a Duo Agent flow — the ordinary permission a developer would have on day one.
Who is exposed, and who is not
Per The Hacker News and Security Online, the affected versions are AI Gateway 18.1.6 through 19.2.3, 19.3.0 through 19.3.1, and 19.4.0. The fixes are 19.2.4, 19.3.2, and 19.4.1. GitLab explicitly notes that GitLab.com, GitLab Dedicated, and self-managed GitLab instances using the GitLab-hosted gateway "do not need to act."
The exposure is on the self-hosted gateway tier only. That tier is a deliberate choice. The customers who stood up an AI Gateway on their own hardware did so to keep prompts off GitLab's SaaS — usually for data-residency, confidentiality, or compliance reasons. The intuition from the rest of the stack says cloud-first is the riskier posture. Here it reverses: GitLab.com customers get the fix server-side with nothing to do; self-hosted customers inherit the patch window and the change-control delay.
No workaround
GitLab's advisory, as summarized by The Hacker News, does not list a workaround for gateways that cannot be updated immediately. The container-based remediation is to "stop and remove the running container, then pull and run the new image tag." If an operator cannot deploy 19.2.4, 19.3.2, or 19.4.1 today, there is no documented interim mitigation other than restricting Duo Agent Platform access entirely.
Cybersecurity News and SQ Magazine credit the finding to HackerOne researcher "invisiblemeerkat" under coordinated disclosure. No active exploitation was known at the time of patch; CISA's assessment, per the Threat Radar entry, lists exploitation as "none."
The architectural read
Three things in this disclosure travel beyond GitLab.
One: a prompt-template sandbox is a code boundary, not a text boundary. Template engines render arbitrary structured data into text that downstream code trusts. If anything in that pipeline — a filter, a loop construct, a nested interpolation — reads the user's input as instructions rather than as data, the sandbox is a code path, not a wall. The ecosystem's shared mental model of "the model is where the risk lives" misses that the engines routing data to the model are often older, less-tested substrates than the model itself.
Two: an internal user is a sufficient threat model. The attacker does not need to be an outsider. They do not need to escalate privileges. Ordinary Duo Agent Platform access — the kind every developer at an adopting enterprise gets at onboarding — is the entry condition. For any product that lets its own users author flow configurations, agent skills, custom tool definitions, or template files, the risk model is "every authenticated user on your tenancy" by default.
Three: self-hosted is not a security boundary. The customers running an AI Gateway on their own infrastructure chose that posture to raise their security floor. For the duration of the 18.1.6-through-19.4.0 window, their floor was 9.9 CVSS to arbitrary command execution by an internal user. Deployment topology is a privacy and compliance decision. It is not a vulnerability-containment decision.
If you run a self-hosted GitLab AI Gateway: patch to 19.2.4, 19.3.2, or 19.4.1 today.
If you build or integrate an AI gateway, a prompt-template engine, or a flow authoring surface anywhere else: audit the paths where user-authored text reaches a template renderer that your product trusts. The template is the boundary. Treat it like one.
SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.