GitLab's 9.9 Gateway Flaw: Self-Hosters First

For most GitLab customers, the October 2 disclosure of a critical AI Gateway flaw meant nothing more than a note that GitLab had already handled it. For a narrower group, the same advisory carried an immediate instruction: update now. The split comes down to who runs the gateway — the service that connects a GitLab instance to AI models — on their own infrastructure.

GitLab rated the flaw critical at 9.9 out of 10, and the company said a logged-in user with Duo Agent Platform access could, under certain conditions, run commands on the gateway. The company disclosed the issue on October 2 and tracked it as CVE-2026-90970.

Who Actually Has to Act

GitLab operates AI Gateways for its customers and had already applied the fix before the advisory went out. Customers on GitLab.com, GitLab Dedicated, and self-managed instances that use a GitLab-hosted gateway do not need to take any action, according to GitLab, said in an advisory.

The picture changes for self-managed customers who host their own gateway, an arrangement GitLab offers so that AI request and response data stays inside the customer's own environment. GitLab strongly recommended those customers update immediately, and it sent that guidance to them before the advisory became public.

That group is also the one holding sensitive material. A self-hosted gateway stores signing keys for JSON Web Tokens, which GitLab's install guide describes as credentials that must be treated as sensitive. The same service connects to the GitLab instance on one side and to the organization's AI model providers on the other.

What the Advisory Says About the Flaw

The weakness sits in the prompt template of a custom flow, according to the advisory's title. A custom flow is an AI-powered workflow that users build on the Duo Agent Platform to automate tasks made up of multiple steps.

According to GitLab, a logged-in user with Duo Agent Platform access could have used the flaw to

escape the prompt template sandbox via a specially crafted flow configuration

— GitLab, in its advisory

That escape could then lead to arbitrary command execution on the gateway itself. The advisory does not describe what conditions the attack requires, and beyond Duo Agent Platform access, it names no particular user role.

GitLab credited the HackerOne user invisiblemeerkat with reporting the flaw. The company did not say whether the flaw has been used in attacks. On October 2, the U.S. Cybersecurity and Infrastructure Security Agency added an assessment to the CVE-2026-90970 record listing exploitation as "none." CISA's other two values cover a public proof of concept and active exploitation.

The Versions That Need Replacing

The versions below are AI Gateway versions, not GitLab versions. The gateway is installed as its own Docker image or Helm chart and has separate update steps from the rest of a GitLab deployment. The flaw is fixed in gateway versions 19.2.4, 19.3.2, and 19.4.1, with the earliest fixed release being 19.2.4.

• Gateway 18.1.6 or later, before 19.2.4 — fixed in 19.2.4
• Gateway 19.3, before 19.3.2 — fixed in 19.3.2
• Gateway 19.4, before 19.4.1 — fixed in 19.4.1

No fixed version is listed below 19.2.4. That leaves every gateway release from 18.1.6 through the 19.1 line inside the affected range. GitLab's install guide instructs administrators to use the gateway image that matches their GitLab minor version, but the advisory does not say whether a 19.2.4 gateway works with GitLab 19.1 or earlier, or whether fixes for the older lines are planned.

Updating Without Breaking Things

For a Docker deployment, the process is to update a Docker deployment by stopping and removing the running container, then pulling and running the new image tag — for example, self-hosted-v19.4.1-ee. Helm deployments instead set the new tag in the chart's image setting.

Two gaps stand out for administrators who cannot move immediately. No workaround is listed for gateways that cannot yet be updated. The advisory also provides no method to check whether a gateway was attacked before it was updated — meaning an organization that patches late has no built-in way to know what happened during the window it was exposed.

The timing of the fix lines up with GitLab's support structure. As of October 2, GitLab's maintenance policy listed 19.4, 19.3, and 19.2 as the GitLab releases that receive security fixes. Those are the same three lines that received a gateway fix.

A Repeated Class of Weakness

This is not the first time GitLab has patched a flaw of this kind in the gateway. In February, GitLab fixed another gateway flaw, CVE-2026-1868, which it also rated 9.9. A logged-in user could reach that flaw 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 does not mention the February flaw. What the two disclosures share is the entry point: a flow configuration that a user with platform access can shape.

The Limits of the Public Record

Several details a defender might want are simply absent from the advisory. It does not state whether the flaw has been exploited in the wild. It does not spell out the conditions under which the sandbox escape succeeds. It names no specific user role beyond Duo Agent Platform access, so administrators cannot narrow the set of accounts they should treat as relevant. And it offers no detection guidance for gateways that were exposed before patching.

What the advisory does make clear is the scope of exposure: a gateway that is self-hosted, holds JWT signing keys, and bridges a GitLab instance to outside AI model providers. The instructions for those deployments are to move to the fixed gateway release that matches their line — 19.2.4, 19.3.2, or 19.4.1 — using the gateway's own update path rather than a general GitLab upgrade.

Why This Matters for Self-Hosters

The organizations most affected here are the ones that chose self-hosting for control — keeping AI request and response data inside their own environment, away from a vendor-operated service. That choice is what put the patching decision in their hands on October 2, and it is what puts the detection question in their hands afterward.

Because the flaw requires only a logged-in user with Duo Agent Platform access rather than an unauthenticated outsider, the relevant threat model may extend to insiders or to any account that has been compromised through other means. That is an inference from the access requirement GitLab described, not something the advisory states.

The absence of a workaround and of any post-hoc check raises the practical cost of a slow patch cycle. Teams that cannot update immediately have no documented middle ground, and teams that patch late cannot confirm what their gateway did while exposed. For administrators running gateway releases from 18.1.6 through the 19.1 line, the advisory leaves open whether fixes for those older versions are coming — which could mean either upgrading the underlying GitLab line or accepting extended exposure. Neither question has a published answer, and both are worth raising with GitLab support if a deployment cannot reach 19.2.4 or later.