GitLab Patches a Second Critical Template Flaw in Its Self-Hosted AI Gateway Within Eight Months

GitLab disclosed a critical flaw in its AI Gateway on Friday, October 2, that, “under certain conditions,” could have allowed an authenticated user with Duo Agent Platform access to “escape the prompt template sandbox via a specially crafted flow configuration” and run commands on the gateway. The bug, CVE-2026-90970, scores 9.9 on CVSS 3.1, and GitLab says only customers who run their own gateway need to act, because the gateways it hosts are already fixed. It is the second critical template flaw GitLab has fixed in the gateway this year, and GitLab has not published how this one works.

The fixed releases are AI Gateway 19.2.4, 19.3.2 and 19.4.1. The advisory lists no workaround and no way to tell whether a gateway was attacked before it was updated.

What GitLab has confirmed

GitLab’s advisory titles the issue “Improper Neutralization issue in custom flow prompt template impacts AI Gateway” and rates it Critical, with a CVSS 3.1 score of 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Read out, that is a network attack of low complexity that needs low privileges and no user interaction, has a changed scope, and has high impact on confidentiality, integrity and availability. The NVD record, published the same day, carries GitLab’s score as a secondary score and lists the weakness as CWE-1336, improper neutralization of special elements used in a template engine. It was still marked “Awaiting Analysis” when this was written. The advisory thanks a reporter who goes by invisiblemeerkat for responsible disclosure.

The advisory is short. It does not describe the “certain conditions,” name a template engine, list a workaround or say how to check a gateway for earlier abuse. The affected and fixed versions are gateway versions:

GitLab lists fixed builds only in the 19.2, 19.3 and 19.4 lines. Its install guide tells administrators to use the gateway image whose tag matches their GitLab minor version (“If your GitLab version is vX.Y.*-ee, use the AI Gateway image with the latest self-hosted-vX.Y.*-ee tag”), so a gateway on a line older than 19.2 has no fix of its own in the advisory, and the advisory does not say whether a 19.2.4 gateway works with an older GitLab release. The Hacker News flagged the same gap.

Who needs to act

GitLab says customers on GitLab.com, GitLab Dedicated and GitLab Self-Managed instances that use a GitLab-hosted gateway “are protected and do not need to take action.” The company had already fixed the gateways it runs by the time of the advisory.

That leaves self-hosted installations, and the exposed organizations are by definition the ones that chose self-hosting. GitLab’s documentation pitches the option as a way to “keep all request and response data in your own environment, avoid external API calls, and manage the full lifecycle of requests to your LLM backends.” GitLab says it “conducted targeted outreach to Self-Hosted AI Gateway customers prior to this release post.” It does not say how many customers run a gateway of their own. BleepingComputer notes that the platform has “over 30 million registered users,” which is not a measure of that population.

The advisory says only that the attacker must be an “authenticated user with Duo Agent Platform access” and names no role. GitLab’s documentation on custom flows says creating one takes the Maintainer or Owner role for the project, running one takes at least the Developer role with the platform turned on for the project, and public flows are visible to anyone on the instance and can be enabled in any project that meets the prerequisites. The advisory does not say which of those routes the bug needs, so the roles are context and not a boundary to rely on.

What a self-hosted gateway holds

The install guide has administrators run one container that serves both the AI Gateway (HTTP on port 5052) and the Duo Agent Platform service (gRPC on port 50052). It also has them hand that container the JWT signing keys as environment variables: “When you host your own AI Gateway, you must generate a signing key pair and pass the keys to the service as environment variables.” The guide says the keys “must be treated as sensitive credentials.”

The advisory says the flaw leads to “arbitrary command execution on the AI Gateway.” Commands that run inside that container could read its environment, which is where the guide puts the keys. GitLab does not say what an attacker could reach after a successful escape. The vector’s changed scope marks impact beyond the vulnerable component, without saying where.

The second template flaw in under eight months

GitLab’s page of other patch release notes lists two AI Gateway releases titled “Critical Patch Release,” and they are 238 days apart. The first, on February 6, fixed CVE-2026-1868. The two flaws share a severity, a CVSS vector, a weakness class and an entry point, a flow definition run by a logged-in user:

GitLab did publish the mechanism for February’s flaw. Its public tracking issue, which NVD lists as a reference for CVE-2026-1868, says the gateway renders its Jinja2 templates through one global SandboxedEnvironment: “When HumanMessage objects (from LangChain) are passed as template variables, attackers can call the parse_raw() method on those objects to deserialize pickled payloads, leading to arbitrary code execution.” The sandbox, it says, “does not block method calls on objects.” The proof of concept in the issue put the payload in a flow’s prompt template and, according to the issue, was the configuration used to run commands on staging.gitlab.com.

The technique was public before February. The issue says the bug was found by building on research into a similar attack on LangSmith, and that January write-up says the “jinja2 formatter could achieve remote code execution by exploiting Pydantic’s deprecated parse_raw method with pickle deserialisation,” a case of “bypassing Jinja2’s sandbox by calling methods that internally perform unsafe operations.” Jinja’s own documentation says the sandbox “can be used to render untrusted templates,” and also that “the sandbox alone is not a solution for perfect security.” Its advice to developers is direct: “Pass only the data that is relevant to the template. Avoid passing global data, or objects with methods that have side effects.”

GitLab has not said whether the October flaw works the same way. Its advisory names no template engine and does not mention February’s flaw, and the tracking issue that NVD cites for CVE-2026-90970, work item 628842 in GitLab’s main project, displayed no issue details to an anonymous visitor when this was written. The advisory gives no date for publishing technical detail.

Exploitation status

GitLab’s advisory does not say whether the flaw has been used in attacks. Decision-point data that CISA added to the NVD record on October 2 rates exploitation as none, the flaw as not automatable and its technical impact as total. Neither CVE appears in CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.02), which holds five GitLab entries. The newest is CVE-2026-85706, the maximum-severity path traversal flaw we covered last month, a bug in GitLab’s core product and a different weakness class from the gateway’s template flaws.

What administrators can do now

1. Find out who hosts your gateway. If your instance uses GitLab’s hosted gateway, GitLab says no action is needed.
2. Update a self-hosted gateway to 19.2.4, 19.3.2 or 19.4.1, using the image tag that matches your GitLab minor version, as the install guide describes.
3. If the gateway is older than 19.2, the advisory lists no fix for your line. Ask GitLab which upgrade path it recommends before assuming a newer gateway image will work with an older instance.
4. Review who can author flows. The advisory does not say which roles the attack needs, so a review of custom flows and of Maintainer and Owner assignments reduces exposure but is not a mitigation GitLab has endorsed. February’s public proof of concept hid its payload in a flow’s prompt template, and the public record does not show where this month’s sits.
5. Treat the gateway’s signing keys as credentials. GitLab does not say rotation is required. If you cannot rule out misuse before the update, rotating them is a judgment worth making deliberately.

Teams that build their own sandboxes for user-authored workflows can compare approaches with our Wasmtime tutorial, which runs untrusted plugin code in a WebAssembly sandbox that can call only the host functions it is explicitly given.