GitLab has issued urgent fixes for a near-maximum-severity weakness in its self-hosted AI Gateway, warning that a user with limited but valid access could cross a template-processing boundary and run commands on the underlying service. The vulnerability, tracked as CVE-2026-90970, has a CVSS score of 9.9 and affects infrastructure supporting GitLab Duo AI features.

The issue is especially important for organizations that operate the gateway inside their own environment. Although exploitation requires an authenticated account with access to the Duo Agent Platform, the attack itself is network-accessible, needs no victim interaction and is considered low complexity. A successful compromise could affect the confidentiality, integrity and availability of the gateway and the systems or model backends it can reach.

How the sandbox escape works

The flaw lies in the handling of custom flow prompt templates. Those templates are supposed to be processed inside a restricted sandbox so that user-controlled instructions cannot become operating-system commands. GitLab says a specially constructed flow configuration can escape that boundary, allowing arbitrary commands to execute on the AI Gateway.

This distinction matters. The risk is not merely that an attacker might manipulate an AI response or influence a model prompt. The vulnerable processing path can reach the service host itself. From there, the practical impact would depend on the gateway’s privileges, accessible secrets, network routes and connections to model services or other internal resources.

GitLab has not disclosed a working exploit, named the underlying template engine or reported attacks in the wild. The company credited researcher invisiblemeerkat with responsibly reporting the problem. Those details lower the immediate evidence of active abuse, but they do not reduce the urgency of a flaw that can convert a relatively constrained application role into command execution.

Affected versions and available fixes

Affected AI Gateway versions begin with 18.1.6 and extend through releases earlier than 19.2.4. The 19.3 branch is vulnerable before 19.3.2, while the 19.4 branch is affected before 19.4.1. GitLab released AI Gateway 19.2.4, 19.3.2 and 19.4.1 to close the issue.

Administrators should check the deployed gateway component rather than assume the main GitLab instance version tells the full story. Customers using GitLab.com, GitLab Dedicated, or self-managed GitLab connected to a GitLab-hosted AI Gateway are already protected because GitLab updated its hosted infrastructure. The required action falls on customers running their own affected gateway.

Why self-hosted AI infrastructure needs attention

Self-hosting gives enterprises greater control over AI requests and model backends, but it also places patching, image management and network isolation in the customer’s hands. AI orchestration services frequently sit between developer identities, source-code context, internal tools and external models. That position can make a compromised gateway a valuable pivot point even when the initial attacker account is not highly privileged.

Security teams should treat access to Duo Agent Platform features as meaningful application privilege. Review who holds that access, remove stale accounts and inspect authentication and gateway logs for unusual flow creation, template errors or command-like content. Any unexplained child processes or outbound connections from the gateway should receive prompt investigation.

Recommended response

• Upgrade immediately to AI Gateway 19.2.4, 19.3.2, 19.4.1 or a later supported release.
• For container deployments, verify the new image digest instead of relying only on a mutable tag.
• For Kubernetes or Helm installations, ensure image caching and pull policies do not leave old code running.
• Restrict unnecessary outbound traffic while preserving documented gateway dependencies.
• Review Duo Agent Platform permissions and investigate suspicious template activity.

After upgrading, operators should run health checks and confirm that every replica uses the patched image. Network controls and least privilege can reduce exposure, but neither substitutes for replacing the vulnerable component. Given the severity and the gateway’s position in AI-enabled development workflows, patch validation should be handled as part of the incident-response process rather than routine maintenance.

Source: Cyber Security News, reporting on GitLab’s security release.