GitLab AI Gateway Vulnerability Turns Authorized Duo Access Into a Critical RCE Risk

GitLab has patched a 9.9-rated GitLab AI Gateway vulnerability that can turn authorized Duo Agent Platform access into command execution on a self-hosted gateway. The flaw, tracked as CVE-2026-90970, crosses a boundary that the product was supposed to enforce. A crafted flow configuration can escape the prompt template sandbox and execute arbitrary commands on the gateway.

That qualification matters. This is not a reported zero-click compromise of every GitLab server, and it does not give an anonymous internet user immediate access. Exploitation requires authentication and access to the Duo Agent Platform. However, GitLab’s severity assessment reflects what happens after those conditions are met: low-complexity network exploitation, no further user interaction, and potentially severe consequences across confidentiality, integrity, and availability.

The incident creates a direct conflict between control and responsibility. Organizations self-host AI infrastructure to keep code, prompts, and model traffic within trusted boundaries. Yet self-hosting also makes those organizations responsible for updating the service that processes this sensitive material. GitLab-hosted gateways have already been patched, while operators of affected self-hosted gateways must complete their own upgrades.

What the GitLab AI Gateway vulnerability changed

CVE-2026-90970 converts permission to configure an AI workflow into a potential path toward operating-system commands.

GitLab disclosed the issue on October 2, 2026. According to the public vulnerability record, affected releases include AI Gateway versions from 18.1.6 through versions preceding 19.2.4. The 19.3 branch is affected before 19.3.2, while the 19.4 branch is affected before 19.4.1.

Those version boundaries differ from the main GitLab application’s release history. Administrators should therefore verify the AI Gateway image or deployment itself. Checking only the visible GitLab application version can create false confidence when the gateway follows a separate deployment lifecycle.

The fixed versions are 19.2.4, 19.3.2, and 19.4.1. Operators should move to the appropriate fixed release or a later supported version. GitLab-hosted gateways have already received the remediation, so GitLab.com and customers using GitLab’s managed gateway do not face the same patching task.

The vulnerable path begins with a specially crafted flow configuration. A flow defines an agentic sequence that can combine prompts, tools, decisions, and actions. GitLab Duo Agent Platform uses these configurations to perform multistep software-development tasks rather than answering a single isolated prompt.

Prompt templates convert a flow’s configuration and runtime data into instructions that an AI model can process. A template sandbox is the restricted environment intended to prevent template content from reaching unsafe application or operating-system capabilities. CVE-2026-90970 involves improper neutralization inside that boundary.

The weakness is categorized as CWE-1336, or improper neutralization of special elements used in a template engine. In practical terms, attacker-controlled syntax can be interpreted as executable template behavior rather than inert data. The exact dangerous outcome depends on the surrounding application, available functions, and process privileges.

For this flaw, GitLab says the result can be arbitrary command execution on the AI Gateway. That outcome is more serious than manipulating an AI response. It means the vulnerability reaches beyond model output and into the conventional execution environment hosting the gateway.

The distinction between the AI Gateway and a large language model is important. The gateway is a standalone application service positioned between GitLab features and AI models. GitLab’s gateway documentation says the service provides access to AI-native GitLab Duo features. It handles application logic and requests around the model rather than functioning as the model itself.

Consequently, the vulnerability is not evidence that a model independently discovered an escape or ignored a behavioral safety instruction. The reported mechanism is a software vulnerability in template processing. Its input happens to arrive through an agentic configuration surface.

That fact keeps the incident within a familiar security category, but the setting raises the stakes. AI gateways can handle source-derived context, workflow instructions, authentication material, and connections to model backends. A command-execution flaw at that junction can expose more than a malformed prompt or unreliable answer.

GitLab has not publicly described widespread exploitation of CVE-2026-90970. The available record also does not establish that attackers have used the vulnerability against production environments. Administrators should not interpret that verification gap as proof of safety, especially after disclosure gives potential attackers a clearer target.

The immediate change is therefore operational. A self-hosted AI Gateway previously treated as a controlled internal component now requires urgent version verification, patching, and post-upgrade review. Its risk cannot be inferred solely from whether the main GitLab interface is public.

Why an authenticated sandbox escape earns a 9.9 rating

The vulnerability is critical because its prerequisites limit who can attack, while its potential impact remains broad once the sandbox fails.

GitLab assigned CVE-2026-90970 a CVSS 3.1 base score of 9.9. The published vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Each element explains why an authenticated flaw can still sit near the top of the severity scale.

The network attack vector means a potential attacker does not need local shell access to the gateway host. The relevant service can receive the malicious configuration through network-accessible application functionality. Network-accessible does not necessarily mean exposed to the entire public internet, but it expands the possible attack path beyond physical or local access.

Low attack complexity indicates that exploitation does not depend on a narrow race condition or an unusual deployment state. Low privileges are required, rather than no privileges. The user must be authenticated and must have Duo Agent Platform access.

No user interaction means another person does not need to open a file, approve a dialog, or visit a malicious link after the configuration reaches the vulnerable path. That characteristic matters in collaborative development environments, where trusted automation often processes submitted configurations without a second human action.

The changed-scope component is especially significant. It indicates that exploitation can affect resources beyond the security authority represented by the original vulnerable component. Here, template input starts within an authorized agent workflow but can cross into the gateway’s command-execution environment.

The final three metrics record high potential impact to confidentiality, integrity, and availability. Command execution can theoretically support reading accessible information, modifying gateway resources, or disrupting the service. The actual damage still depends on deployment architecture, process permissions, network reachability, and available credentials.

That context prevents two misleading interpretations. Calling the vulnerability “authenticated” should not be used to dismiss it as an ordinary account-level problem. Calling it “remote code execution” should not imply that every anonymous visitor can immediately compromise a GitLab environment.

The relevant attacker might already be a valid user. It could also be someone controlling a compromised account, stolen token, or overprivileged automation identity. Security boundaries must continue working after authentication because legitimate access is rarely equivalent to unlimited infrastructure authority.

Agent systems make this distinction more urgent. They accept structured instructions and can perform sequences of actions across development services. A user authorized to define a flow may need extensive application capabilities, but that user should not inherit the operating-system privileges of the service interpreting the flow.

The vulnerable sandbox was meant to preserve that separation. Its failure turns a configuration language into a possible execution surface. That is the core reversal behind the GitLab AI Gateway vulnerability: a feature designed to govern agent actions becomes a route around its own containment layer.

Template injection also differs from prompt injection. Prompt injection manipulates instructions sent to a model, often attempting to redirect the model’s behavior or reveal contextual data. Template injection targets the software that constructs or renders those prompts. When the template engine exposes unsafe objects or functions, the result can include server-side execution regardless of how the model responds.

CWE-1336 formalizes this class of failure. The template-engine weakness appears when software fails to neutralize elements that a template engine treats as executable syntax. The safest response is not another behavioral instruction for the model. It is a software fix that prevents attacker-controlled data from becoming executable template content.

That difference should shape incident review. Teams need to inspect application permissions, configuration histories, gateway logs, container activity, and downstream credentials. Reviewing AI conversation transcripts alone would miss activity occurring in the gateway process or its surrounding runtime.

A gateway commonly occupies a privileged integration position even when it does not run as root. It may communicate with the GitLab instance, model servers, observability systems, or internal network services. Operators should map those connections instead of assuming command execution on one container automatically equals total infrastructure compromise.

Containerization can reduce impact when configured well, but it does not erase the incident. A compromised container can still expose mounted secrets, service tokens, network-accessible systems, or data handled by the process. Excessive permissions, writable mounts, and broad network routes enlarge that blast radius.

The 9.9 score therefore describes a worst-case standardized assessment, not proof that every affected environment suffered maximum damage. Administrators must combine that score with their actual deployment architecture. The correct conclusion is urgent investigation and remediation, not automatic confirmation of a breach.

Self-hosting trades data control for patch ownership

The security promise of a self-hosted gateway remains valid only when customers can inventory, isolate, update, and monitor that gateway as critical infrastructure.

GitLab supports managed, hybrid, and fully self-hosted AI configurations. In the managed arrangement, GitLab operates the gateway and connects it to selected external model providers. A self-hosted deployment places the gateway and model path inside infrastructure controlled by the customer.

That architecture can support strict privacy, residency, and network-isolation requirements. GitLab’s self-hosting guide says organizations can operate their own gateway and models for full control over AI infrastructure. A fully self-hosted configuration can also operate in a network with limited or no general internet access.

CVE-2026-90970 exposes the other half of that bargain. The customer gains control over placement and data flow, but also owns maintenance of the deployed gateway. GitLab cannot silently update a container running inside a customer-controlled environment.

That responsibility can become unclear because an AI gateway sits beside more familiar development infrastructure. Platform teams may manage the GitLab application, while machine-learning teams maintain the model server. A separate group may own the container platform or network controls.

If no team explicitly owns the gateway image, its patch state can fall between those boundaries. A managed gateway avoids that specific coordination problem because the vendor controls deployment. Self-hosting demands an internal process that treats the gateway as a distinct production service.

Inventory is the first pressure point. Organizations need to know whether they use GitLab’s managed gateway, a self-hosted gateway, or a hybrid arrangement. Hybrid deployments require feature-level understanding because some requests can use customer infrastructure while others use GitLab-managed services.

Version discovery is the second pressure point. Operators should identify every self-hosted gateway instance, including proof-of-concept systems and disconnected environments. An isolated deployment can still be vulnerable to authenticated insiders or compromised identities even when it cannot receive direct internet traffic.

Patching is the third pressure point. Affected installations need a fixed gateway version, not only an update to the visible GitLab application. Teams should preserve deployment evidence, record the previous image digest, and confirm that workloads restarted with the intended version.

The fourth pressure point is exposure analysis. Administrators should identify which users and service accounts had Duo Agent Platform access during the vulnerable period. They should also determine who could create or modify flows and whether those actions produced usable audit records.

The fifth is runtime review. A post-patch investigation should compare gateway process behavior with its normal baseline. Unexpected child processes, command interpreters, file changes, new outbound connections, or unusual container restarts deserve examination.

Secrets require special attention. GitLab’s installation documentation explains that the gateway uses signed JSON Web Tokens to authenticate requests. Self-hosted services also receive configuration values and keys through their runtime environment. These mechanisms are necessary for normal operation, but any credential accessible to a compromised process may need rotation.

The installation guidance also describes the AI Gateway and Duo Agent Platform as separate services with separate signing-key pairs. That separation gives defenders a useful review framework. They should assess both services, their trust relationship, and the credentials used between them.

Network design can substantially change the consequences. A gateway that can reach only a model server and narrowly defined GitLab endpoints presents a smaller opportunity than one with broad access across internal networks. Egress restrictions, workload identities, read-only filesystems, and minimal container privileges remain meaningful controls.

However, network isolation should complement patching rather than replace it. A vulnerable internal service can be attacked from another compromised internal account or workload. Segmentation limits movement and data access, but it does not repair unsafe template processing.

Operators should also consider the data passing through the gateway. Self-hosting is often selected precisely because prompts can contain proprietary source code, issue context, or internal instructions. If exploitation occurred, investigators need to determine which information the gateway could access, not merely which files existed inside its container.

This work belongs in the same operational category as protecting CI runners, artifact repositories, and secret managers. All of these services translate developer-controlled inputs into automated actions. Their usefulness comes from privileged connectivity, which also makes their isolation and update cadence important.

The lesson is not that managed AI infrastructure is always safer. Managed services concentrate vendor responsibility and reduce customer patch work, but customers accept different trust, residency, and dependency tradeoffs. The lesson is that self-hosting changes who must respond when a critical gateway flaw appears.

An earlier 9.9 flaw makes this more than a one-off patch

CVE-2026-90970 is the second publicly documented 9.9-rated GitLab AI Gateway template issue in 2026, strengthening the case for architectural review.

In February 2026, GitLab addressed CVE-2026-1868 in the Duo Workflow Service component of the AI Gateway. GitLab’s public CVE assignment describes insecure template expansion of user-supplied data through crafted Duo Agent Platform flow definitions.

The earlier vulnerability carried the same CVSS 3.1 vector and 9.9 severity score. Its fixed releases included AI Gateway versions 18.6.2, 18.7.1, and 18.8.1. GitLab credited an internal team member with discovering that flaw.

The new vulnerability affects later release lines beginning at version 18.1.6 and extending into the 19.4 series, according to the current record. Public descriptions of both issues involve crafted flow definitions or configurations, template handling, low-privilege authenticated access, and possible command execution.

That similarity does not prove the patches failed in the same way. Public vulnerability summaries are too limited to establish whether CVE-2026-90970 is a regression, an incomplete earlier fix, or a distinct unsafe template path. Treating those possibilities as confirmed would overstate the evidence.

Still, defenders should not evaluate the October disclosure in isolation. Two critical findings around the same broad trust boundary indicate that flow configuration processing deserves deeper testing. A one-line version upgrade can close the disclosed path while leaving broader design questions unanswered.

The main opponent in this story is the platform’s governance promise versus the reality of an executable configuration surface. GitLab positions agentic flows as controlled automations that operate within established development processes. Those controls lose value if authorized flow authors can cross into gateway-level commands.

The issue is not unique to GitLab’s product category. AI gateways, agent orchestrators, and workflow engines all translate flexible user input into privileged operations. Their configuration formats can become programming languages even when product interfaces present them as declarative files.

That flexibility creates a recurring security tradeoff. Customers want customizable agents that can inspect repositories, call tools, respond to events, and complete multistep objectives. Each new tool, expression, template variable, or plugin expands what the orchestration layer must interpret safely.

A strict configuration language can reduce risk but limits customer customization. A flexible language supports more workflows but requires mature sandboxing, parser controls, permission boundaries, and security testing. The risk rises when a single process both renders untrusted templates and holds valuable infrastructure access.

Defense therefore needs several independent layers. The parser should treat untrusted values as data. The template environment should expose the smallest possible object set. Authorization should limit who can submit flows. The gateway runtime should have minimal filesystem, network, and credential access.

Auditability provides another layer. Flow creation and modification events should be attributable to specific human or service identities. Organizations should be able to connect a submitted configuration with subsequent gateway activity. Without that chain, confirming or excluding exploitation becomes much harder.

The earlier vulnerability also changes how teams should handle upgrade verification. It is not enough to establish that the latest fixed image started successfully. Operators should confirm that old replicas, cached images, test clusters, and disaster-recovery environments do not retain affected versions.

Disconnected environments can be especially deceptive. Their lack of general internet access reduces some external threats, but it can slow delivery of security notices and patches. An authorized user inside that environment may still reach the application functionality required by the vulnerability.

A skeptical assessment must also acknowledge what remains unknown. Public records do not yet provide a proof of concept, a detailed call path, or confirmed exploitation telemetry. They do not identify a universal set of post-exploitation indicators for every deployment.

Those gaps restrict confident claims about observed attacks, but they do not weaken the patch recommendation. A vendor-confirmed command-execution flaw with a 9.9 score presents enough risk to justify immediate remediation. Waiting for public exploitation evidence would exchange uncertainty for preventable exposure.

The stronger long-term question is whether template processing remains necessary in its current trust context. GitLab can reduce future risk by publishing more technical detail after customers have time to patch. Root-cause information would help operators understand which boundaries failed and which compensating controls matter most.

Customers, meanwhile, should treat custom agent flows as code. They deserve review, ownership, change control, and testing comparable to CI configuration. A visual or declarative interface does not make a workflow non-executable when the platform turns its contents into actions.

What defenders should watch next

The next assessment should depend on three signals: patch adoption, GitLab’s root-cause disclosure, and evidence concerning real-world exploitation.

The first signal is whether self-hosted operators reach fixed AI Gateway versions quickly. GitLab controls its hosted service, but it cannot measure every customer deployment from inside private infrastructure. Security teams should establish their own completion evidence instead of assuming normal software-update reporting includes the gateway.

That evidence should identify the deployment, previous version, replacement image, restart time, and validation result. It should also cover development and disaster-recovery systems. If organizations struggle to produce this inventory, the incident reveals an ownership problem beyond the vulnerability itself.

Fast patch adoption would strengthen the case that enterprises can manage self-hosted AI components as conventional production infrastructure. Slow or unmeasured adoption would weaken the control argument behind private deployment. Data locality offers limited protection when critical middleware remains untracked.

The second signal is a fuller technical explanation from GitLab. Defenders need to know whether CVE-2026-90970 represents a new template path, a regression, or incomplete mitigation of the earlier flaw. That distinction affects confidence in the surrounding architecture and testing strategy.

A useful disclosure would explain the vulnerable component, the affected privilege boundary, and the containment changes without providing unnecessary exploit detail. It would also clarify whether separate Agent Platform and AI Gateway services require different post-incident actions.

Confirmation of a distinct root cause would suggest that broad template hardening is working through multiple findings. Evidence of a bypass around an earlier mitigation would raise sharper questions about whether the initial security boundary was designed comprehensively.

The third signal is credible evidence about exploitation. GitLab and security agencies should be watched for indicators of compromise, known exploited vulnerability listings, or revised response guidance. Independent incident reports would also matter if they include verifiable telemetry.

Until such evidence appears, articles should not describe CVE-2026-90970 as actively exploited. The absence of public confirmation is not the same as confirmation that no exploitation occurred. Organizations must make response decisions from exposure and impact, not headlines alone.

Teams can begin with four practical questions. Do we operate any self-hosted AI Gateway? Are all instances running 19.2.4, 19.3.2, 19.4.1, or later? Who could modify Duo agent flows during the affected period? What systems and secrets could the gateway process reach?

The answers should be preserved with incident records, configuration history, and relevant logs. Teams that need to connect deployment notes, ownership decisions, and review evidence can maintain a searchable knowledge base. Documentation will not remediate the vulnerability, but fragmented evidence can delay containment and later audits.

The GitLab AI Gateway vulnerability ultimately tests whether agent infrastructure receives the same operational discipline as CI systems and other code-execution services. Patch the affected gateway, verify the running image, review authorized flow changes, rotate exposed credentials when evidence warrants it, and reduce the gateway’s privileges.

Then ask the harder question: if another agent configuration crosses a trust boundary next month, can your team identify the owner, affected versions, reachable assets, and response path without rebuilding the inventory during the incident?