GitLab's AI Gateway Let a Crafted Flow Configuration Break Out of Its Prompt Sandbox

On 2 October 2026, GitLab published a critical patch release for its AI Gateway — the middleware that carries requests between a GitLab instance and the language models its Duo features call — naming CVE-2026-90970 and rating it 9.9 out of 10. The flaw, in GitLab's own words, 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." Only organisations running a self-hosted AI Gateway needed to act: GitLab had already fixed the gateways it operates for GitLab.com, GitLab Dedicated and self-managed customers that use a GitLab-hosted gateway, and said so in the advisory. GitLab's notice does not say the flaw was ever exploited, and the assessment attached to the CVE record by the US Cybersecurity and Infrastructure Security Agency on the same day lists exploitation as "none". Credit for the finding went to the HackerOne researcher known as invisiblemeerkat. GitLab's advisory, the NVD record and the reporting that followed it are consistent with one another about what the flaw was and which versions carried it; they are equally consistent about what is not known, which is whether anyone ever used it. This record sits alongside the other documented agent-infrastructure vulnerabilities in the AI incident archive, where each entry carries its own sources, severity, confidence grade and disputed flag.

What the advisory actually says, and what it leaves out

The advisory is short. Published on GitLab's documentation site under the title "GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2, and 19.4.1", it lists one security fix, headed "Improper Neutralization issue in custom flow prompt template impacts AI Gateway" and marked Critical. It gives the CVSS 3.1 vector as AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — network reachable, low attack complexity, low privileges required, no user interaction, scope changed, and high impact on confidentiality, integrity and availability. That vector is worth reading because it is precise about the attacker: low privileges, but privileges all the same. The advisory says "an authenticated user with Duo Agent Platform access" and stops there. It does not name the role, the permission, or the conditions its own phrase "under certain conditions" refers to.

It does not publish a proof of concept, does not describe the crafted flow configuration, and does not offer a workaround for gateways that cannot be updated immediately. The Hacker News, in its 2 October report, notes the same absences and adds one that matters operationally: the advisory gives no way to check whether a gateway was attacked before it was patched. Security Affairs, writing the following day, records the same gaps.

The common weakness enumeration entry attached to the CVE is CWE-1336, improper neutralisation of special elements used in a template engine. GitLab's advisory never uses the word Jinja. The AI Gateway's own repository documentation does: its prompt-registry document describes prompt configuration files that "support Jinja expression for multiple roles such as user and system", and describes a Prompt class that "uses Jinja to interpolate the prompt templates with the input arguments". The gap the CVE describes is the one that class of engine is famous for — user-supplied text reaching a template that is evaluated rather than printed.

Why a command on this particular host is worth 9.9

The AI Gateway is not a sidecar. Per GitLab's self-hosted documentation, it receives requests from GitLab, assembles the prompts, and talks to the model backend — a vLLM server, A​mazon Bedrock, Azure O​penAI, or an external provider — and in a fully self-hosted deployment it is the component that keeps prompts and responses inside the organisation's own network. GitLab's AI Gateway install guide also tells administrators to generate a signing key pair and pass the two halves to the service as environment variables, as AIGW_SELF_SIGNED_JWT__SIGNING_KEY and AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (with Duo Workflow equivalents). Security Affairs makes the consequence explicit: command execution on the gateway lands an attacker in a host that holds JWT signing material and sits on the path between the GitLab instance and the model infrastructure.

That is the difference between a sandbox escape in a toy and one in production. The escape does not need to reach a model; it needs to reach the process that holds the keys the model calls are signed with.

GitLab's product documentation, separately from the advisory, states that creating or editing a custom flow requires the Maintainer or Owner role in the managing project, and that running one requires Developer or above. The advisory does not confirm that mapping, and The Hacker News notes that no role is named beyond "Duo Agent Platform access". A reader estimating their own exposure should treat the documentation as the product's permission model and the advisory's silence as exactly that: silence, not a contradiction.

Established, and not established

The record's own fields are consistent with everything above and add nothing that is not in the advisory. What follows is the split a reader cannot get from a one-line summary.

• Established: a critical-severity flaw in GitLab AI Gateway, disclosed 2 October 2026, CVSS 9.9, CWE-1336, reachable by an authenticated Duo Agent Platform user through a crafted flow configuration, resulting in command execution on the gateway host.

• Established: the affected range — all AI Gateway versions from 18.1.6 before 19.2.4, 19.3 before 19.3.2, and 19.4 before 19.4.1 — and the fixed versions, 19.2.4, 19.3.2 and 19.4.1.

• Established: GitLab-hosted gateways were patched before publication and their customers need take no action; self-hosted operators were contacted directly ahead of the release post, which GitLab states in the advisory itself.

• Established: the reporter credit, to invisiblemeerkat, and the absence of any statement of exploitation in the wild.

• Not established: whether anyone exploited it. A CISA SSVC assessment dated 2 October 2026 and visible in the NVD record gives exploitation as "none", automatable as "no" and technical impact as "total"; the CISA Known Exploited Vulnerabilities catalogue did not list CVE-2026-90970 in its 20 October 2026 revision, which I checked directly. FIRST's EPSS model put the probability of exploitation in the next 30 days at 0.94 percent on 21 October 2026 — low, and not zero.

• Not established: how many self-hosted gateways exist, how many were exposed, or whether any were attacked before patching. No source in this record gives a count, and GitLab's advisory supplies no detection method.

The affected range, and the versions with no fix listed

The version arithmetic is less tidy than the three fixed releases suggest. The affected range begins at 18.1.6, and no fixed release is published on any line below 19.2.4. Every gateway from 18.1.6 through the 19.1 series therefore sits inside the stated affected range with no patched version named for it. The Hacker News flags the same consequence and the questions that follow: GitLab's install documentation tells administrators to run the gateway image whose version matches their GitLab minor version, and the advisory does not say whether a 19.2.4 gateway works against GitLab 19.1 or earlier, nor whether fixes for the older lines are planned. GitLab's supported-version policy, as The Hacker News notes, currently lists 19.4, 19.3 and 19.2 — the same three lines that received fixes.

Remediation is a container swap rather than a patch: the gateway ships as its own Docker image or Helm chart. GitLab's install guide describes stopping and removing the running container, pulling the new image with a self-hosted-vX.Y.Z-ee tag, and starting it again with the environment variables intact; Helm deployments set the tag in the chart's image field. Neither the advisory nor the install guide offers a signature or indicator that would distinguish an attacked gateway from a clean one.

The same bug class, eight months earlier

This is not the first time GitLab has shipped a 9.9 for template injection in the AI Gateway. On 6 February 2026 it released AI Gateway 18.6.2, 18.7.1 and 18.8.1 for CVE-2026-1868, described in that advisory as an "Insecure Template expansion issue" in which the Duo Workflow Service component was "vulnerable to insecure template expansion of user supplied data via crafted Duo Agent Platform Flow definitions", usable for denial of service or code execution on the gateway. The CVSS vector is identical to October's, character for character, and so is the CWE. The reporter was different: that one was found internally, by GitLab team member Joern Schneeweisz.

The October advisory does not mention the February one, and The Hacker News says so explicitly. Whether the two share a root cause, a fix that did not hold, or merely a language and a threat model, is not something either public document answers. What is on the record is that a template engine in an AI middleware component has now produced two critical command-execution advisories at the same score in the same year, and that the second one required an outside researcher to find.

What changed, and what operators are left to decide

The concrete change is three image tags and a direct outreach round. GitLab says it contacted self-hosted gateway customers before publishing, and the advisory was released alongside the fixed images on the same day. For everyone else — GitLab.com, GitLab Dedicated, and self-managed instances pointed at a GitLab-hosted gateway — the fix had already been applied server-side and, on GitLab's account, nothing was required.

For a self-hosted operator, the decision is narrower and less comfortable than a normal patch cycle. There is no workaround for a gateway that cannot be moved immediately. There is no released method for establishing whether the host was compromised beforehand, which means the only retrospective option is the ordinary one: treat the container as a system whose integrity is unproven, and look for signs of execution outside its normal behaviour. And for gateways on 18.x or 19.1, the advisory names no target version at all — an omission The Hacker News reports and GitLab's notice does not address.

The archive's own classification is deliberately narrower than the vendor's. It records this entry as a vulnerability, at confidence A with the sources in agreement, not disputed, with no real harm recorded, and with a severity field of "high" against GitLab's and NVD's "critical". Those are answers to different questions: the score describes what the flaw would permit, and the archive's grade describes what is known to have happened. On the public record, nothing happened — no exploitation, no victims, no incident report. The value of the entry is that it documents, with a CVE number and a fixed version, exactly how a prompt template became a command line in the middleware that enterprise AI features depend on.