GitLab's AI Gateway got its second 9.9 of the year. Patch the gateway, not just GitLab.

On October 2, GitLab disclosed CVE-2026-90970, a critical flaw in its self-hosted AI Gateway. An authenticated user with Duo Agent Platform access can submit a crafted custom flow configuration, escape the prompt-template sandbox (a Jinja2 template-engine weakness, CWE-1336), and execute arbitrary commands on the gateway host. CVSS 9.9. Network-reachable, low complexity, low privileges, no user interaction.

The uncomfortable part is the repetition. This is the second CVSS 9.9 in this component this year. In February, GitLab patched CVE-2026-1868, another 9.9, also reachable through a crafted flow definition, in the same template-engine weakness class. Two near-maximum-severity bugs in eight months, in the same component, through the same mechanism. That is not two bugs. That is a design that keeps producing this bug.

Who has to act: only organizations that self-host the AI Gateway. GitLab.com, GitLab Dedicated, and self-managed instances pointed at GitLab-hosted gateways are already patched server-side. If you run your own gateway, and many regulated shops do precisely to keep AI request and response data inside their own environment, the patching is on you.

The critical operational detail, and the one most likely to be missed: the AI Gateway is a separately versioned component. Upgrading GitLab CE or EE does not remediate this. You must update the gateway image or Helm chart to 19.2.4, 19.3.2, or 19.4.1 depending on your branch. Affected versions run from 18.1.6 up to but excluding 19.2.4, plus the 19.3 and 19.4 branches before their patched releases. GitLab has listed no workaround, so the upgrade is the mitigation.

Do three more things while you are in there. First, review who has Duo Agent Platform access and, specifically, who can author or modify custom flow configurations. This vulnerability reframes flow authoring as a privileged action: whoever can write a flow is one template-engine bug away from command execution on infrastructure that brokers your AI traffic. Second, examine recent flow configuration changes for anything unexpected or unapproved. There is no evidence either way about whether gateways were probed before patching, so treat the pre-patch window as unknowable and review the configs. Third, note what the gateway holds: it brokers requests between your GitLab instance and your chosen model providers, which makes it a concentration point for API keys, prompt templates, and code snippets sent for AI analysis.

The broader lesson is one this publication keeps finding in AI infrastructure: the component that connects your agents to models is the component attackers will live in. A sandbox around a template engine is a security boundary drawn in exactly the material attackers know how to cut. Treat agent-workflow authoring like code deployment, with the same review, the same access controls, and the same suspicion of anything new.

Step back and the pattern is also a buying signal. Two near-maximum bugs in eight months in the box that brokers your model access should change how you evaluate AI infrastructure from any vendor: ask which components sit between your code and the model, how each one is sandboxed, and how fast the vendor ships when a sandbox breaks. The template engine will get a third test. What you want is an architecture that assumes the sandbox fails, with the gateway's secrets, keys, and data segmented so that one escape does not become a skeleton key.