GitLab shipped fixes on 2 October 2026 for CVE-2026-90970, a 9.9 in the AI Gateway — the service that sits behind GitLab Duo and talks to the models. An authenticated user with access to the Duo Agent Platform could supply a crafted flow configuration, escape the prompt-template sandbox, and run arbitrary commands on the machine hosting the gateway.

Fixed releases are 19.2.4, 19.3.2 and 19.4.1. Affected are 18.1.6 up to 19.2.4, 19.3 up to 19.3.2, and 19.4 up to 19.4.1. GitLab's own hosted gateway was never exposed; this is a self-hosted problem.

The bug is older than the product

The NVD files it under CWE-1336: improper neutralisation of special elements used in a template engine. That is server-side template injection, and it has been a known class since long before anyone built an AI gateway.

The mechanism is always the same. A template engine exists to evaluate expressions and substitute values. If a string an attacker controls reaches the engine as template source rather than as data, the attacker is no longer supplying a value — they are supplying code the engine will run. Jinja2, the engine family involved here, is particularly rich in ways to walk from an innocuous object back to the Python runtime, which is why it ships a sandbox and why that sandbox has a long history of being escaped.

GitLab's flow configuration is user-supplied and was not sufficiently sanitised before reaching the engine. From there the path to command execution on the host is a well-trodden one.

What is new is where it lives

The reason to write about this rather than file it is that the condition which makes template injection possible has gone from an implementation mistake to a product requirement.

Letting users write prompt templates is the feature. An agent platform that does not let teams define their own flows, with their own placeholders filled from their own context, is not an agent platform. So the product deliberately accepts user-authored template source, deliberately evaluates it on the server, and places a sandbox between the two.

Which means the sandbox is now load-bearing in a way it was not when template injection was simply a bug. Every AI platform offering custom prompts, custom flows or user-defined agents has made the same architectural bet, and most of them are betting on the same handful of engines with the same escape literature behind them.

Authenticated is not reassuring here

The score stops at 9.9 rather than 10 because the attacker needs an account with Duo Agent Platform access. On a self-hosted GitLab that is a weaker constraint than it sounds.

Self-hosted GitLab is where an organisation's source code lives, and its user list is every developer, plus contractors, plus whatever automation holds a token. Duo access tends to be granted broadly, because the point of buying it is that people use it.

What sits on the other side matters more. The AI Gateway runs inside the environment that holds repositories, CI runners and the secrets those runners inject. Command execution there is not a foothold on a peripheral service. It is a foothold in the build system, which is the shortest path from one compromised developer account to everything that organisation ships.

This is the second GitLab flaw we have covered in weeks, after the request that read any file on the server. Different mechanism, same lesson about where the platform sits.

No exploitation reported, which is the window

Nothing published says this is being exploited. That is the useful part of the timing rather than a reason to wait.

Microsoft's report this week puts the median time from a vulnerability being discovered to being weaponised well below 24 hours, against 30 to 60 days of typical enterprise remediation. A 9.9 with a public advisory, a named bug class and a well-documented exploitation path for that class is not a flaw anyone should expect to stay theoretical for a month.

What to do

  • Upgrade the gateway to 19.2.4, 19.3.2 or 19.4.1 depending on your branch. If you run GitLab's hosted AI Gateway, there is nothing to do.
  • Until you have, review who holds Duo Agent Platform access and remove what is not being used. The vulnerability needs an account, and that is the one variable you control today.
  • Check what the gateway host can reach. If it shares a network with CI runners or can read runner secrets, the blast radius of a command execution bug there is your whole pipeline, and that is worth fixing independently of this CVE.
  • Look at your own custom flow configurations. The patch fixes the sanitisation; it does not tell you whether anyone wrote something unusual before it landed.

What is not established

  • Whether the flaw has been exploited. No reporting says so, and GitLab has not described any.
  • Who found it and how, which GitLab has not detailed publicly in what has been reported.
  • The exact escape technique used against the sandbox, which has not been published.
  • Whether the same pattern affects other parts of the Duo stack that accept user-authored templates.