GitLab AI Gateway: Patch CVE-2026-90970

GitLab AI Gateway: Patch CVE-2026-90970

GitLab shipped three patch releases on Friday, October 2 — 19.2.4, 19.3.2 and 19.4.1 — for a flaw it scores at 9.9 Critical. The advisory's own title is the whole bug in eight words: Improper Neutralization issue in custom flow prompt template.

If you host your own AI Gateway, this is a patch-today item. If GitLab hosts it for you, close this tab. Getting that distinction right takes about thirty seconds, and it is the difference between an incident response and a free afternoon.

Who is actually exposed

The AI Gateway is the piece that connects a GitLab instance to model providers. GitLab's install docs describe it as "a combination of two services" — the AI Gateway service and the Duo Agent Platform service — and they ship in a single model-gateway container alongside your own instance, listening on ports 5052 and 50052.

That optionality is the whole reason the disclosure is worth reading carefully. GitLab states plainly that a fix is already deployed for GitLab-hosted gateways and that GitLab.com, Dedicated, and Self-Managed instances pointed at a GitLab-hosted gateway "are protected and do not need to take action."

So the exposed population is narrow: organisations running GitLab Duo Self-Hosted with their own gateway container. That is a small set — the feature exists to let you keep model traffic inside your own network — and it is also a valuable one. Those containers are configured with credentials for the model endpoints they call: the same install guide documents AIGW_MTLS__CERT_FILE and AIGW_MTLS__KEY_FILE, a client certificate and private key the gateway presents to upstream model providers.

The mechanism, as far as the advisory reveals it

CVE-2026-90970 maps to CWE-1336: improper neutralization of special elements used in a template engine. In plain terms, user-supplied content was evaluated as template syntax rather than treated as data.

GitLab's description:

"GitLab has remediated an issue in the GitLab AI Gateway that, under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway."

Read that carefully. It is not prompt injection against the model. The model's output is not part of the attack. The attacker submits a flow configuration — a custom flow being the AI-powered workflow users build on the Duo Agent Platform — whose prompt template breaks out of a sandbox whose whole purpose was to keep that submitted content from reaching the host. What comes out the other side is command execution on the gateway, under the gateway's own privileges.

The vector string explains why 9.9 and not something lower:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

PR:L is the only thing holding it down from a perfect ten — you need an authenticated account with Duo Agent Platform access. S:C is the part people skip: scope changed. The impact escapes the gateway component itself, so whatever the gateway can reach is in scope too.

Credit goes to HackerOne researcher invisiblemeerkat, who GitLab thanked for responsible disclosure.

The February precedent nobody is connecting

This is not the first 9.9 in the AI Gateway, and the earlier one has the same shape. CVE-2026-1868 was fixed on February 6, 2026 in 18.6.2, 18.7.1 and 18.8.1, also scored 9.9, also CWE-1336. That one lived in the Duo Workflow Service and was reachable via crafted Flow definitions, causing denial of service or code execution on the gateway. February's advisory carried the same advice: update immediately.

Two disclosures, eight months apart, both critical, both template expansion of user-supplied data from the same product area. Whatever is templating flows in this service has now failed twice. Treat the next one as a matter of when, not whether — and note that February's advisory is silent about this one, so there is no vendor statement that the two share a root cause. Nobody has published one.

The version math will bite you

Here is where I would expect an admin to get stuck. The affected ranges, as GitLab words them:

AI Gateway: all versions from 18.1.6 before 19.2.4,
            19.3 before 19.3.2, and 19.4 before 19.4.1

Fixed in 19.2.4, 19.3.2, 19.4.1. Now look at that as a list of available fixes for a given deployment:

The lowest fixed version in the product is 19.2.4. There is no backport below it. An 18.x deployment has no in-branch patch to apply.

And this collides with GitLab's own install guidance, which pairs the gateway image tag to your GitLab version: if you are on vX.Y.*-ee, use the latest self-hosted-vX.Y.*-ee gateway tag. Getting a fixed gateway may therefore mean upgrading the GitLab application to 19.2 or later. The advisory does not address that case, so check with GitLab support before you pin a mismatched pair.

One more trap worth naming: these are not the GitLab CE/EE patch numbers. GitLab's own application also took a critical fix last month — a maximum-severity path traversal, CVE-2026-85706 — and CISA added it to the KEV catalog on September 11, which makes it the one GitLab flaw you are already obliged to patch. A self-managed instance with a self-hosted gateway is carrying two separate critical advisories right now, and only one of them is fixed by bumping a gateway tag.

Patching the gateway

The upgrade path is unremarkable, which is a relief. Stop the container, remove it, pull the fixed tag, run it again with the same environment variables:

sudo docker stop gitlab-aigw
sudo docker rm gitlab-aigw

docker pull registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:<ai-gateway-tag>

docker run -d -p 5052:5052 -p 50052:50052 \
 -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e AIGW_SELF_SIGNED_JWT__SIGNING_KEY="$(cat aigw_signing.key)" \
 -e AIGW_SELF_SIGNED_JWT__VALIDATION_KEY="$(cat aigw_validation.key)" \
 -e DUO_WORKFLOW_AUTH__ENABLED="true" \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="$(cat duo_workflow_jwt.key)" \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__VALIDATION_KEY="$(cat duo_workflow_validation.key)" \
 registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:self-hosted-v19.4.1-ee

For Helm deployments, do not skip the digest. Chart versions before 0.7.0 default to imagePullPolicy: IfNotPresent, so a re-rollout against an unchanged tag keeps serving the old image — and you will believe you patched:

# Pin by digest so a re-rollout cannot silently reuse the old image
helm upgrade --install ai-gateway \
  ai-gateway/ai-gateway \
  --set="image.tag=self-hosted-v19.4.1-ee@sha256:<digest>" \
  --set="image.pullPolicy=Always" \
  # ... your existing flags

kubectl rollout restart deployment/ai-gateway -n ai-gateway

Verify the running image, not the intended one:

# Docker
docker images --digests | grep ai-assist

# Kubernetes: read the tag and digest the pod is actually running
kubectl get pod -n ai-gateway \
  -o jsonpath='{.items[0].status.containerStatuses[0].imageID}{"\n"}'

Until the patch lands: cut the attack path

The advisory gives you the fix and almost no compensating guidance. Two things are worth doing on your own, both cheap.

Trim the entitlement list. The precondition is Duo Agent Platform access. Audit who actually holds it. If your business does not need the feature, turning it off removes the attack path entirely; if it does, shrink it to the smallest set of accounts that genuinely author flows. Review existing flows for template syntax you do not recognise.

Look at the gateway as a potential foothold. GitLab has published no indicators of compromise, and CISA's SSVC assessment on the CVE record lists exploitation as none, automatable as no, and technical impact as total. That is the strongest available signal, and it still says nothing about your gateway. It also means there is nothing vendor-provided to hunt with, so reasonable starting points are yours to choose: unexpected child processes or shell activity inside the container, outbound connections the service has no reason to make, flows created or edited recently by accounts that do not normally author them.

Because commands run as the gateway, if anything looks wrong, rotate the credentials that gateway holds for your model endpoints — including that mTLS client certificate — and rebuild the gateway from a known-good image rather than restarting it.

If you take one architectural lesson from this, make it that a component holding your model-provider credentials should not also be a component end users can push executable-shaped content into. That is the agent platform blast radius problem in its purest form — the same reasoning that makes sandboxed agent runtimes worth demanding applies to the gateway your agents call through.

What is still unknown

GitLab says the escape works "under certain conditions" and does not list them. The work item that tracks it is one GitLab's coordinated disclosure process makes public 90 days after the fix ships — "All vulnerabilities will be made public via our issue tracker 90 days after releasing the fix" — so the mechanism detail arrives around the turn of the year. The advisory does not say which credentials or systems post-exploitation touches; S:C tells you the boundary was crossed without telling you what lies past it.

CISA has not added CVE-2026-90970 to the Known Exploited Vulnerabilities catalog, though GitLab now has five entries there — including CVE-2026-85706 from September. That is a reason to patch today rather than a reason to relax: the fix is a three-version bump, the attack needs nothing more exotic than an account that already holds agent permissions, and a gateway nobody has attacked yet is the cheapest moment to update one.

That is the pattern worth taking away: the most expensive compromises now start from ordinary, legitimate access, not from a missing login.

Sources

• GitLab Docs: GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2, and 19.4.1
• NVD: CVE-2026-90970 (CNA record and CISA SSVC assessment)
• GitLab Docs: GitLab AI Gateway Critical Patch Release: 18.6.2, 18.7.1, and 18.8.1 (CVE-2026-1868)
• GitLab Docs: Install the GitLab AI Gateway
• GitLab: Coordinated Disclosure Process
• CISA: Known Exploited Vulnerabilities Catalog (CVE-2026-90970 and CVE-2026-85706 entries)
• The Hacker News: GitLab Patches Critical Self-Hosted AI Gateway Flaw That Could Let Duo Agent Users Run Commands
• BleepingComputer: GitLab warns of critical RCE vulnerability in AI Gateway service