CVE-2026-90970: a CVSS 9.9 warning for self-hosted AI gateways

The worst bug of GitLab's week wasn't in GitLab

On October 2, GitLab disclosed CVE-2026-90970 and rated it 9.9 out of 10. The flaw lives in the self-hosted GitLab AI Gateway, the service that connects a GitLab instance to AI models. GitLab runs that gateway for most customers and has already patched its own fleet. The group that needs to act is smaller: organizations that host their own gateway to keep AI request and response data inside their network. If that includes you, the fix ships in gateway versions 19.2.4, 19.3.2, and 19.4.1, and the advisory recommends upgrading immediately.

Why lead with a CVE you may not be able to trigger? Because it exposes something structural. The most sensitive new piece of AI infrastructure you run is probably not your model server. It's the gateway in front of it, and this is the second time in eight months that component has scored 9.9.

What the flaw actually is

The advisory title calls it an improper neutralization issue in the custom flow prompt template. Custom flows are AI-powered workflows that users build on the Duo Agent Platform to automate multi-step tasks. GitLab's description: an authenticated user with Duo Agent Platform access could have escaped the prompt template sandbox through a specially crafted flow configuration, which could lead to arbitrary command execution on the gateway.

The CVSS vector fills in conditions the prose leaves out: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Network-reachable, low attack complexity, a low-privilege account is enough, and the scope-changed flag, meaning the escape crosses a security boundary instead of staying inside it. In plain terms, GitLab modeled this as an ordinary user breaking out of a sandbox and landing on the box itself, with full impact on confidentiality, integrity, and availability.

What the advisory does not give you: the specific conditions of an attack, a role name beyond Duo Agent Platform access, a workaround, or a way to check whether your gateway was hit before you patched. invisiblemeerkat reported it through HackerOne.

Which versions are affected

No fixed version exists below 19.2.4. Every gateway release from 18.1.6 through the entire 19.1 line is inside the affected range, and GitLab's maintenance policy listed 19.4, 19.3, and 19.2 as the only lines receiving security fixes as of October 2. The advisory is silent on whether a 19.2.4 gateway works with GitLab 19.1 or older, and on whether older lines will get fixes. If you're pinned to an old GitLab minor, that's a question for GitLab support before you plan the upgrade.

Why the gateway deserves 9.9-level urgency

The severity makes more sense once you look at what a self-hosted gateway is. It holds the signing keys for the JSON Web Tokens that authenticate AI traffic, and GitLab's install guide says those keys must be treated as sensitive credentials. It holds live connections to your GitLab instance and to your model providers. Command execution on that box means an attacker can mint valid tokens, read the AI request and response payloads flowing through it, and abuse its trusted position to reach whatever talks to it. That's what the scope-changed flag is for: this escape doesn't stay in the sandbox.

The weakness class deserves a name too. The Hacker News points out that this flaw and February's CVE-2026-1868 share CWE-1336, the template-injection class. February's flaw was also rated 9.9 and also arrived through a crafted flow definition. Two template-injection criticals in the same component within eight months is a pattern. Prompt templates get assembled from user-influenced configuration, then fed to an engine that treats parts of the string as instructions, so every AI feature that lets users define flows is another template engine instance to get right.

CISA added an assessment to the CVE record on October 2 listing exploitation as none, and no public proof of concept exists yet. I'd still treat patching as urgent. The advisory title alone describes the escape surface precisely, the patched code is public, and gateways sit on networks full of credentials by design.

What to do today

1. Find your gateway version. The gateway installs as its own Docker image or Helm chart and versions independently of GitLab itself. If nobody on your team can answer "what version is our AI gateway" in under a minute, that's the first finding.
2. Patch. For Docker deployments, the upgrade is stop and remove the running container, then pull and run the new tag, for example self-hosted-v19.4.1-ee. Helm deployments set the new tag in the chart's image setting.
3. If you can't patch yet, plan containment. The advisory lists no workaround and no detection guidance. The honest fallback is knowing who can reach the gateway, what the JWT signing keys protect, and how you'd rotate those keys. Rotating keys right after patching is cheap insurance given what they unlock.
4. If you don't host your own gateway, nothing to do. GitLab.com, GitLab Dedicated, and self-managed instances on a GitLab-hosted gateway are already protected.

One inventory question worth answering this week: can you list, from memory, every AI-side component your organization self-hosts? Most admins can name their reverse proxies and databases instantly. The gateway usually comes up only when it breaks, or when its vendor uses the word critical. This CVE is one patch. Keeping that inventory current is what turns the next 9.9 into a Tuesday-morning task instead of a fire drill.