CVE-2026-90970 (CVSS 9.9): GitLab AI Gateway Sandbox Escape Lets Attackers Execute Commands on Self-Hosted Servers

Your DevOps pipeline just became your biggest attack surface. A newly patched critical vulnerability in GitLab’s AI Gateway — rated CVSS 9.9 — allows an authenticated user to escape a prompt-template sandbox and execute arbitrary commands on the underlying server. If your organisation runs a self-hosted GitLab AI Gateway and hasn’t yet upgraded, you are exposed to a near-maximum severity remote code execution risk right now.

What Is the GitLab AI Gateway — and Why Does It Matter?

GitLab AI Gateway is the microservice that bridges a self-hosted GitLab instance to large-language-model (LLM) back-ends powering features such as GitLab Duo — code completion, vulnerability explanation, root-cause analysis, and the newer Duo Agent Platform that allows AI workflows to take automated actions inside a repository. Think of it as the AI “middleware” sitting between your developers’ IDE and the LLM APIs.

Because the gateway handles live code, CI/CD pipelines, merge-request context, and — crucially — has shell-level access to the host it runs on, a code-execution vulnerability here is not a theoretical risk. An attacker who compromises the gateway controls the build environment. In a modern software-supply-chain attack scenario, that translates to tainted binaries reaching production.

India has one of the world’s fastest-growing DevOps user bases. Major IT services firms, large public-sector banks, fintech start-ups, and DRDO-tier defence contractors have adopted GitLab for source control and CI/CD. The ones that self-host to keep code on-premises — a common compliance requirement under RBI and MeitY guidelines — are exactly the organisations affected by this vulnerability.

Technical Breakdown: How the Sandbox Escape Works

The vulnerability is catalogued under CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine. In plain language: GitLab AI Gateway uses Jinja2-style placeholders to process user-supplied flow configuration data for Duo Agent Platform custom workflows. The processing code failed to sanitise those placeholders adequately, allowing a crafted value to break out of the sandbox context.

Jinja2 (and Jinja2-inspired) template engines are notoriously prone to this class of bug. When user input is interpolated directly into a template string and then evaluated, an attacker can inject template syntax — for instance, server-side template injection payloads that call Python’s built-in functions — to reach the underlying interpreter and execute OS-level commands. The mechanism here is effectively a Server-Side Template Injection (SSTI) leading to Remote Code Execution.

Attribute	Detail
CVE ID	CVE-2026-90970
CVSS v3.1 Score	9.9 Critical
CVSS Vector	AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE	CWE-1336 — Template Engine Injection
Attack Vector	Network, Low Complexity, Low Privilege, No User Interaction
Scope Change	Changed (sandbox → host OS)
Affected Versions	AI Gateway ≥ 18.1.6, < 19.2.4; ≥ 19.3.0, < 19.3.2; ≥ 19.4.0, < 19.4.1
Fixed In	19.2.4, 19.3.2, 19.4.1 (released 2 October 2026)
Reported By	invisiblemeerkat (responsible disclosure via GitLab Bug Bounty)
Exploitation Status	No confirmed in-the-wild exploitation (as of 3 October 2026)

The scope change (S:C in the CVSS vector) is what pushes the score to 9.9. It means the impact extends beyond the vulnerable component itself — an attacker who escapes the Python template sandbox lands on the host OS of the AI Gateway, with whatever privileges the gateway process runs under. In most Docker or Kubernetes deployments, that process runs as a non-root user — but still has access to model tokens, API credentials, internal network segments, and potentially CI/CD secrets mounted at runtime.

Who Is Exposed?

Exposure is limited to self-hosted GitLab AI Gateway deployments where:

• The Duo Agent Platform feature is enabled.
• At least one user account has been granted “Duo Agent Platform access” (a role-based permission).
• The gateway is running an affected version (18.1.6 through the patch boundary).

Critically, GitLab.com, GitLab Dedicated, and GitLab Self-Managed customers who use GitLab’s hosted AI Gateway (the default) are not affected — GitLab already patched those instances. The risk is specific to organisations that spun up their own AI Gateway — typically for data-residency, regulatory, or air-gapped reasons.

An insider threat or a phishing attack that compromises a developer account with Duo access is sufficient. The attacker does not need admin privileges. That is the scenario that should concern every CISO in the room: a single developer credential leak translates to OS-level shell access on the AI Gateway host.

What You Should Do Right Now — Sanjay’s Expert Guidance

In my thirty years working with enterprise networks across India — from banking NOCs to multi-site government deployments — I have seen templates turn into attack surfaces more times than I care to count. Template injection is not a new class; what is new is its sudden appearance at the boundary between your DevOps toolchain and AI back-ends. Here is the prioritised response plan:

1. Patch immediately. For Docker deployments: stop the container (docker stop gitlab-ai-gateway), pull the patched image tag (self-hosted-v19.4.1-ee), and restart. For Helm: update the image.tag in your chart values to the patched release and roll the deployment. There is no workaround that substitutes for patching.
2. Audit Duo Agent Platform permissions. Run an access review and revoke Duo Agent Platform access from any account that does not require it for active work. Apply least-privilege to this feature the same way you would any privileged role — treat it like admin access, not a convenience toggle.
3. Review recent flow configurations. Examine AI Gateway flow configuration logs from the past 30 days for unexpected or unapproved template submissions. Anomalous flow payloads with Python-style expressions (underscores in identifiers, __class__, __import__, os.popen, subprocess) are the signatures to look for.
4. Apply zero-trust segmentation to the gateway. The AI Gateway should live in a dedicated network segment with outbound rules restricted to the LLM API endpoints only. No lateral-movement paths to your CI/CD infrastructure, secret stores, or code repositories. This is the zero-trust posture I advocate for every enterprise — and its practical implementation with FortiGate and FortiAuthenticator applies here as much as it does on the campus floor.
5. Enable audit logging and alerting. GitLab’s Audit Events API logs flow configuration submissions. Feed those events into your SIEM and alert on any submission from an account that has not previously submitted a flow, or any submission outside business hours.
6. Update your threat model. AI tooling components are production infrastructure. They carry API keys, model tokens, and — in agentic workflows — the ability to commit code and trigger deployments. A compromised AI Gateway is a compromised CI/CD pipeline. Your next penetration test should explicitly scope these components.

For reference, the Kiteworks RCE earlier this week followed a similar pattern: a misconfigured processing layer at an integration boundary. The lesson is consistent — wherever user-supplied data meets a processing engine at the edge of your environment, that seam deserves the same rigour as a firewall rule.

The Broader Signal: AI Features Are Your New Attack Surface

CVE-2026-90970 is not an isolated incident. It is a preview of the vulnerability class that will define the next two years of enterprise security. As organisations rush to deploy AI-assisted development tools, code-review bots, and agentic workflows, they are introducing new components — AI Gateways, vector databases, embedding pipelines, LLM proxies — into environments that were designed long before those components existed. Each of these components:

• Processes externally influenced data (code, natural-language prompts, repository content).
• Runs with significant internal trust (access to secrets, code, APIs).
• Is updated on a separate release cadence from the core platform.
• Is rarely included in traditional vulnerability management scope.

The full disclosure from The Hacker News, Security Affairs’ technical analysis, and the official GitLab Security Advisory all underscore the same point: treat AI middleware the way you treat any other privileged infrastructure service — with dedicated patching SLAs, network segmentation, access control reviews, and inclusion in your vulnerability management programme.

---

Frequently Asked Questions

Does this affect GitLab.com or GitLab SaaS customers?

No. GitLab patched its hosted AI Gateway instances before the public disclosure on 2 October 2026. Only organisations that run a self-hosted AI Gateway — deploying the open-source or EE component themselves on Docker, Kubernetes, or bare metal — are at risk. If you are unsure whether you run a self-hosted gateway, check whether you have deployed the gitlab-ai-gateway container image in your own environment.

Is there an active exploit or PoC in the wild?

As of 3 October 2026, GitLab and CISA report no confirmed in-the-wild exploitation. However, the attack mechanism (Server-Side Template Injection) is a well-understood and heavily documented class, with public proof-of-concept payloads available for Jinja2 engines. The window between disclosure and weaponisation for SSTI vulnerabilities is historically short — measured in days, not weeks. Do not rely on the current absence of exploits as a reason to delay patching.

What is the minimum privilege level required to exploit CVE-2026-90970?

An attacker needs an authenticated GitLab user account with Duo Agent Platform access. This is a role-based permission that must be explicitly granted; it is not the default for standard Developer or Maintainer roles. However, in organisations that have broadly enabled Duo for all developers, the privilege bar is effectively any compromised developer account.

Can a firewall or WAF block exploitation?

A WAF with SSTI detection signatures can flag certain payload patterns, but it is not a substitute for patching. Jinja2 payloads are easily obfuscated, and the gateway API endpoint processes legitimate JSON that may structurally resemble an attack payload. Network-layer controls — restricting who can reach the AI Gateway API at all — are a more reliable mitigation while you schedule the patch window. Use both, but prioritise the patch.

---

CVE-2026-90970 is a wake-up call for every organisation running AI tooling inside its DevOps environment. The vulnerability is critical, the patch is available, and the attack class is well understood by offensive researchers. The question is simply whether your team patches in the next 24 hours or waits until an incident forces the issue.

If you are not certain whether your environment is exposed — or if you want an independent review of how your AI toolchain components are segmented, permissioned, and monitored — reach out for a security assessment. With three decades of enterprise network and security experience across Indian and global enterprises, P J Networks can map your exposure and give you a clear remediation roadmap.