On October 2, 2026, GitLab disclosed CVE-2026-90970, a critical vulnerability rated CVSS 9.9 in its self-hosted AI Gateway. Under certain conditions, an authenticated user with Duo Agent Platform access could escape the gateway’s prompt-template sandbox through a specially crafted flow configuration, potentially executing arbitrary commands on the gateway. Affected versions include AI Gateway releases from 18.1.6 before 19.2.4, 19.3 releases before 19.3.2, and 19.4 releases before 19.4.1. GitLab has released fixes in versions 19.2.4, 19.3.2, and 19.4.1.
The AI model was not the weak point. The flaw was in the software that turns workflow configuration into prompts, and that software deserves the same scrutiny as anything else you run in production.
The immediate lesson is familiar to application security engineers: a security boundary is only as strong as its enforcement. But the implications extend beyond a single vulnerability. As AI agents, workflows, and automation become embedded in development platforms, organizations must reconsider how they isolate executable inputs, control access to infrastructure, and secure the components supporting these capabilities.
When configuration becomes executable
The flaw is in how the gateway renders custom flow prompt templates within the GitLab AI Gateway. These templates combine text with expressions evaluated against a context.
Sandboxing is intended to restrict what a template can access and prevent its execution from reaching sensitive host capabilities. Its effectiveness depends on how the template engine evaluates expressions and how the surrounding environment enforces those restrictions.
GitLab's advisory describes a flaw that could allow an authenticated user with Duo Agent Platform access to escape this boundary using a specially crafted flow configuration, resulting in command execution on the AI Gateway. The vulnerability is classified as CWE-1336, Improper Neutralization of Special Elements Used in a Template Engine.
The vulnerability illustrates the limits of relying on a sandbox as the primary boundary between user-controlled configuration and the environment processing it. Although template engines can restrict access to sensitive capabilities, those restrictions must withstand the inputs the engine evaluates. GitLab’s advisory does not identify the specific mechanism used to escape the sandbox, but the broader lesson is clear: systems that process user-defined templates and workflow configurations need strong execution boundaries and additional controls to limit the impact if those boundaries fail.
There is also a relevant precedent. In February 2026, GitLab addressed CVE-2026-1868, another critical AI Gateway vulnerability involving the insecure expansion of user-supplied data in custom flow definitions. That vulnerability could cause denial of service or enable code execution on the gateway. Both vulnerabilities are classified under CWE-1336, although the available advisories do not establish a common root cause.
The recurrence highlights a broader engineering challenge: when platforms allow users to define AI workflows, processing those definitions becomes a security-critical operation.
Why AI development platforms need stronger isolation
AI development platforms often need to process workflows, templates, and configurations supplied by users or generated through automated processes. These inputs should not automatically inherit the privileges of the services that process them.
Sandboxing is one layer of defense, but it should not be the only one. Execution environments need clearly defined boundaries, and the permissions available within them should be limited to what the task requires. If a sandbox escape occurs, the surrounding controls should constrain what an attacker can access or execute.
Three engineering principles follow:
Treat user-controlled configurations as untrusted inputs. Authentication establishes who can access a platform, not whether every configuration supplied by an authenticated user is safe. Template engines and workflow processors must validate inputs, constrain expression evaluation, and prevent user-controlled content from accessing unintended capabilities.
Do not rely on sandboxing as the only control. Execution should operate with the minimum privileges necessary. Untrusted processing should be isolated from sensitive credentials, privileged services, and unnecessary network access. A failure in one control should not automatically expose the entire host.
Limit the impact of a successful escape. Commands executed through this flaw run with the permissions available to the gateway process, including access to its filesystem, network connections, and mounted secrets. These permissions can be restricted to reduce the potential impact of a compromise. Run the gateway as a non-root user with a read-only root filesystem and no unnecessary Linux capabilities. Restrict outbound traffic to the model providers and GitLab instance the gateway needs to reach. Mount only the credentials required for its operation. Broadly privileged credentials can turn a gateway compromise into a wider compromise of connected systems.
The gateway is part of the development attack surface
An AI gateway does not operate in isolation. Depending on its deployment and configuration, it may have access to credentials, internal services, APIs, and network resources needed to support AI workflows. The potential consequences of a compromise therefore depend not only on the original vulnerability but also on what the affected service can reach.
Engineering teams need visibility into these connections and the software components supporting them. Knowing which gateway versions are deployed is important, but so is understanding the permissions, secrets, dependencies, and infrastructure associated with each deployment.
The software underneath AI matters too
Application-level protections are only one part of the security equation. The software components and container images used to deploy AI infrastructure introduce their own risks. Vulnerable dependencies, unnecessary packages, and limited visibility into deployed software can expand the attack surface.
These risks are distinct from the template-engine vulnerability in GitLab's AI Gateway. A hardened container image would not, by itself, prevent an application-level sandbox escape. It can, however, reduce other risks by minimizing the software footprint and helping teams manage vulnerabilities in the components they deploy. Maintaining component inventories and verifying artifact provenance provide additional visibility into the software supporting these environments.
These controls serve different purposes. Isolation constrains execution. Least privilege limits access. Vulnerability management identifies known weaknesses. Provenance verification establishes evidence about where software came from and how it was built.
Securing AI infrastructure requires these layers to work together. No single control substitutes for the others.
What engineering teams should do now
For organizations running a self-hosted GitLab AI Gateway, remediation should come first. GitLab has released fixes in AI Gateway versions 19.2.4, 19.3.2, and 19.4.1. Administrators should consult the official GitLab security advisory to confirm the affected version ranges and follow the appropriate upgrade path. GitLab-hosted AI Gateways have already been patched, so customers using those gateways do not need to take action for this vulnerability.
Beyond patching, engineering and security teams should review the broader architecture surrounding AI development services:
- Inventory AI infrastructure. Identify self-hosted gateways, agent services, workflow processors, and other components that handle user-defined configurations.
- Review exposure and access. Examine execution boundaries, service permissions, connected systems, and credentials accessible to affected deployments.
- Look for signs of prior compromise. Review gateway logs and available telemetry for unexpected child processes, suspicious outbound connections, and unapproved changes to flow configurations, particularly templates or expressions that cannot be traced to an authorized change.
- Verify the underlying software. Track component versions, identify known vulnerabilities, and establish controls for vulnerability remediation and artifact provenance.
GitLab’s advisory does not establish whether CVE-2026-90970 was exploited before the fixes became available. The Hacker News reported that CISA’s October 2 assessment recorded exploitation as “none.” However, this assessment does not establish whether a particular deployment was compromised. Patching closes the vulnerability, but it does not reverse any activity that may have occurred before remediation.
Where verification fits
AI security discussions often focus on model behavior, prompt injection, and the risks of AI-generated code. But the GitLab vulnerability highlights another part of the problem: the software infrastructure that makes AI capabilities possible.
Securing AI infrastructure requires both application-level controls and a verifiable software foundation. Organizations need to enforce execution boundaries and least privilege while reducing vulnerabilities in the components they deploy and establishing verifiable provenance for the artifacts they run.
This is the principle behind CleanStart's approach to software security: verification should begin with the software itself. From container images to open-source libraries, knowing what goes into a software environment, understanding how it was built, and verifying its integrity are essential to reducing inherited risk. Security controls at runtime remain necessary, but they are stronger when the software entering the environment is already verifiable.
AI is software. The infrastructure that powers it is software, too. Neither should be trusted without verification.
Next step: if you run a self-hosted AI Gateway, upgrade first. Then ask a harder question of everything else you deploy: is what you’re running what you think you’re running? Understanding image provenance →
