GitLab has patched one of the more interesting AI infrastructure vulnerabilities disclosed in 2026. CVE-2026-90970 affects the GitLab AI Gateway and can, under specific conditions, allow an authenticated user with access to the GitLab Duo Agent Platform to escape a prompt-template sandbox using a specially crafted flow configuration. The security boundary does not fail merely inside an LLM conversation. According to GitLab, successful exploitation can end with arbitrary command execution on the AI Gateway itself.
That distinction makes CVE-2026-90970 far more significant than its “prompt template” wording might initially suggest.
GitLab assigned the vulnerability a CVSS v3.1 score of 9.9, Critical, with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The affected component is GitLab AI Gateway, and GitLab has released fixed versions 19.2.4, 19.3.2, and 19.4.1. GitLab says customers operating affected Self-Hosted AI Gateway installations should upgrade immediately. GitLab-hosted AI Gateways have already received the fix, meaning GitLab.com, GitLab Dedicated, and Self-Managed deployments that rely on GitLab’s hosted gateway do not need to patch their own gateway for this particular issue. GitLab Docs
The CVE was published on October 2, 2026 and is classified as CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine. GitLab credited HackerOne researcher invisiblemeerkat with responsibly disclosing the vulnerability. OpenCVE
At the time of writing on October 3, 2026, there is no reliable public evidence of exploitation in the wild and no confirmed public proof-of-concept exploit identified in the major public trackers reviewed for this article. CVE-2026-90970 is also not currently listed in the CISA Known Exploited Vulnerabilities catalog. That status should not be confused with low risk: the technical consequence documented by GitLab is still host-level command execution, and disclosure of the affected feature and vulnerability class gives researchers and attackers a useful starting point for independent analysis. Feedly
CVE-2026-90970 at a Glance
| Detail | CVE-2026-90970 |
|---|---|
| Product | GitLab AI Gateway |
| Component | Custom flow prompt template processing |
| Vulnerability class | CWE-1336, template engine injection |
| Severity | Critical |
| CVSS v3.1 | 9.9 |
| Attack vector | Network |
| Attack complexity | Low |
| Privileges required | Low |
| User interaction | None |
| Result | Prompt template sandbox escape and arbitrary command execution |
| Attacker requirement | Authenticated user with Duo Agent Platform access |
| Affected | 18.1.6 to before 19.2.4 |
| Affected | 19.3 to before 19.3.2 |
| Affected | 19.4 to before 19.4.1 |
| Fixed | 19.2.4, 19.3.2, 19.4.1 |
| Researcher | invisiblemeerkat |
| Publicly confirmed exploitation | None identified as of October 3, 2026 |
The most important phrase in GitLab’s advisory is not simply “prompt template.” GitLab explicitly states that a crafted flow configuration can allow a qualifying authenticated user to escape the prompt template sandbox, ultimately leading to arbitrary command execution on the AI Gateway. GitLab Docs
That moves CVE-2026-90970 into a very different category from ordinary prompt injection.
What Is the GitLab AI Gateway?
Understanding CVE-2026-90970 requires understanding where the AI Gateway sits.
GitLab describes the AI Gateway as a standalone service providing access to AI-native GitLab Duo functionality. Organizations using GitLab’s managed infrastructure can communicate with a GitLab-hosted gateway, while GitLab Self-Managed customers can deploy a self-hosted AI Gateway when they want the AI processing infrastructure under their own administrative control. GitLab Docs
For fully self-hosted configurations, requests can move from the organization’s GitLab instance to a self-hosted AI Gateway and then to a self-hosted model. This architecture is attractive to enterprises concerned about data residency, privacy, model control, or keeping proprietary source code and development context inside their own infrastructure. GitLab Docs
The AI Gateway is therefore not just another browser-facing feature.
It sits between developer-facing AI functionality, orchestration logic, authentication, model providers, and—in the case of the Duo Agent Platform—agentic workflows capable of carrying out development tasks.
GitLab’s installation documentation also illustrates why compromising this service matters. Self-hosted AI Gateway configurations use signing and validation keys for JSON Web Tokens. The AI Gateway and the Duo Agent Platform service maintain their respective key pairs through environment variables such as AIGW_SELF_SIGNED_JWT__SIGNING_KEY and DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY. GitLab Docs
The advisory does not say CVE-2026-90970 automatically exposes those keys, so it would be incorrect to claim that exploitation necessarily steals them. But arbitrary command execution on a service responsible for sensitive authentication and AI orchestration obviously raises a much larger incident-response question than compromise of a disposable front-end component.
Once defenders hear “RCE on the AI Gateway,” the relevant question becomes what the compromised process can read, where it can connect, which credentials are reachable, which model endpoints it can access, and which GitLab-side services trust it.
How GitLab Duo Custom Flows Create the Attack Surface
The vulnerable path involves the GitLab Duo Agent Platform and custom flow configurations.
GitLab describes custom flows as AI-powered workflows that organizations can create to automate complex, multi-step actions across their GitLab projects. Custom flows have moved rapidly through GitLab’s product lifecycle: they appeared experimentally in GitLab 18.4, reached beta status in 18.7, became enabled for Self-Managed and Dedicated deployments in subsequent releases, and became generally available in GitLab 19.2. GitLab Docs
The underlying model is considerably more powerful than a single textbox sent to an LLM.
GitLab’s Flow Registry Framework represents a flow using YAML. A flow can define components, routing rules, inputs, prompts and available tools. An AgentComponent can reference a prompt or define one inline. Data from the surrounding session is mapped into named inputs and then inserted into the prompt template when the flow executes. GitLab Docs
A harmless simplified structure looks conceptually like this:
version: "v1"
environment: ambient
components:
- name: analysis_agent
type: AgentComponent
prompt_id: analysis_prompt
inputs:
- from: "context:goal"
as: "goal"
flow:
entry_point: analysis_agent
prompts:
- prompt_id: analysis_prompt
name: Analysis Prompt
unit_primitives: []
prompt_template:
system: |
Analyze the requested task.
user: |
Goal: {{ goal }}
placeholder: historyThis example is not an exploit. It simply demonstrates why templating exists in the first place.
GitLab needs some mechanism for turning structured workflow information into model-ready prompts. Variables such as a user’s goal, project identifier or previous agent output need to be inserted into prompt text. GitLab’s own documentation explicitly refers to Jinja-style placeholders and notes that its system prompt processing uses Jinja2: text containing {{ }} can be interpreted as template syntax unless it is appropriately escaped. GitLab Docs
That is where the security problem becomes interesting.
The system contains both data and template syntax. Security depends on making absolutely sure that values an untrusted or lower-privileged user controls never acquire the capabilities of the template language itself.
CVE-2026-90970 indicates that this boundary could be crossed.
CVE-2026-90970 Is a Template Injection Vulnerability, Not Ordinary Prompt Injection
This distinction is essential.
Prompt injection usually describes an attack against the behavioral boundary of a language model. An attacker places instructions in content that the model processes and attempts to convince the model to ignore earlier instructions, disclose information, call tools, or otherwise behave outside the developer’s intended policy.
The language model is the interpreter being manipulated.
CVE-2026-90970 is different.
The vulnerability has been classified as CWE-1336, which MITRE defines as a condition where externally influenced input reaches a template engine without sufficient neutralization, allowing syntax supplied through that input to be interpreted as template expressions or code directives. MITRE notes that template engines can include systems such as Jinja2, Twig, FreeMarker and others, and that unsafe template interpretation can result in unauthorized code or command execution. Common Weakness Enumeration
In other words, the dangerous interpreter in CVE-2026-90970 is located before or around the construction of the prompt, not inside the LLM reasoning process.
The difference can be represented conceptually as:
Traditional prompt injection:
Untrusted text
↓
LLM prompt
↓
Model interprets text as instructions
↓
Undesired AI behavior
CVE-2026-90970-style template injection:
Crafted flow configuration
↓
Prompt template processing
↓
Template sandbox boundary
↓
Sandbox escape
↓
AI Gateway command executionThe first case is largely an AI control problem.
The second can become a conventional server compromise.
That is why describing CVE-2026-90970 simply as an “AI prompt injection vulnerability” would materially undersell it.
What GitLab Has Publicly Confirmed About the Vulnerability
GitLab’s disclosure is concise.
According to the vendor, under certain conditions, an authenticated user who has Duo Agent Platform access could submit a specially crafted flow configuration capable of escaping the prompt template sandbox. Successful exploitation could result in arbitrary command execution on the AI Gateway. GitLab Docs
Three pieces of the attack chain are therefore confirmed.
The attacker controls or meaningfully influences a flow configuration.
The vulnerable operation occurs around the custom flow prompt template and the sandbox intended to contain its evaluation.
The security consequence can cross from template evaluation into command execution on the AI Gateway.
What GitLab has not publicly described is equally important.
As of this writing, GitLab has not published the precise sandbox escape primitive, the exact template expression required, the object or function that becomes reachable, the relevant vulnerable source-code path, or a working exploit. The public GitLab work item referenced by the CVE is not presently a full technical exploit write-up. Independent reporting has therefore correctly cautioned that the mechanics should not be invented beyond what the vendor has disclosed. ThreatFrontier.com
This matters because template sandbox escapes can happen in many ways.
A weak sandbox might expose a dangerous object. It might fail to filter an attribute traversal path. A helper made available to the template might indirectly expose filesystem or process primitives. Validation could differ between configuration parsing and actual template execution. An object considered harmless could contain methods leading to a more privileged subsystem.
Any of those patterns is plausible in the abstract.
None should currently be presented as the confirmed CVE-2026-90970 exploit mechanism without evidence.
For defenders, the practical fact is already enough: untrusted flow configuration reached a template execution boundary whose isolation could be escaped.
Why CWE-1336 Can Become Remote Code Execution
Template injection bugs often begin because an application needs to combine data with dynamic text.
Imagine an application that wants to produce:
Review project: my-project
Task: check the latest merge requestA safe design treats my-project and the task description exclusively as data.
A dangerous design accidentally lets an attacker transform some portion of that data into instructions understood by the template engine itself.
MITRE’s CWE-1336 documentation explains that once attacker-controlled input is interpreted as template syntax, the attacker may gain the ability to invoke template expressions rather than merely influence rendered text. Depending on the capabilities exposed by the template environment, the consequence can include execution of unauthorized code or commands. MITRE therefore recommends restricted or sandboxed template environments and limiting the functions and expressions available during evaluation. Common Weakness Enumeration
Sandboxing is supposed to break the escalation chain.
Conceptually:
User-controlled configuration
↓
Template engine
↓
Restricted expression set
↓
Rendered prompt
↓
LLMThe template engine may genuinely need conditional logic, substitutions, includes or structured data transformations. The sandbox attempts to provide those features without making the host runtime accessible.
CVE-2026-90970 indicates that the sandbox did not provide a sufficient boundary for all allowed flow configurations.
So the failure is not simply:
attacker changes the wording of a promptIt is closer to:
attacker-controlled configuration
↓
template language gains unintended capability
↓
sandbox restriction is bypassed
↓
host execution becomes reachableThat is a much more traditional injection vulnerability wearing an AI infrastructure surface.
A Likely Attack Path Without Inventing a PoC
The publicly documented attack chain can be modeled at a high level without publishing or guessing a weaponized payload.
An attacker first needs a valid identity and access to functionality in the GitLab Duo Agent Platform. GitLab does not describe CVE-2026-90970 as an unauthenticated internet RCE. The official CVSS vector sets PR:L, or low privileges required. GitLab Docs
The attacker then needs to reach a path where a custom flow configuration can influence prompt-template processing.
GitLab’s documentation confirms that custom flow YAML can contain locally defined prompts and template variables. A flow can combine components, context inputs and prompts and then execute those workflows through the Duo Agent Platform. GitLab Docs
The crafted configuration then reaches the vulnerable template-processing logic.
Under the unspecified conditions described by GitLab, the malicious template content escapes the prompt template sandbox.
After that boundary is broken, GitLab says arbitrary commands can execute on the AI Gateway.
The important security path therefore looks roughly like:
Authenticated GitLab user
↓
Duo Agent Platform access
↓
Create or influence custom flow
↓
Crafted prompt-template configuration
↓
AI Gateway processes flow
↓
Prompt template sandbox escape
↓
Arbitrary command execution
↓
AI Gateway host/process compromiseWhat happens after the final step depends heavily on the deployment.
Container isolation, service-account privileges, filesystem mounts, secret management, network segmentation and model connectivity will determine the blast radius.
The CVE itself does not establish that exploitation automatically compromises the entire GitLab instance.
Likewise, it does not establish that an attacker automatically gains root.
The correct statement is narrower and still serious: GitLab confirms arbitrary command execution on the AI Gateway.
Why CVSS 9.9 Makes Sense
The CVSS vector assigned to CVE-2026-90970 is:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HGitLab gives the vulnerability a base score of 9.9, just one tenth below the maximum possible CVSS v3.1 score. GitLab Docs
AV:N means the vulnerable functionality is reachable through a network-accessible path rather than requiring local access to the server.
AC:L indicates low attack complexity once the required conditions have been satisfied.
PR:L is important. The attacker requires some privileges. CVE-2026-90970 is therefore not equivalent to an unauthenticated RCE where anyone on the internet can immediately compromise an exposed server.
UI:N means exploitation does not require another user to click, approve or open something.
S:C, or Scope Changed, indicates the successful exploit crosses an authorization or security boundary.
Finally, confidentiality, integrity and availability are all rated High.
That combination fits the underlying architecture. A user operates in one trust domain—the Duo Agent Platform and its workflow configuration surface—but exploitation can cross into the AI Gateway’s command-execution environment.
This is also why organizations should not downgrade the issue simply because authentication is required.
An authenticated RCE can still be extremely dangerous when the required account is a normal internal user, compromised developer account, exposed service credential, malicious insider identity or account obtained through an unrelated application vulnerability.
Authentication changes the attack prerequisites.
It does not remove the post-exploitation impact.
Which GitLab AI Gateway Versions Are Vulnerable?
GitLab gives three affected ranges:
18.1.6 <= version < 19.2.4
19.3 <= version < 19.3.2
19.4 <= version < 19.4.1The corrected versions are:
19.2.4
19.3.2
19.4.1GitLab explicitly recommends that Self-Hosted AI Gateway users running an affected version upgrade to one of the corresponding patched versions as soon as possible. GitLab Docs
Administrators should pay attention to one operational detail: GitLab AI Gateway is a distinct service.
Seeing a patched GitLab application version in the UI is not, by itself, proof that the separately deployed self-hosted AI Gateway has also been replaced with a corrected build.
Organizations should inventory the actual gateway image, package or deployment being executed.
This distinction is particularly important in Kubernetes environments or internal platform deployments where GitLab itself and the AI Gateway may be upgraded by different Helm releases, deployment pipelines, platform teams or container registries.
Do not close the vulnerability ticket based solely on the main GitLab version.
Verify the running AI Gateway artifact.
GitLab-Hosted Gateways Are Already Patched
There is a major scope distinction in GitLab’s advisory.
GitLab states that it has already deployed the fix to GitLab-hosted AI Gateways. Customers using GitLab.com, GitLab Dedicated, and Self-Managed GitLab instances that use the GitLab-hosted AI Gateway are protected and do not need to take action for CVE-2026-90970. GitLab Docs
The environments requiring direct remediation are therefore Self-Managed customers operating their own Self-Hosted AI Gateway and running one of the vulnerable releases.
This difference is worth checking before initiating emergency maintenance.
“GitLab Self-Managed” does not automatically mean “vulnerable.”
A Self-Managed GitLab deployment can still use a GitLab-hosted AI Gateway.
The useful decision tree is:
Do you use GitLab Duo Agent Platform?
|
v
Do you operate your own AI Gateway?
/ \
No Yes
| |
GitLab-hosted Check gateway version
gateway |
already fixed +-- vulnerable -> upgrade
|
+-- patched -> verify deploymentAsset inventory is therefore the first response step.
CVE-2026-90970 Has an Important Predecessor: CVE-2026-1868
CVE-2026-90970 is especially interesting because it is not the first critical template-related AI Gateway vulnerability GitLab has fixed this year.
On February 6, 2026, GitLab released AI Gateway versions 18.6.2, 18.7.1 and 18.8.1 to address CVE-2026-1868, another Critical vulnerability scored 9.9.
GitLab described that earlier issue as insecure template expansion involving user-supplied data in crafted Duo Agent Platform Flow definitions. It could cause denial of service or gain code execution on the Gateway. CVE-2026-1868 was also associated with CWE-1336. GitLab Docs
The two vulnerabilities should not be treated as identical without additional evidence.
GitLab has not stated that CVE-2026-90970 is simply a bypass of the February patch.
But from a defensive architecture perspective, the recurrence is noteworthy.
Both issues sit near the same fundamental boundary:
user-controllable flow definition
↓
template processing
↓
AI Gateway execution environmentThat boundary is naturally difficult to secure because modern agent platforms intentionally make workflows expressive.
The more expressive a flow system becomes, the more tempting it is to give templates access to rich objects, helper functions, routing primitives and dynamically generated context.
Every capability exposed to the template runtime increases the importance of strict isolation.
CVE-2026-1868 and CVE-2026-90970 therefore illustrate a broader lesson for AI agent infrastructure: prompt construction itself can become an application-security attack surface.
The prompt does not need to reach the model before things go wrong.
Why AI Agent Platforms Make Template Injection More Dangerous
Server-side template injection is not new.
The security industry has dealt with Jinja, Twig, FreeMarker, Velocity and similar injection problems for years.
What has changed is the environment surrounding the template.
Historically, a vulnerable template might generate a webpage or email.
In an agent platform, the template may help assemble instructions for software that can query APIs, access repositories, read files, invoke tools, create branches, analyze vulnerabilities or interact with external services.
GitLab’s Flow Registry documentation shows that flows can combine multiple components, route data between them and provide toolsets to agents. Flow inputs can include session context and the outputs of previously executed agents. GitLab Docs
The security boundary is therefore layered:
User
↓
GitLab permissions
↓
Flow configuration
↓
Template parser
↓
Prompt sandbox
↓
Agent runtime
↓
Tool permissions
↓
GitLab APIs / filesystem / network / modelsSecurity failures at different layers produce very different consequences.
A prompt injection may manipulate the agent.
A tool-permission bug may let the agent perform an unauthorized action.
A template injection may compromise the service generating the prompt.
A container escape may compromise the host running the agent.
CVE-2026-90970 matters because it demonstrates that AI-security teams cannot focus exclusively on model behavior.
The conventional software underneath the model remains part of the attack surface.
How to Determine Whether Your Environment Is Exposed
Organizations should start with deployment discovery rather than exploit testing.
First establish whether a self-hosted AI Gateway exists at all.
GitLab’s architecture supports both GitLab-hosted and self-hosted configurations, so inventory should identify which model applies to each GitLab deployment. GitLab Docs
Then identify the exact running AI Gateway version.
For containerized deployments, this normally means checking the deployed image tag and, ideally, the immutable image digest. Do not rely entirely on infrastructure-as-code repositories because production may have drifted from declared state.
A simple Kubernetes inventory approach might be:
kubectl get deployments -A \
-o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGE:.spec.template.spec.containers[*].image'This command merely inventories container images; it does not test or exploit CVE-2026-90970.
Teams can then compare any AI Gateway release they identify against the affected ranges.
For Docker-based environments, administrators can similarly inventory running containers:
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'After identifying the gateway, capture the currently deployed version before making changes. This provides useful evidence for vulnerability-management records and incident investigation.
The next question is whether the Duo Agent Platform and custom flows are enabled and who can interact with them.
GitLab’s custom-flow documentation describes project-level creation and flow management capabilities, including roles and visibility configurations. Because the CVE specifically requires Duo Agent Platform access, reviewing users, groups, service accounts and project roles associated with custom flows is more useful than simply asking whether the AI Gateway’s network port was internet-accessible. GitLab Docs
How to Hunt for Possible Exploitation of CVE-2026-90970
Because GitLab has not published a canonical exploit signature, defenders should avoid pretending there is a reliable single IOC for CVE-2026-90970.
Detection should instead correlate activity across the two sides of the attack boundary: flow configuration activity and operating-system behavior on the AI Gateway.
Start by preserving relevant GitLab audit events and identifying recent creation or modification of custom flows. Pay particular attention to flow changes made by unexpected accounts, dormant developer identities, newly provisioned service accounts or users who normally have no reason to manage AI workflows.
Then correlate those timestamps against AI Gateway process activity.
A successful sandbox escape that ends in arbitrary command execution may produce process behavior inconsistent with normal gateway operation. The exact child process depends on the undisclosed exploit and the gateway environment, so hunting should focus on deviation from known-good process trees rather than a single executable name.
Useful telemetry can include process creation records, container runtime events, unexpected shell execution, filesystem writes, access to sensitive environment files, attempts to enumerate credentials and outbound connections to destinations the AI Gateway does not normally contact.
Network monitoring is particularly valuable.
A compromised AI Gateway might attempt to communicate with infrastructure outside the normal set of GitLab, model-provider, observability and internal dependency endpoints.
Again, this is post-exploitation hunting rather than a claim about the public CVE exploit.
A practical investigation sequence is:
Unexpected flow creation/modification
↓
AI Gateway template-processing request
↓
Unusual child process
↓
Unexpected file access
↓
Unexpected outbound network connection
↓
Credential use or lateral movementNot every anomaly in this chain means CVE-2026-90970 was exploited.
The purpose is to combine weak signals into a defensible investigation.
Do Not Test Production With an Unverified Sandbox-Escape Payload
Because the precise exploit has not been publicly documented, security teams should resist the temptation to copy arbitrary “CVE-2026-90970 PoCs” that may appear on GitHub, paste sites or social media immediately after disclosure.
Fresh CVEs routinely attract mislabeled repositories.
Some are harmless placeholders built for SEO.
Others contain code for unrelated vulnerabilities.
A few can contain malware.
At the time this article was prepared, public tracking sources had not identified a confirmed public CVE-2026-90970 exploit. Feedly
For most organizations, exploitability can be established safely without RCE testing.
If you operate an affected self-hosted version and expose Duo Agent Platform custom flows to qualifying users, the vendor has already told you the deployment is vulnerable.
Upgrade it.
A production RCE demonstration adds little value and creates unnecessary incident risk.
How to Fix CVE-2026-90970
The primary remediation is straightforward: upgrade the GitLab Self-Hosted AI Gateway.
GitLab has released:
19.2.4
19.3.2
19.4.1Administrators should move their deployment onto the appropriate patched branch and follow GitLab’s Self-Hosted AI Gateway installation and update instructions. GitLab explicitly recommends immediate updates for affected installations. GitLab Docs
Before the upgrade, preserve the current configuration, deployed image identifier and relevant logs.
After upgrading, confirm the actual running version rather than merely confirming that a CI/CD deployment job completed successfully.
A useful remediation lifecycle is:
Inventory
↓
Confirm hosting model
↓
Confirm gateway version
↓
Preserve relevant logs
↓
Upgrade gateway
↓
Verify deployed image/version
↓
Exercise a legitimate Duo workflow
↓
Review gateway behavior
↓
Close vulnerability only after verificationIf an organization cannot immediately patch, reducing Duo Agent Platform access to trusted users provides a useful temporary risk reduction because exploitation requires such access.
However, access restriction should not be considered equivalent to the vendor patch.
Compensating controls reduce attack opportunity.
They do not repair the vulnerable template boundary.
Restrict Who Can Create and Change AI Flows
CVE-2026-90970 also provides a reason to reassess the privilege model around custom AI workflows.
A flow configuration is executable infrastructure in a broader sense.
Even when it appears to be “just YAML,” it can control agent components, data sources, prompt templates, routing and tool availability.
Treating such configuration with the same casual permissions as ordinary documentation creates unnecessary risk.
GitLab itself recommends protecting customization files with Code Owners as part of its Duo Agent Platform customization best practices. GitLab Docs
Organizations should similarly consider workflow governance around custom flows.
Changes should be attributable to an identity, reviewable, version-controlled where possible and limited to users who actually need to design agent behavior.
The security principle is similar to CI/CD pipelines.
A .gitlab-ci.yml file might look like configuration, but developers understand that changing it can affect code execution.
AI flow definitions deserve comparable scrutiny.
Prompt Templates Should Be Treated Like Code Boundaries
One of the most useful lessons from CVE-2026-90970 is that a prompt template is not necessarily “just text.”
A static prompt like:
Summarize the following issue.has very little computational power.
A template like:
Project: {{ project_id }}
Goal: {{ goal }}
Previous output: {{ previous_result }}introduces a language that must parse variables.
Add conditional expressions, includes, macros, filters and object access, and the template begins to resemble a small program.
That is why CWE-1336 exists.
MITRE specifically recommends selecting template engines that provide sandboxed or restricted execution modes and limiting available expressions, functions and commands. Common Weakness Enumeration
For AI infrastructure designers, that leads to a useful architecture principle:
The safest prompt template language is the least expressive language that can satisfy the product requirement.
If a prompt system only needs string substitution, it should not automatically inherit the full capabilities of a general-purpose template runtime.
When general-purpose templating is necessary, data passed into it should remain data throughout its lifetime.
Sandbox Security Requires More Than a Sandbox Class
The word “sandbox” often creates too much confidence.
A sandbox does not become secure merely because a library provides a class with “Sandbox” in its name.
The real question is what the sandbox can reach.
Objects exposed to templates matter.
Functions exposed to templates matter.
Filters matter.
Implicit object properties matter.
Serialization and deserialization behavior matter.
Error handlers matter.
Plugins matter.
The Python runtime, filesystem and network context surrounding the template engine matter.
MITRE’s guidance around CWE-1336 reflects this broader point: the goal is not simply to select a sandboxed mode but also to restrict the expressions, functions and commands available to evaluated input. Common Weakness Enumeration
Agent infrastructure adds another concern.
Even when the host-level sandbox is secure, the rendered prompt can still be passed into an AI agent with powerful tools.
So there are effectively two different isolation challenges:
Template security boundary
+
Agent capability boundaryCVE-2026-90970 concerns the first.
Many prompt-injection defenses concern the second.
A secure system needs both.
Why a Compromised AI Gateway Deserves Incident-Response Attention
Once arbitrary commands can run on an AI Gateway, defenders should stop thinking about the issue exclusively as “an AI vulnerability.”
It has become a server compromise scenario.
For a confirmed or strongly suspected exploitation event, incident responders should preserve the gateway’s logs, container metadata, deployment manifests and relevant GitLab audit information before rebuilding the service.
Investigators should determine which credentials were accessible to the compromised process.
GitLab’s self-hosting documentation shows that signing and validation keys are part of the gateway architecture. Depending on an organization’s deployment, there may also be model-provider credentials, internal certificates, proxy credentials, telemetry tokens or other secrets in the surrounding runtime. GitLab Docs
This does not mean CVE-2026-90970 definitely steals those assets.
It means they belong in the post-compromise exposure analysis.
Security teams should also examine the gateway’s network reachability.
A service designed to communicate with GitLab and model infrastructure may legitimately have access to systems that ordinary developer endpoints do not.
Those relationships can become lateral-movement opportunities after RCE.
If compromise is confirmed, rebuilding the affected gateway from a known-good image is generally safer than trying to “clean” an unknown process state.
Secrets that could reasonably have been exposed should then be rotated based on evidence and the organization’s credential architecture.
The Remote Execution Sandbox Does Not Eliminate the CVE
GitLab separately documents an execution environment sandbox for remote Duo Agent Platform flows. That environment provides filesystem and network isolation for supported runner-based flow execution and is intended to reduce risks such as data exfiltration, malicious code loading and unauthorized network access. GitLab Docs
It is important not to confuse that system with the vulnerable prompt template sandbox described in CVE-2026-90970.
They protect different boundaries.
A runner execution sandbox can reduce what an AI agent does after being launched.
CVE-2026-90970 concerns the processing of prompt templates inside the AI Gateway itself.
Layered isolation remains valuable, and strong container or network boundaries can reduce post-exploitation impact, but administrators should not interpret the existence of a remote flow execution sandbox as mitigation for an unpatched AI Gateway.
The vendor fix remains necessary.
Why This Vulnerability Matters Beyond GitLab
CVE-2026-90970 is likely to become a useful case study for the security of agentic developer platforms.
The current generation of AI development tools increasingly combines several historically separate technologies:
Source-code hosting
+
Template engines
+
LLMs
+
Agent orchestration
+
CI/CD
+
Tool calling
+
Repository credentials
+
Execution sandboxes
+
Cloud APIsEach component already has a mature security history.
LLMs do not replace those old vulnerability classes.
They compose them.
A system can simultaneously be vulnerable to server-side template injection, prompt injection, confused-deputy behavior, excessive tool permissions and conventional secret leakage.
CVE-2026-90970 demonstrates why “AI security” cannot be reduced to testing whether a chatbot reveals its system prompt.
Sometimes the decisive vulnerability exists several layers before inference occurs.
The model might never need to behave maliciously at all.
CVE-2026-90970 Also Changes How We Should Think About AI Pentesting
Traditional web application testing normally asks where untrusted data reaches an interpreter.
SQL databases produce SQL injection.
Operating-system shells produce command injection.
Browsers produce XSS.
Template engines produce SSTI.
Agent platforms introduce additional interpreters without removing the existing ones.
A modern AI workflow might process the same attacker-controlled input through:
YAML parser
↓
Template engine
↓
LLM
↓
Tool router
↓
Shell or APITesting only the final LLM layer misses most of that pipeline.
Security testing should instead follow data across the complete execution graph.
For prompt templates specifically, testers should identify where user-controlled values enter template compilation or evaluation, distinguish values from template source, enumerate what functions and objects are exposed to the template, and determine whether the sandbox still enforces the intended security properties.
Those tests can be performed safely in isolated environments without immediately escalating to operating-system command execution.
The objective is to prove the boundary exists and fails, not to unnecessarily weaponize the failure.
CVE-2026-90970 Detection Is More About Behavior Than Signatures
Fresh vulnerabilities frequently arrive before mature detection content.
CVE tracking on October 2 indicated that no established Sigma, Suricata, YARA or Nuclei rule had yet become a reliable public standard for this issue. CVETodo
That makes behavioral telemetry more valuable.
Security teams operating self-hosted gateways should understand what normal execution looks like before an incident happens.
Which processes normally run inside the gateway container?
Which destinations does it normally contact?
Which directories does it normally write?
Which GitLab accounts normally create flows?
Which flow templates were modified recently?
Which credentials should the process be able to read?
Without this baseline, post-exploitation behavior blends into the noise.
With it, a flow configuration change followed seconds later by an anomalous subprocess and an unfamiliar outbound connection becomes considerably more meaningful.
Organizations Should Review the Trust Boundary Around Flow Creators
GitLab introduced a Flow Creator agent in GitLab 19.3. It can produce complete flow YAML from a natural-language description and is designed to help users create and debug custom Duo Agent Platform flows. GitLab Docs
There is no public evidence that the Flow Creator itself causes CVE-2026-90970.
The relevance is architectural.
As AI systems make workflow creation easier, a larger population of users may eventually interact with increasingly expressive configuration.
Security models that assumed “only a few specialists will ever edit this YAML” can become outdated very quickly.
Agent-generated configuration should therefore pass through the same validation and security boundaries as manually written configuration.
An AI-generated flow is still untrusted configuration from the perspective of the runtime.
Automation should never implicitly elevate trust.
What Security Teams Should Do Now
For most organizations, CVE-2026-90970 does not require sophisticated exploit research.
The response can be straightforward.
Determine whether you operate a GitLab Self-Hosted AI Gateway.
Determine the exact deployed AI Gateway version.
If it falls into the affected range, upgrade to 19.2.4, 19.3.2 or 19.4.1 as appropriate.
Review who has Duo Agent Platform and custom-flow access.
Preserve and inspect recent flow modifications if the gateway was vulnerable before patching.
Review AI Gateway process and network telemetry for unusual behavior during the exposure window.
If suspicious execution is found, investigate the gateway as a potentially compromised server rather than simply deleting the offending flow.
The Government of Canada’s Cyber Centre has also published an advisory urging administrators to review GitLab’s guidance and install the relevant updates. Canadian Centre for Cyber Security
The patch is available.
There is little reason to leave a vulnerable self-hosted gateway exposed while waiting for a public exploit.
Frequently Asked Questions About CVE-2026-90970
What is CVE-2026-90970?
CVE-2026-90970 is a critical vulnerability in GitLab AI Gateway affecting prompt-template processing used with the GitLab Duo Agent Platform. GitLab says an authenticated user with Duo Agent Platform access could, under certain conditions, submit a specially crafted flow configuration that escapes the prompt template sandbox and leads to arbitrary command execution on the AI Gateway. GitLab Docs
How severe is CVE-2026-90970?
GitLab assigns CVE-2026-90970 a CVSS v3.1 score of 9.9 Critical with network accessibility, low attack complexity, low privileges required, no user interaction, changed scope and high impact to confidentiality, integrity and availability. OpenCVE
Is CVE-2026-90970 an unauthenticated RCE?
No.
The vendor states that exploitation requires an authenticated user with Duo Agent Platform access. The CVSS vector likewise indicates PR:L, meaning low privileges are required. GitLab Docs
Is CVE-2026-90970 prompt injection?
Not in the usual sense.
GitLab maps the vulnerability to CWE-1336, a template-engine injection weakness. The failure happens in prompt-template processing and can escape the template sandbox into command execution on the AI Gateway. That is fundamentally different from merely convincing an LLM to follow malicious natural-language instructions. Common Weakness Enumeration
What versions of GitLab AI Gateway are vulnerable?
GitLab lists the following affected versions:
18.1.6 through versions before 19.2.4
19.3 through versions before 19.3.2
19.4 through versions before 19.4.1The fixed releases are 19.2.4, 19.3.2 and 19.4.1. GitLab Docs
Is GitLab.com vulnerable?
GitLab says the fix has already been deployed to GitLab-hosted AI Gateways. GitLab.com customers therefore do not need to take action for this vulnerability. The same applies to GitLab Dedicated and Self-Managed customers that use a GitLab-hosted AI Gateway. GitLab Docs
Does GitLab Self-Managed automatically mean I am vulnerable?
No.
The important question is whether your Self-Managed GitLab environment uses a Self-Hosted AI Gateway or GitLab’s hosted gateway.
Only an affected self-hosted gateway requires the customer-side gateway upgrade described in this advisory. GitLab Docs
Is CVE-2026-90970 being actively exploited?
There is no reliable public evidence of active exploitation identified as of October 3, 2026, and public tracking did not identify a confirmed public PoC at the time this article was prepared. The CVE is also not currently listed in CISA KEV. That situation can change quickly following disclosure, so organizations should rely on the vendor patch rather than the absence of published exploitation. Feedly
Is there a public CVE-2026-90970 exploit?
No verified public exploit was identified during research for this article.
GitLab has also not publicly disclosed the exact sandbox-escape primitive. Security teams should therefore be skeptical of repositories claiming to offer a working CVE-2026-90970 exploit unless the code can be independently validated. CVETodo
How do I patch CVE-2026-90970?
Upgrade the GitLab Self-Hosted AI Gateway to an appropriate corrected release:
19.2.4
19.3.2
19.4.1GitLab recommends upgrading affected self-hosted installations as soon as possible. GitLab Docs
Is upgrading the main GitLab application enough?
Administrators should verify the AI Gateway independently.
GitLab documents the AI Gateway as a standalone service, and the vulnerability specifically affects that component. A patched main GitLab installation should not be used as evidence that an independently deployed AI Gateway is also patched. GitLab Docs
CVE-2026-90970 Is a Warning About Where AI Security Boundaries Really Live
CVE-2026-90970 is easy to misread because several distinctly modern terms appear in the same advisory: AI Gateway, Duo Agent Platform, flow configuration and prompt template.
Underneath those names, however, the vulnerability represents a familiar security failure.
Untrusted configuration crossed an interpreter boundary.
A sandbox failed to keep that interpretation sufficiently contained.
The result could become command execution.
What makes the vulnerability particularly relevant in 2026 is where that old weakness now lives: inside infrastructure responsible for orchestrating AI agents across software-development environments.
GitLab’s fix resolves the immediate problem. Self-hosted administrators should move to AI Gateway 19.2.4, 19.3.2 or 19.4.1 and verify that the corrected gateway—not merely the core GitLab application—is actually running. GitLab-hosted gateways have already been patched. GitLab Docs
The larger lesson will outlive this patch.
AI agents create new attack surfaces, but many of the most consequential failures will still come from conventional software components surrounding the model: parsers, template engines, identity boundaries, tool routers, containers, credentials and network policy.
CVE-2026-90970 is a particularly clear example.
The dangerous prompt never needed to trick the model.
It only needed to escape the machinery that built the prompt.
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew