CVE-2026-90970 in GitLab AI Gateway: RCE risk and JWT key compromise

GitLab AI Gateway has received a critical vulnerability, CVE-2026-90970 (CVSS 9.9), which under certain conditions allows an authenticated user with access to Duo Agent Platform to execute arbitrary commands on the gateway. Only organizations with a self-hosted AI Gateway are at risk; they must immediately update the gateway to versions 19.2.4, 19.3.2 or 19.4.1, otherwise they risk losing control over JWT keys and the communication channels between GitLab and model providers.

Technical details of the vulnerability

According to the official GitLab advisory on the patch release for AI Gateway versions 19.2.4, 19.3.2 and 19.4.1 (patch-release gitlab-ai-gateway-19-4-1), CVE-2026-90970 is described as a critical weakness in the prompt template mechanism used in custom flows in Duo Agent Platform:

• Identifier: CVE-2026-90970 (critical; CVSS 9.9 according to GitLab, confirmed by the CVE Project record: CVE-2026-90970 record).
• Weakness class: CWE-1336 (errors in template engines and code generation systems; indicated by GitLab as the general class, including for the February CVE-2026-1868).
• Impact type: the ability to “escape the prompt template sandbox” followed by execution of arbitrary commands on the AI Gateway.
• Required privileges: an authenticated user with access to Duo Agent Platform and the ability to create/modify custom flow; no additional roles are mentioned in the advisory.

The core problem is that the template mechanism, which is supposed to isolate the execution context (a sandbox for the prompt template), can be bypassed via a specially crafted flow configuration. In threat modeling terms, this turns the user-defined description of an AI flow into a channel for injecting constructs that result in command execution in the gateway’s host environment.

GitLab emphasizes that exploitation leads specifically to command execution on the AI Gateway, and not directly on the GitLab server. However, in the architecture of a self-hosted Duo AI Gateway, this component is a trusted intermediary and contains sensitive elements:

• the gateway stores JWT signing keys used for communication between GitLab and the gateway (addressed in the Duo self-hosted documentation: GitLab Duo Self-Hosted);
• the gateway maintains connections both to the GitLab instance itself and to model providers.

From a threat perspective, this means that successful command execution on the AI Gateway can at minimum lead to:

• compromise of JWT keys (loss of trust in all tokens signed by this gateway);
• the ability to manipulate traffic between GitLab and model providers (tampering with requests/responses, leakage of prompts and codebase content if they pass through the gateway);
• use of the gateway as a foothold for further lateral movement across the network.

The CVE entry in NVD, created on the basis of information from GitLab and the CVE Project, is available under the standard identifier CVE-2026-90970 in NVD, which cements the rating as critical and confirms remote code execution (RCE) with authentication.

Affected and fixed versions

AI Gateway is delivered as a separate component (Docker image or Helm chart) and is updated independently from the main GitLab version. In the GitLab advisory for AI Gateway (AI Gateway installation and upgrade documentation) the following key points are stated:

• Fixed AI Gateway versions:
  • 19.2.4
  • 19.3.2
  • 19.4.1
• There are no fixes for branches below 19.2.4, and the advisory explicitly states that all releases from 18.1.6 up to and including the 19.1 line fall within the range of affected versions.
• GitLab (as of October 2) supports only GitLab branches 19.4, 19.3 and 19.2, as reflected in the maintenance policy: GitLab maintenance policy. These same lines received AI Gateway patches.

To update a Docker deployment, GitLab recommends stopping and removing the current AI Gateway container, then pulling and starting the image with the new tag (for example, self-hosted-v19.4.1-ee). For Helm deployments, it is sufficient to change the image tag in the chart configuration and apply the upgrade.

Organizations using GitLab.com, GitLab Dedicated, or self-managed GitLab with AI Gateway hosted by GitLab are protected automatically: the provider has already updated its gateways. Only owners of self-hosted gateways need to take action.

The advisory highlights two important limitations:

• GitLab does not provide workarounds for those who cannot yet update the gateway.
• No reliable diagnostic method is described that would allow an administrator to definitively determine past exploitation of the vulnerability in their gateway.

According to the CISA assessment added to the CVE record on October 2, the exploitation status is “none” (no information on public exploitation or proof-of-concept is available). But this is a momentary snapshot: the vulnerability class and high CVSS score make it an attractive target, especially after patch details are published.

Recurring vulnerability class in AI Gateway

In February, GitLab had already addressed a critical issue of the same class in AI Gateway — CVE-2026-1868, also with a 9.9 score and a similar vector: a crafted flow definition leading to denial of service or code execution on the gateway. The patch is described in a separate GitLab advisory: patch-release gitlab-ai-gateway-18-8-1.

Both vulnerabilities belong to CWE-1336 — security violations in template systems. Two critical incidents in less than a year indicate that:

• the template mechanism for custom flows in Duo Agent Platform is a high-risk part of the architecture;
• traditional testing methods (including unit tests and standard security reviews) do not cover all abuse scenarios for custom flow;
• to protect platforms that allow configuration of AI flows, a targeted security review of template engines and strict limitations on available constructs are required.

For customers, this means that the risk is not limited to a single CVE: the very model of giving end users powerful tools for configuring AI flows requires administrators to configure permissions more carefully and to introduce such capabilities gradually into critical processes.

Impact assessment and risk profile

The primary risk area is organizations that:

• deploy a self-hosted GitLab AI Gateway in their own environments;
• provide Duo Agent Platform access to a wide range of developers and teams rather than a small trusted core;
• use GitLab AI features (GitLab Duo) to work with sensitive code or data (IP, confidential artifacts, internal models).

If no update is applied, potential consequences include:

• Compromise of authentication and authorization:
  • an attacker who gains access to the gateway can extract JWT keys or manipulate the token issuance process;
  • as a result, it becomes possible to forge trusted interactions between GitLab and AI Gateway.
• Data leakage:
  • access to the content of AI model requests and responses;
  • indirect access to the codebase and artifacts if they are involved in AI flows.
• Expansion of the attack surface:
  • using the gateway as an entry point for further movement within the infrastructure (moving towards the GitLab server, databases, or network segments where the gateway is located);
  • a shift from an “internal” vulnerability (requiring Duo Agent Platform authorization) to a scenario where a compromised internal account causes maximum damage.

It should be taken into account that the presence of authentication does not make the vulnerability insignificant: in a typical DevOps environment, developers and engineers who already have broad privileges often have rights to create custom flows. CVE-2026-90970 turns any compromised account with such rights into a direct lever for taking over the AI Gateway.

Practical response recommendations

1. Immediate update of the self-hosted AI Gateway

1. Determine whether you are using a self-hosted AI Gateway:
   • check the documentation for your own installation or follow the “self-hosted” section in the GitLab Duo guide: GitLab Duo Self-Hosted;
   • if you use GitLab.com or GitLab Dedicated without your own gateway, you can skip this step — the gateway has already been updated by GitLab.
2. Determine the current AI Gateway version:
   • for Docker — by the image/container tag;
   • for Helm — by the image tag specified in the chart values file.
3. If the version is lower than 19.2.4, 19.3.2 or 19.4.1:
   • for Docker:
     1. stop and remove the running AI Gateway container;
     2. pull a new image with a fixed tag (self-hosted-v19.2.4-ee, self-hosted-v19.3.2-ee or self-hosted-v19.4.1-ee — depending on your GitLab branch, see the upgrade instructions);
     3. start the new container with the same environment and network parameters.
   • for Helm:
     1. update the AI Gateway image tag in the chart configuration to one of the fixed versions;
     2. apply the upgrade (helm upgrade ...).

2. Access management for Duo Agent Platform

• Review the list of users who have access to Duo Agent Platform and the right to create/edit custom flows.
• Reduce this access to the minimum necessary set of roles, especially in environments with a self-hosted AI Gateway.
• Temporarily limit experiments with custom flows in production environments until the update is completed and further risk assessment is carried out.

3. Post-incident analysis and monitoring

Since GitLab has not provided a ready-made method to check for exploitation, it makes sense to perform an extended analysis of activity around AI Gateway and Duo Agent Platform for the period before the update:

• analyze Duo Agent Platform access logs for:
  • creation or modification of unusual custom flows;
  • suspiciously frequent or complex changes in flow configurations;
• check AI Gateway container or pod logs for:
  • atypical commands in system logs;
  • errors related to template execution (exceptions in the template engine);
  • suspicious outbound connections to unusual hosts.
• if there is reason to suspect exploitation:
  • assume the JWT keys on the gateway are compromised;
  • initiate a key rotation procedure and re-establish trusted relationships between GitLab and AI Gateway.

4. Long-term measures

• Implement separate deployments:
  • separate environments for experimenting with AI flows and for production AI integrations;
  • separate AI Gateway instances for particularly sensitive projects, if necessary.
• Include AI Gateway updates in the overall patch management process alongside GitLab core:
  • check current GitLab advisories for AI Gateway;
  • regularly cross-check against the supported versions in the maintenance policy.
• Reassess the trust model for AI components:
  • treat AI Gateway as a highly sensitive service with criticality equivalent to the GitLab server;
  • restrict network access to the gateway and use separate network segments and inter-segment traffic controls.

The key priority for self-hosted GitLab AI Gateway owners is to update the gateway to one of the fixed versions (19.2.4, 19.3.2 or 19.4.1) as soon as possible, then review access rights to Duo Agent Platform and perform at least a basic audit of gateway logs and custom flows for the period preceding the update.