GitLab urges self-hosted AI Gateway users to apply critical patches

GitLab is urging operators of affected self-hosted AI Gateways to install a critical security patch. The advisory says an authenticated user with Duo Agent Platform access could, under certain conditions, escape a custom-flow prompt-template sandbox and execute arbitrary commands on the gateway. The fixed releases are 19.2.4, 19.3.2 and 19.4.1.

The first question is where the AI Gateway runs. GitLab says its hosted gateways are already fixed, including those used by GitLab.com, Dedicated and Self-Managed customers. Running your own GitLab instance does not by itself mean you operate the affected gateway. The urgent update applies to an affected gateway you host.

Find the gateway that needs the patch

The CVE record for CVE-2026-90970 was published on October 2. GitLab rates the issue critical, with a CVSS 3.1 score of 9.9. The disclosed failure concerns server-side processing of a specially crafted flow configuration. It should not be described as a model simply being persuaded to ignore its instructions.

The gateway has its own deployment and release tag. GitLab's installation documentation covers Docker and Helm deployments and tells administrators to use explicit stable image tags aligned with the GitLab minor release. Updating the main GitLab application is therefore not evidence that a separately deployed gateway has received this fix.

Affected AI Gateway release range	Listed fixed release
18.1.6 up to, but excluding, 19.2.4	19.2.4
19.3 up to, but excluding, 19.3.2	19.3.2
19.4 up to, but excluding, 19.4.1	19.4.1

The advisory lists no patched version below the 19.2 line. A team on an older line needs to resolve the supported upgrade path with GitLab rather than assume that a cross-minor gateway replacement is compatible with its instance. The advisory's urgency and the deployment's compatibility requirements need to be handled together.

Verify the running release

In a hypothetical installation, the main GitLab instance is current but a separate gateway container still runs 19.4.0. The application upgrade has not changed that container. Checking the gateway's running image identifies the component that needs 19.4.1, while checking only the main application's version would miss it.

Applying the bounded-action approach to this patch means identifying the gateway deployment, its current image and the compatible fixed release before making the change, then confirming what is running afterward. A desired tag in a manifest is insufficient when the rollout has left an older replica serving requests.

For a Docker deployment, inspect the gateway container and the image it is actually using. For a Helm deployment, compare the release configuration with the gateway pods' running images and rollout state. Follow GitLab's update procedure for the chosen deployment method, then check that the AI Gateway and Agent Platform are accessible. These checks establish deployment state and basic service continuity; they are not a penetration test or proof that no prior compromise occurred.

The October 2 CISA assessment in the CVE record recorded exploitation as “none.” That is a dated assessment, not a guarantee that exploitation cannot occur. No active-exploitation claim is established by the sources reviewed for this article.

For this patch, the practical handoff is short: who operates the gateway, which image is serving, and which supported fixed release will replace it? Answering those questions connects a critical advisory to the infrastructure that actually needs attention.