GitLab has patched CVE-2026-90970, a critical vulnerability in its self-hosted AI Gateway that can allow an authenticated Duo Agent Platform user to escape the prompt-template sandbox and execute arbitrary operating-system commands on the gateway host. GitLab assigned the issue a CVSS score of 9.9, reflecting the fact that exploitation requires only low privileges and no user interaction once the attacker already has access to the Duo Agent Platform. The flaw affects self-hosted AI Gateway releases from version 18.1.6 onward, with fixed versions now available in 19.2.4, 19.3.2, and 19.4.1. GitLab.com, GitLab Dedicated, and self-managed GitLab instances that use GitLab’s hosted AI Gateway have already been patched and do not require customer action.

That deployment distinction is essential because the phrase “GitLab AI Gateway flaw” can easily sound broader than the actual exposure. The vulnerable component is the AI Gateway service, which organizations may choose to host themselves so that AI request and response data remains within their own infrastructure. Customers using GitLab-hosted gateway infrastructure are already protected. The urgent action is for organizations operating their own gateway containers or Helm deployments, particularly those allowing users to create or execute custom Duo Agent Platform flows.

The vulnerability exists in the way custom AI flows process prompt templates. GitLab says an authenticated user with Duo Agent Platform access can provide a specially crafted flow configuration that escapes the sandbox intended to contain template execution. Once that boundary is crossed, attacker-controlled template logic can reach the underlying host environment and execute arbitrary commands. In simplified form, the attack path becomes: authenticated Duo user → malicious custom flow → prompt-template processing → sandbox escape → command execution on self-hosted AI Gateway.

The technical significance is not that the AI model itself has somehow become capable of escaping into the operating system. This is a conventional application-security problem occurring inside an AI workflow. The system accepts user-controlled flow configuration, processes that configuration through a templating engine, and relies on a sandbox to prevent template expressions from reaching sensitive host objects or execution primitives. Once that sandbox boundary fails, the prompt-processing layer becomes a route into the server.

That distinction matters because “AI vulnerability” often invites unnecessary mystery. The underlying security principle is extremely familiar: untrusted template input must never gain access to host execution capabilities. Whether the input originated from a traditional web application, a CI configuration, a reporting engine, or an AI-agent flow does not change the fundamental issue.

The vulnerability is classified as CWE-1336, Improper Neutralization of Special Elements Used in a Template Engine, which places it in the broader family of server-side template injection and template-sandbox escape problems. These vulnerabilities are dangerous because templating systems frequently expose powerful objects, helpers, attributes, or references to the host language. A sandbox may initially prevent direct access to dangerous functionality, but attackers often search for less obvious object relationships that lead from harmless template features to underlying Python, JavaScript, or operating-system functionality.

GitLab’s advisory does not publish the exact exploit conditions or payload, which is sensible given the severity. It states that a crafted flow configuration can escape the prompt-template sandbox and reach arbitrary command execution, but it does not identify a particular user role beyond requiring Duo Agent Platform access. That means organizations should not assume the flaw is limited to full GitLab administrators. Any identity capable of exercising the relevant custom-flow functionality should be considered in the threat model until access requirements are more precisely documented.

The fact that exploitation requires authentication significantly changes the risk compared with an unauthenticated Internet-facing RCE, but it does not make the vulnerability minor. Developer platforms frequently have large user populations including internal developers, contractors, partners, automation identities, and service accounts. A compromised ordinary account that already has Duo Agent Platform permissions could potentially turn an application-level foothold into operating-system execution on the AI Gateway.

This creates a classic privilege-boundary problem. The attacker does not begin with operating-system access. They begin with legitimate application access. The vulnerability then converts that legitimate access into something the user was never intended to possess: command execution on the infrastructure hosting the AI service.

That is why the 9.9 rating is defensible despite the authentication requirement. The relevant progression is: low-privileged application identity → sandbox escape → host command execution → potential access to gateway secrets and connected systems. The security boundary being crossed is large.

A self-hosted AI Gateway is also a particularly sensitive target because it sits between GitLab and external or internally hosted language models. GitLab’s installation documentation says the gateway contains JWT signing and validation keys, connects to the GitLab instance, and communicates with model endpoints. Those credentials and connections should be treated as high-value assets. Compromise of the gateway could therefore have consequences beyond the container or virtual machine itself, depending on what secrets are available and how broadly the service can communicate.

The JWT signing keys deserve special attention. If an attacker gains command execution on the gateway, any signing material stored in environment variables, mounted secrets, configuration files, or the container runtime may become accessible. Compromise of signing keys can be more serious than compromise of one user password because cryptographic signing material may be used to create tokens that other components trust. The exact post-exploitation impact depends on how the deployment is configured, so defenders should avoid assuming that every compromise automatically enables impersonation. But these secrets should be considered exposed if host-level execution is confirmed.

The same reasoning applies to model-provider credentials. A self-hosted AI Gateway may possess API keys or service credentials required to communicate with internal or third-party model endpoints. If those secrets are stored on the gateway or injected into its runtime, an attacker with command execution may be able to retrieve them. That creates potential downstream risk involving unauthorized model access, consumption of paid compute, access to internal model services, or movement toward systems reachable from the gateway.

This is one reason AI infrastructure should not be treated as an isolated experimental layer. Once an AI gateway holds signing keys, API credentials, network access, and privileged integration with developer platforms, it becomes part of the organization’s identity and control plane.

CVE-2026-90970 is also notable because it is not the first critical template-related flaw GitLab has fixed in the AI Gateway this year. In February 2026, GitLab patched CVE-2026-1868, another CVSS 9.9 issue involving insecure template expansion in Duo Agent Platform flow definitions. That earlier flaw could also lead to denial of service or code execution on the gateway. Both vulnerabilities involve the same broad weakness class, CWE-1336.

That recurrence deserves attention. One critical template bug can be an implementation mistake. Two critical bugs in the same workflow family within the same year suggest that the templating and isolation model itself deserves deeper architectural review.

Security teams should therefore avoid treating this as simply another patch ticket. The broader question is whether untrusted flow definitions are being processed inside a sufficiently strong isolation boundary. Sandboxing inside the application runtime can be useful, but history repeatedly shows that language-level sandboxes are difficult to make perfect when they expose rich object models and dynamic evaluation.

A stronger architecture for truly untrusted workflow execution is to assume that the template or flow may eventually escape its application-level sandbox and then contain it using additional operating-system controls: separate containers, restricted Linux capabilities, read-only filesystems, seccomp profiles, minimal service accounts, network egress restrictions, and isolation from high-value secrets.

In other words, the security model should not depend on a single sentence that effectively says:

“The template sandbox will never fail.”

Security boundaries fail. Good architecture decides what happens afterward.

For self-hosted GitLab users, the immediate remediation is straightforward: upgrade the AI Gateway to 19.2.4, 19.3.2, or 19.4.1, depending on the maintained branch. The Gateway is distributed separately as a Docker image or Helm deployment, so updating the main GitLab application alone does not necessarily update the AI Gateway. Administrators need to verify the actual image or chart tag in use.

This separation creates an operational trap. An organization may look at its GitLab application version, conclude that GitLab itself is fully patched, and overlook an older AI Gateway container deployed separately months earlier. AI components increasingly have independent release cycles, images, dependencies, and maintenance requirements. Vulnerability management therefore needs to inventory them as separate software assets.

The advisory lists the following affected ranges: 18.1.6 and later before 19.2.4, 19.3 before 19.3.2, and 19.4 before 19.4.1. Releases from 18.1.6 through the 19.1 branch remain inside the affected range, while GitLab’s current maintenance policy provides fixes for the 19.2, 19.3, and 19.4 branches. The public advisory does not list a backported fixed release for older lines.

That creates a practical issue for organizations running older self-hosted gateway branches. If a deployment cannot move directly to one of the supported fixed versions because of compatibility or application-version constraints, administrators may need to accelerate a broader GitLab upgrade rather than wait for a patch that may never arrive for an unsupported branch.

GitLab does not list a workaround for customers unable to upgrade. That makes compensating controls more important until the fixed build can be deployed. Organizations should restrict which users can create or execute Duo Agent Platform flows, remove unnecessary access, review service-account permissions, isolate the AI Gateway from sensitive networks, and minimize secrets exposed to the gateway runtime. These controls do not remove the vulnerability, but they can reduce who is capable of reaching it and limit the damage if the sandbox is escaped.

The public information also does not provide a reliable indicator set for determining whether a gateway was previously exploited. GitLab’s advisory does not state that CVE-2026-90970 has been used in attacks, and CISA’s CVE assessment as of October 2 lists exploitation as none rather than active or publicly proven. That is an important boundary. This is a critical vulnerability, but currently there is no public evidence that attackers are exploiting it in the wild.

Organizations should therefore avoid describing this as an exploited zero-day unless new evidence emerges. Critical severity and active exploitation are separate facts, despite cybersecurity headlines occasionally treating them as synonyms because apparently one alarming adjective at a time was insufficient.

That said, self-hosted operators should still review recent gateway activity, particularly if untrusted or compromised user accounts had Duo Agent Platform access. Useful areas include unusual child processes from the AI Gateway container, shell invocation, unexpected outbound connections, abnormal filesystem writes, process execution inconsistent with normal gateway behavior, and suspicious flow configurations created before the upgrade.

Container-runtime telemetry can be particularly valuable. An AI Gateway normally exists to process requests, orchestrate flows, and communicate with GitLab and model services. It should not routinely spawn sh, bash, package managers, network reconnaissance tools, or arbitrary system utilities. Those behaviors can provide stronger post-exploitation indicators than trying to identify the exact malicious template payload.

Organizations should also rotate sensitive gateway credentials if there is evidence of compromise. This includes JWT signing or validation keys, model-provider API keys, service credentials, GitLab integration tokens, and other secrets available inside the gateway runtime. Rebuilding the container without rotating stolen secrets may remove the attacker’s process while leaving their credentials perfectly usable.

The vulnerability also raises a broader concern for enterprise AI platforms: custom agent and workflow definitions increasingly behave like code even when users perceive them as configuration. A flow may appear to be a sequence of prompts and actions, but behind that interface it can drive templating engines, tool invocation, network requests, file handling, and dynamic data expansion. Once users can influence those components, the configuration itself becomes an application-security boundary.

Security programs therefore need to classify AI workflows appropriately. They are not merely prompts. They can be executable logic with access to tools and infrastructure.

The distinction matters for secure development reviews. Traditional application-security programs know to inspect APIs, SQL queries, file uploads, serializers, and template engines. AI workflow platforms add new forms of user-controlled configuration that may eventually reach those same dangerous primitives. The names change. The vulnerability classes remain depressingly familiar.

The full attack path can be summarized as: GitLab user obtains Duo Agent Platform access → creates or modifies malicious custom flow → crafted prompt-template configuration reaches vulnerable sandbox → template escapes isolation → commands execute on self-hosted AI Gateway → gateway secrets and connected infrastructure potentially become accessible.

The first half sounds new because it involves AI agents.

The second half is conventional server compromise.

That is perhaps the most useful lesson from CVE-2026-90970.

Organizations should resist treating AI security as a completely separate discipline governed by mysterious new rules. Prompt injection, agent permissions, and model behavior certainly create new challenges, but AI systems still sit on ordinary operating systems, use ordinary credentials, parse ordinary templates, expose ordinary APIs, and fail in many of the same ordinary ways.

Here, the model did not need to become malicious.

The template engine simply needed to stop containing the user.

For self-hosted GitLab Duo environments, the priority is therefore clear: update the AI Gateway, review who can create flows, minimize secrets and network privileges available to the gateway, and treat AI workflow definitions as untrusted executable input rather than harmless configuration.

The vulnerability is a useful warning for the wider AI industry as well.

As agent platforms gain the ability to define workflows and execute tools, every sandbox separating user-controlled logic from the host becomes a critical security boundary.

And if that sandbox fails, the AI Gateway stops being a gateway to the model.

It becomes a gateway to the server.

A critical flaw in GitLab's AI Gateway could let a logged-in user with Duo Agent Platform access run commands on the gateway under certain conditions, GitLab said in an advisory. The gateway is the service that connects a GitLab instance to AI models, and only organizations that host their own gateway need to act. The flaw is fixed in gateway versions 19.2.4, 19.3.2, and 19.4.1. The flaw

Source: GitLab Patches Critical 9.9 AI Gateway Flaw Allowing Command Execution on Self-Hosted Servers via The Hacker News — published 02 Oct 2026.