GitLab patches a critical 9.9 AI Gateway flaw that runs commands on self-hosted servers
On October 2, GitLab fixed a critical vulnerability (CVE-2026-90970, CVSS 9.9) that lets a logged-in user execute commands on the AI Gateway, the service that connects a GitLab instance to AI models. Only organizations that host their own gateway need to act: move to 19.2.4, 19.3.2 or 19.4.1 now.
October 2, 2026. GitLab ships a fix for a critical flaw in its AI Gateway, the service that connects a GitLab instance to large language models. October 2, 2026. The flaw, tracked as CVE-2026-90970, carries a CVSS score of 9.9 out of 10 — one tenth short of the maximum. October 2, 2026. CISA adds an assessment to the record that lists exploitation as “none”: no known attacks, no public proof of concept. Why it matters: a logged-in user with nothing more than Duo Agent Platform access can run commands on the gateway — the component sitting between your repository and your AI model.
What the flaw actually allows
The vulnerability does not sit in GitLab itself, but in the AI Gateway, the separate component that routes AI requests between the instance and the models. In practice, a logged-in user who holds Duo Agent Platform access can, under certain conditions, execute commands on the gateway.
The danger is asymmetric. The gateway is not a plain proxy: it often carries API secrets, keys to model providers, and the credentials of the service account that talks to the LLM. Running a command on that machine means reading those secrets, pivoting toward the model provider, or tampering with the responses developers receive.
The score of 9.9 — not 10 — reflects a precondition: the attacker must already be logged in and hold Duo Agent Platform access. It is therefore not a fully unauthenticated remote code execution from the internet, but an escalation inside the AI chain. That nuance does not reduce the urgency: organizations that host their gateway have exactly such privileged accounts, and one compromised account is enough to reach the machine holding the model secrets.
GitLab did not publish the full technical vector in its advisory, but the scope is unambiguous: only instances that host their own gateway are affected. Customers on GitLab.com, GitLab Dedicated, and self-managed instances using a GitLab-hosted gateway have nothing to do — the vendor already fixed those.
Who patches, and how
The fix ships in three gateway lines: 19.2.4, 19.3.2 and 19.4.1. The mapping table GitLab published leaves no room for guessing:
- 18.1.6 or later, before 19.2.4 → upgrade to 19.2.4.
- 19.3, before 19.3.2 → upgrade to 19.3.2.
- 19.4, before 19.4.1 → upgrade to 19.4.1.
The affected range is wide: every gateway release from 18.1.6 through the 19.1 line is exposed, and no fixed version is published below 19.2.4. The three fixed lines (19.4, 19.3, 19.2) line up exactly with the GitLab versions that still receive security fixes under the vendor’s maintenance policy.
The gateway deploys as its own Docker image or Helm chart, with a separate update cadence — it does not update in lockstep with the instance. For a Docker deployment, stop and remove the container, then pull and run the new tag, for example self-hosted-v19.4.1-ee. For Helm, change the tag in the chart’s image setting.
# Docker deployment: replace the container with the fixed tag
docker stop ai-gateway && docker rm ai-gateway
docker run -d --name ai-gateway \
-e AIGW_AUTH__BYPASS_EXTERNAL=true \
registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/self-hosted-v19.4.1-ee:latestTwo details make the decision heavier. First, there is no workaround: an instance that cannot be updated yet stays exposed. Second, GitLab offers no way to check whether a gateway was attacked before it was patched — no indicators of compromise, no log to inspect first.
That manual step is the real risk. The gateway is deployed separately from the instance, updates on its own cadence, and often falls outside the patch-management scans that cover the GitLab application itself. A 9.9 left on an unpatched gateway is, for many teams, the result of that inventory blind spot — the component was never added to the list of things to scan. Add the gateway’s image tag to whatever tracks your container versions, and treat its upgrade as a first-class change rather than a follow-up to the GitLab release.
A link that concentrates risk
This flaw illustrates a structural shift in the job. For years, a code forge’s attack surface boiled down to the repository and the CI/CD runner. AI features grafted on a new privileged link: a service that talks to models, holds secrets and processes source code in cleartext, often deployed hastily because it is seen as a mere utility.
That Duo Agent Platform access — an agent-oriented feature — is enough to trigger the flaw says a lot. Security is no longer only about who can push code; it is about who can do what on the AI chain that assists it. One misconfigured role, and an account meant for test agents becomes a command-execution point on the gateway.
The absence of public exploitation should not lull anyone. CISA rates exploitation “none” as of October 2, but a network-facing — or near-network-facing — 9.9 RCE on a component holding model-provider secrets is exactly the kind of target ransomware and espionage groups quickly add to their toolkits once the patch is reverse-engineered.
After the patch: the audit the fix does not do
Moving to 19.2.4, 19.3.2 or 19.4.1 closes the door, but says nothing about what may have gone through while it was open. GitLab offers no indicators of compromise, which shifts onto the team the burden of checking whether the gateway was touched.
The first step is a secrets inventory. A self-hosted gateway does not just route requests: it typically holds an API key to the model provider, an access token to the GitLab instance, and sometimes a dedicated service account. Any secret that may have passed through the machine during the exposure window must be treated as compromised and rotated — rotation is not a precaution, it is the only defensible posture when you cannot prove the absence of intrusion.
The second is a role audit. The flaw triggers through Duo Agent Platform access, a recent feature often granted in a hurry for agent pilots. Re-list the holders of that privilege, revoke those who no longer need it, and treat the right as a strong privilege, on par with a CI/CD runner administrator. A leftover test account can be enough to turn the flaw into command execution.
The third is monitoring. Pipe the gateway’s logs into your SIEM, and alert on command execution, key access and unusual network egress. A component holding model-provider secrets deserves the same supervision as a secrets manager — and too many deployments still treat it as a plain utility with no logs.
Verdict
If you host your own AI Gateway, treat this patch as an emergency: move to 19.2.4, 19.3.2 or 19.4.1 now, starting with environments where the gateway touches sensitive code or data. Since no indicators of compromise are provided, review the gateway afterward — exposed secrets, service accounts, model-provider keys — and rotate anything that may have leaked. If you use a GitLab-hosted gateway, you have nothing to patch, but use the moment to audit who holds Duo Agent Platform access in your organization: that is the privilege that turns this flaw into command execution.