GitLab fixed a CVSS 9.9 prompt-template sandbox escape in its AI Gateway. Self-hosted gateways must move to 19.2.4, 19.3.2 or 19.4.1.
GitLab has patched CVE-2026-90970, a critical flaw in its AI Gateway. An authenticated user with access to the Duo Agent Platform could escape the prompt template sandbox with a crafted flow configuration and run arbitrary commands on the gateway. GitLab rates it CVSS 9.9. Only organizations that run their own Self-Hosted AI Gateway need to act: the fixed releases are 19.2.4, 19.3.2 and 19.4.1. GitLab says GitLab.com, GitLab Dedicated, and Self-Managed instances that use a GitLab-hosted gateway are already protected.
What happened
On October 2, 2026, GitLab published CVE-2026-90970 together with a dedicated patch release for the AI Gateway, separate from its usual GitLab Community and Enterprise Edition releases. The advisory carries one fix, titled "Improper Neutralization issue in custom flow prompt template impacts AI Gateway" and rated Critical.
GitLab's description: the issue "could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway."
| Field | Detail |
|---|---|
| CVE | CVE-2026-90970 (GitLab is the CNA) |
| CVSS 3.1 | 9.9 Critical, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
| Weakness | CWE-1336, Improper Neutralization of Special Elements Used in a Template Engine |
| Affected | AI Gateway 18.1.6 before 19.2.4, 19.3 before 19.3.2, 19.4 before 19.4.1 |
| Fixed | AI Gateway 19.2.4, 19.3.2, 19.4.1 |
| Credited to | invisiblemeerkat (HackerOne researcher) |
GitLab says it contacted Self-Hosted AI Gateway customers directly before it published the advisory, and that the fix is already deployed on the gateways it hosts. The vendor work item linked from the CVE record (628842) is not public. GitLab's patch release notes say security issues are made public on its tracker 90 days after release.
Why it matters
GitLab's install guide describes the AI Gateway as "a combination of two services that give access to AI-native GitLab Duo features": the AI Gateway service and the GitLab Duo Agent Platform service. In a self-hosted deployment, the customer runs it as a container alongside their own GitLab instance and model endpoints. A flaw that turns a user's agent flow configuration into command execution on that service breaks the boundary between "can use Duo agents" and "can run code on infrastructure."
Three parts of the CVSS vector define the risk:
- Low privileges (
PR:L). The attacker needs only a valid account with Duo Agent Platform access, not an administrator role. Every user who can build or edit agent flows is in scope. - Scope changed (
S:C). GitLab's scoring says the impact reaches beyond the vulnerable component. GitLab does not say what that covers. A reasonable reading, which is our inference and not GitLab's statement, is that the gateway's own configuration, its credentials for model endpoints, and its network position toward the GitLab instance and model hosts are exposed once an attacker runs commands on it. - No user interaction (
UI:N). No victim has to click anything.
What the flaw is not: it does not affect GitLab.com users, GitLab Dedicated, or Self-Managed instances that send AI traffic to a GitLab-hosted gateway. It is not in CISA's Known Exploited Vulnerabilities catalog (checked against the October 2 catalog), and GitLab's advisory says nothing about exploitation. CISA's enrichment on the CVE record, added October 2, lists exploitation as "none", automatable as "no", and technical impact as "total".
Technical details
The attack path GitLab describes for CVE-2026-90970, with the affected and fixed AI Gateway versions. Source: GitLab AI Gateway patch release notes.
GitLab has not published a technical write-up, and the work item is private, so the mechanism can only be described at the level the advisory and the CVE record give.
- Entry point: a custom flow. The advisory names the "custom flow prompt template" as the vulnerable element, and the attacker's input is "a specially crafted flow configuration."
- Weakness: template injection. CWE-1336 covers input that a template engine evaluates as template syntax rather than data. Here, GitLab says the attacker could "escape the prompt template sandbox." The advisory places both the template and the resulting command execution on the gateway. Our reading is that the sandbox is the control meant to stop user-supplied template content from reaching the host.
- Result: command execution on the AI Gateway, under the gateway's own privileges. The advisory says this happens "under certain conditions" and does not list them.
This is a server-side template sandbox escape. It is not prompt injection against the model: the model's output is not involved in the advisory's description.
The affected range starts at 18.1.6. GitLab has not said whether that version introduced the vulnerable code or is simply the oldest release it checked.
What defenders should do
1. Check whether you run a Self-Hosted AI Gateway. If your GitLab instance uses GitLab's hosted gateway, or you only use GitLab.com or Dedicated, GitLab says no action is needed. Self-hosted gateways are typically deployed from the model-gateway container image under gitlab-org/modelops/applied-ml/code-suggestions/ai-assist, with the HTTP service on port 5052 and the Duo Workflow gRPC service on port 50052, according to GitLab's install guide.
2. Upgrade the gateway to 19.2.4, 19.3.2 or 19.4.1. GitLab's install guide tells operators to run the latest self-hosted-vX.Y.*-ee image tag that matches the GitLab instance's major and minor version. FIPS images use the same tag format. For Docker, the guide's procedure is to stop and remove the running container, then pull and run the new image with the same environment variables.
3. Watch for the Helm pull-policy trap. GitLab's guide warns that Helm chart versions before 0.7.0, and Kubernetes by default, use imagePullPolicy: IfNotPresent, which can miss security patches published under an existing tag. It recommends pinning the image by digest. Confirm the running container's digest after the upgrade.
4. If your gateway runs 18.1.6 or later on the 18.x line, or any 19.0 or 19.1 release, there is no fixed gateway release in your line. The affected range runs from 18.1.6 up to 19.2.4, and the lowest fixed version is 19.2.4. Because the install guide pairs the gateway's tag with the GitLab version, getting a fixed gateway may mean upgrading GitLab itself to 19.2 or later. GitLab's advisory does not address this case. Check with GitLab support before running a mismatched gateway version.
5. Until you can patch, reduce who can reach the vulnerable path. GitLab has published no workaround. Because the attacker needs Duo Agent Platform access, limiting that access to users you would trust with code execution on the gateway host reduces exposure. This is our suggestion, not vendor guidance.
6. Review the gateway for signs of misuse. GitLab has published no indicators of compromise. Reasonable starting points are unexpected child processes or shell activity in the gateway container, unexpected outbound connections from it, and recently created or changed custom flows. Because a successful attack runs commands with the gateway's privileges, rotate any credentials the gateway holds for model endpoints if you find anything suspicious.
7. Don't confuse this with the CE/EE release. On September 23, GitLab shipped GitLab CE/EE 19.4.1, 19.3.3 and 19.2.7, a separate critical patch for the GitLab application. The version numbers overlap with the gateway fix. A Self-Managed instance with a self-hosted gateway may need both.
What is still unclear
- The exact conditions. GitLab says the escape works "under certain conditions" and has not listed them. The work item should become public about 90 days after release.
- Older release lines. No fix is listed below 19.2.4, and GitLab has not said whether gateways on 18.1.6 through 19.1.x can run a fixed gateway without upgrading GitLab.
- Post-exploitation impact. The
S:Cscore implies impact beyond the gateway, but GitLab has not said which credentials or systems are exposed. - Exploitation. None has been reported. This article will be updated if GitLab, CISA or a researcher reports exploitation or publishes technical details.