CRITICAL: GitLab Fixes CVSS 9.9 Command Execution Flaw in AI Gateway

Every few months the industry rediscovers that a template engine is a programming language wearing a nice suit. This week it was GitLab's turn. On October 2, 2026, GitLab disclosed and patched CVE-2026-90970, a critical flaw in its self-hosted AI Gateway that lets an authenticated user break out of the prompt template sandbox and run arbitrary commands on the gateway host. It carries a CVSS score of 9.9, which is about as close to a perfect ten as you can get while still requiring a login.

That login requirement is the only thing keeping this out of full panic territory, and it is a thinner shield than it sounds. The attacker needs access to the Duo Agent Platform, which in plenty of organizations means any developer who has been handed an AI seat. If your rollout plan for GitLab Duo was "give everyone access and see what happens," then congratulations, every one of those people is now a potential path to code execution on a server that sits between your source code and your AI model providers.

What GitLab Actually Fixed

The bug lives in how the AI Gateway processes prompt templates for custom flows inside the Duo Agent Platform. Custom flows let users define how an agent should behave, and those definitions get rendered through Jinja2 style template placeholders on the gateway side. GitLab's advisory puts it plainly, saying that "an authenticated user with Duo Agent Platform access could escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway."

The weakness is classified as CWE-1336, which is the formal name for improper neutralization of special elements used in a template engine. Most of us know it by the shorter and more ominous name of server side template injection. The pattern is old and well understood. User supplied data reaches a template renderer that treats it as instructions rather than text, and the attacker walks the object graph of the underlying language until they find something that spawns a process. Sandboxed template environments exist precisely to stop that walk, and when a sandbox escape is possible, the sandbox is decorative.

What makes this one worth your attention is where it happens. The AI Gateway is the service that connects a GitLab instance to the large language models behind Duo features. By design it handles prompts that include code context, and it holds whatever credentials it needs to talk to model providers. A command execution foothold on that box is not a nuisance. It is a front row seat to the traffic flowing between your repositories and your AI stack, with a decent chance of walking away with API keys along the way.

Affected Versions and Who Needs to Act

The vulnerable range is broad. Self-hosted AI Gateway releases from 18.1.6 onward are affected, covering everything through 19.2.3, along with 19.3.0 and 19.3.1, plus 19.4.0. GitLab shipped fixes in AI Gateway 19.2.4, 19.3.2, and 19.4.1, so the move is to jump to the patched release in whichever branch you are running, or to the latest 19.4 line if you have the flexibility.

The good news is that the blast radius is limited to organizations hosting their own gateway. GitLab says the fix has already been deployed to the gateways it operates, so customers on GitLab.com, GitLab Dedicated, and self-managed instances that route through the GitLab hosted gateway do not need to do anything. GitLab also says it has contacted affected self-hosted customers directly, which is a nice touch, though I would not count on that email landing in the right inbox at every shop.

The organizations most likely to be running a self-hosted gateway are, not coincidentally, the ones with the most to lose. Teams usually self-host the AI Gateway because they have data residency requirements, air gapped or regulated environments, or a policy that source code never leaves their infrastructure. Think defense contractors, healthcare software vendors, financial institutions, and government agencies. The very customers who went out of their way to keep their AI traffic in house are the ones who now have to patch a server that was supposed to be the safe option.

Exploitation Status

As of publication there is no evidence of exploitation in the wild. CISA added an SSVC assessment to the CVE record on October 2 listing exploitation as "none," and no public proof of concept has surfaced. The flaw was reported privately through GitLab's HackerOne bug bounty program by a researcher going by invisiblemeerkat, which is the way you want these things to come to light.

I would not read too much comfort into that, though. GitLab publishes its security fixes, and the AI Gateway code is available for anyone to diff. Template injection bugs are among the friendliest vulnerability classes to reverse engineer from a patch, because the fix usually reveals exactly which input was reaching the renderer unfiltered. Once someone figures out which flow configuration fields were passed through, building a working payload is the kind of afternoon project that shows up on a researcher's blog within a couple of weeks. Assume the clock is running.

The insider angle matters here too. A CVSS score that hinges on authentication tends to get mentally discounted, but in this case "authenticated" means a developer account with Duo access, not an administrator. A phished developer, a contractor with lingering access, or a disgruntled employee all meet the bar. So does an attacker who has already compromised a single developer workstation and lifted a session token. Developer credentials are one of the most actively targeted asset types in the current threat landscape, and this bug turns any one of them into a server compromise.

What to Do Right Now

Start by finding out whether you run a self-hosted AI Gateway at all. If your GitLab instance uses the GitLab hosted gateway, you are covered and can move on with your day. If you run your own, check the version immediately and upgrade to 19.2.4, 19.3.2, or 19.4.1 depending on your branch. GitLab has not published a workaround, so there is no configuration toggle that buys you time. If you genuinely cannot patch today, the closest thing to a stopgap is restricting Duo Agent Platform access to a small group of trusted users until you can, and making sure the gateway cannot reach anything it does not strictly need.

Since GitLab also offers no guidance on detecting prior exploitation, you will have to do some of that thinking yourself. Review the custom flow configurations that exist in your environment and look for anything with unusual template syntax, especially expressions that reference object attributes, class hierarchies, or module imports rather than simple variable substitution. On the gateway host, look for child processes spawned by the gateway service that have no business existing, such as shells, curl, wget, or Python one liners. Outbound connections from the gateway to destinations other than your configured model providers deserve a hard look as well.

If anything looks off, treat the gateway as compromised. Rotate every model provider API key and service token the gateway had access to, review what prompts and code context passed through it, and rebuild the host from a known good image rather than trying to clean it in place. That is a lot of work to avoid, which is a pretty good argument for patching this morning.

Longer term, this is a good moment to revisit how your AI tooling is segmented. The AI Gateway should sit in its own network zone with tight egress rules, run under a least privilege service account, and have its logs shipped somewhere an attacker on the box cannot quietly edit them. AI infrastructure has been bolted onto a lot of development environments in a hurry over the past two years, and a lot of it was deployed with the security posture of a proof of concept. Bugs like this are the bill coming due.

The Bigger Picture

This is not an isolated incident so much as a preview. Every vendor shipping agent platforms is building features that take user defined configuration, stitch it into prompts, and render it through some flavor of template engine. Prompt templates are code, and flow configurations are code, regardless of whether the product page calls them settings. When an attacker controls the input to a renderer, the security of the whole system comes down to how well that renderer's sandbox holds. History suggests the answer is "not as well as everyone hoped."

GitLab handled this one responsibly, with a quick fix, a hosted gateway patched before disclosure, and direct outreach to affected customers. The part that worries me is everyone else building similar features with less mature security programs. If your organization is evaluating AI agent platforms, ask the vendor how user supplied flow and prompt configuration gets rendered, what sandboxing is in place, and when it was last tested. If they look at you blankly, that is your answer.

For self-hosted GitLab AI Gateway customers, the severity description is simple. Drop everything and patch this now.

MSP Angle

Clients who self-host AI tooling for compliance reasons are exactly the regulated, security conscious buyers who will pay for help, so use this CVE to open a conversation about an AI infrastructure assessment that inventories gateways, agent platforms, and the credentials they hold. Package it with ongoing patch management for developer tooling, a category most MSPs ignore and most clients are quietly failing at.