GitLab Fixed a 9.9 in Its AI Gateway's Template Sandbox in February. Today It Fixed Another 9.9 in the Same Sandbox, and February's Patched Builds Were Still Exposed.
GitLab shipped a fix today for CVE-2026-90970, a CVSS 9.9 flaw in its self-hosted AI Gateway. In GitLab's own words, 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."
That sentence should sound familiar. On February 6, GitLab fixed CVE-2026-1868, also a 9.9, also with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, also in the gateway's handling of Duo Agent Platform flow definitions. Same component, same kind of bug, same score, eight months apart. And the affected range for today's bug starts at the same version as February's, which means the builds GitLab told you to install in February were still exposed to this one.
What GitLab says, from the advisory
Per GitLab's patch-release advisory, the affected versions are GitLab AI Gateway 18.1.6 through 19.2.3, 19.3 before 19.3.2, and 19.4 before 19.4.1. The fixed versions are 19.2.4, 19.3.2 and 19.4.1. GitLab-hosted gateways are already patched; only self-hosted gateways need action. Credit goes to the HackerOne researcher invisiblemeerkat. (The Hacker News, which is where we first saw it, gives the vulnerable range as ending at 19.1.x. We use GitLab's numbers.)
February's bug, per GitLab's February 6 advisory, was "insecure template expansion of user supplied data via crafted Duo Agent Platform Flow definitions" in the Duo Workflow Service, found internally by a GitLab security engineer. It affected versions from 18.1.6 and was fixed in 18.6.2, 18.7.1 and 18.8.1. Every one of those fixed builds sits inside today's affected range.
Why the same bug twice is the story
Two 9.9s in the same sandbox does not mean GitLab is careless. It means the sandbox is a hard thing to build, and the first fix closed one way out, not all of them. Template engines given user-controlled input are a well-worn bug class (CWE-1336, improper neutralization of special elements in a template engine), and an agent platform makes the input richer: a "flow" is configuration that describes what an AI agent does, and a gateway that renders it has to treat every field as hostile.
The lesson for defenders is narrower and more useful than "GitLab bad." If you patched in February and moved on, the builds you installed were still exposed to this second escape until today. The patch fixed a CVE; it did not certify the sandbox.
The gateway is the box that calls your models
Here is the part that matters for our beat. In a self-hosted setup, the AI Gateway is the process that brokers calls to your models. GitLab's Duo Self-Hosted configuration docs have you register each model's endpoint, with an optional API key, and for Amazon Bedrock they tell you to give the gateway's Docker container access to AWS in the right region.
So command execution on the gateway is not just code on a box. It is code on the box that holds the keys to your metered inference. That is the shape of what we have been calling tokentheft: someone else spending the model capacity you pay for, from a position where it looks like your own traffic. We have no evidence anyone has done that through this bug. We are describing what the position gives an attacker, not reporting that it happened.
How fast does a GitLab 9.9 get used?
Three weeks ago we wrote that GitLab was exploited one day after the patch: GitLab disclosed CVE-2026-85706 on September 10, and watchTowr observed exploitation on September 11. That bug was unauthenticated and sat on the main GitLab application, which is everywhere.
This one is different in two ways, and both lower the urgency without removing it. It needs a logged-in user who already has Duo Agent Platform access, and it only affects self-hosted AI Gateways, a much smaller population than GitLab itself. As of tonight, neither CVE-2026-90970 nor CVE-2026-1868 is in CISA's Known Exploited Vulnerabilities catalog, and neither GitLab nor the reporting we read mentions exploitation.
What we hold
Nothing, and we checked. Our exploit harvester has no proof-of-concept repository for either CVE, our index has no indicators tied to them, and we had not written about the February bug. If a public PoC appears, the harvester is built to catch it, and we will say when it did, next to GitLab's date.
What to do
Upgrade self-hosted AI Gateways to 19.2.4, 19.3.2 or 19.4.1, whichever matches your line. Then look at who holds Duo Agent Platform access, because "PR:L" in that vector means any of them could have tried this, and the flows they can submit are now part of your attack surface. If your gateway was reachable by users you do not fully trust while it ran an affected version, consider rotating the model endpoint keys and cloud credentials it held. That is the cheap move, and it closes the tokentheft path regardless of whether anyone walked it.
Every version number, date and quote above comes from GitLab's two advisories, GitLab's configuration documentation, and CISA's catalog as of today. We hold it at about 95 percent confidence. The other 5 percent is the gap between two sources that already disagree on where the vulnerable range ends.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=gitlab-fixed-a-9-9-in-its-ai-gateway-s-template-sandbox-in-february-today-it-fixed-another-9-9-in-t
Comments