Your self-hosted GitLab AI Gateway might be carrying a flaw that hands command execution to any logged-in user with Duo Agent Platform access, because GitLab just disclosed a critical vulnerability in the gateway's prompt template handling, and it scores 9.9 out of 10 on the severity scale, which puts it near the ceiling of what a single bug can do.
The flaw is tracked as CVE-2026-90970, it affects every gateway release before the fixed builds, and the relief here is narrow, because only organizations running their own gateway need to move.
What Makes the GitLab AI Gateway Vulnerability So Serious
The AI Gateway is the service sitting between your GitLab instance and your AI model providers. It's not a peripheral component.
A self-hosted gateway holds JWT signing keys, and GitLab's own install guide says to treat those as sensitive credentials. It also connects out to your GitLab instance and to every AI provider your organization uses.
So when a flaw lets someone escape a sandbox and run commands on that service, they land in a spot with real reach.
GitLab rated it critical. CISA added an assessment to the CVE record on October 2 listing exploitation as "none," which means no confirmed attacks so far.
Breaking Down CVE-2026-90970
The Prompt Template Sandbox Escape
The bug lives in the prompt template of a custom flow. Custom flows are AI-powered workflows users build on the Duo Agent Platform to automate multi-step tasks.
GitLab's advisory says a logged-in user with Duo Agent Platform access could "escape the prompt template sandbox via a specially crafted flow configuration."
That escape leads to arbitrary command execution on the gateway.
What the Advisory Doesn't Say
The conditions the attack needs aren't described. No specific user role is named beyond Duo Agent Platform access.
GitLab also doesn't say whether the flaw has been used in attacks. CISA's "none" assessment is a snapshot, not a guarantee.
GitLab credited HackerOne user invisiblemeerkat with the report.
Who Needs to Patch Right Now
This is the part that saves most teams a headache. GitLab runs AI Gateways for its customers, and those are already fixed.
You don't need to act if you're on:
- GitLab.com
- GitLab Dedicated
- A self-managed instance using a GitLab-hosted gateway
You do need to act if you host your own gateway. That's the option GitLab offers for keeping AI request and response data inside your own environment, and it's the deployment carrying this flaw.
GitLab strongly recommends immediate updates, and it sent that guidance to self-hosted gateway customers before publishing the advisory.
Affected and Fixed Versions
These are AI Gateway versions, not GitLab versions. The gateway ships as its own Docker image or Helm chart, so it has separate update steps.
|
Gateway version in use |
First fixed version |
|
18.1.6 or later, before 19.2.4 |
19.2.4 |
|
19.3, before 19.3.2 |
19.3.2 |
|
19.4, before 19.4.1 |
19.4.1 |
GitLab's maintenance policy, as of October 2, lists 19.4, 19.3, and 19.2 as the releases receiving security fixes. Those are the same three lines that got the gateway patch.
How to Update Your Self-Hosted Gateway
The update itself is straightforward, and it depends on how you deployed.
Docker deployments: Stop and remove the running container, then pull and run the new image tag. A working example is self-hosted-v19.4.1-ee.
Helm deployment: Change the tag in the 'image' setting of the chart, then deploy the release.
Match the gateway image to your GitLab minor version, which is what GitLab's install guide tells administrators to do.
The Gaps in This Advisory Worth Knowing
Three things stand out, and none of them are comfortable.
No fixed version exists below 19.2.4. Every gateway release from 18.1.6 through the 19.1 line sits inside the affected range. GitLab hasn't said whether a 19.2.4 gateway works with GitLab 19.1 or earlier, and it hasn't said whether fixes for those older lines are coming.
There's no workaround. If you can't update yet, the advisory offers nothing to reduce risk in the meantime.
There's no way to check for past compromise. GitLab gives no method for determining whether a gateway was attacked before it was patched.
If you're stuck on an older line, that combination should push the upgrade question up your priority list.
A Pattern Worth Noticing
This isn't GitLab's first gateway flaw of the year, and the similarity is hard to ignore.
In February, GitLab fixed CVE-2026-1868, also rated 9.9. A logged-in user could reach it through a crafted flow definition, and it could lead to denial of service or code execution on the gateway.
Both flaws are template engine weaknesses of the same class, CWE-1336. The new advisory doesn't mention the February one, but the shape of the bug is familiar.
AI gateways sit in a strange spot. They accept user-authored configurations, they run with elevated access to credentials and model providers, and they're newer than the rest of your stack. That's a combination that tends to produce repeat findings.
FAQ
Does CVE-2026-90970 affect GitLab.com users?
No. GitLab runs and has already patched the gateways for GitLab.com, GitLab Dedicated, and self-managed instances using a GitLab-hosted gateway. Only self-hosted gateway deployments need action.
What can an attacker do with this GitLab AI Gateway vulnerability?
A logged-in user with Duo Agent Platform access can escape the prompt template sandbox through a crafted flow configuration, which can lead to arbitrary command execution on the gateway.
Which gateway versions fix CVE-2026-90970?
19.2.4, 19.3.2, and 19.4.1. There is no fixed version listed below 19.2.4, so releases from 18.1.6 through the 19.1 line remain affected.
Is there a workaround if I can't update right away?
No. GitLab lists no workaround for gateways that can't be updated yet, which makes patching the only real option.
Has this flaw been exploited in the wild?
As of October 2, CISA's assessment on the CVE record lists exploitation as "none." GitLab's advisory doesn't state whether attacks have occurred.
How do I update a Docker or Helm AI Gateway deployment?
For Docker, stop and remove the container, then pull and run the new image tag, such as self-hosted-v19.4.1-ee. For Helm, set the new tag in the chart's image setting and apply the release.
