GitLab AI Gateway vulnerability: who must patch and how
The GitLab AI Gateway vulnerability CVE-2026-90970 scores 9.9. Only self-hosted gateways need action: the versions to upgrade to and what an attacker needs.
Source-based. Written from the documents, reporting and reviews linked in the text. Nothing here was tested hands-on by The Ruling Desk. How we work
A critical GitLab AI Gateway vulnerability, CVE-2026-90970, lets a signed-in user with access to GitLab's Duo Agent Platform run commands on the gateway server. GitLab disclosed it on October 2, 2026, and fixed it in AI Gateway 19.2.4, 19.3.2 and 19.4.1. The short version for admins: if you run your own AI Gateway, upgrade it today; if you use GitLab.com, GitLab Dedicated or GitLab's hosted gateway, you have nothing to do.
Key takeaways
- Only self-hosted AI Gateways must act. GitLab says GitLab.com, GitLab Dedicated and Self-Managed instances that use a GitLab-hosted gateway are already protected.
- The fixed versions are AI Gateway versions, not GitLab versions: 19.2.4, 19.3.2 and 19.4.1. Pick the one that matches your GitLab release line.
- Affected: every AI Gateway from 18.1.6 up to 19.2.3, plus 19.3.0 to 19.3.1 and 19.4.0.
- The attacker needs an account, not admin rights: a logged-in user with Duo Agent Platform access and a crafted flow configuration. GitLab scores it 9.9 out of 10.
- No exploitation reported as of October 4, 2026, and GitLab's advisory offers no workaround, only the upgrade.
Who has to act on the GitLab AI Gateway vulnerability
The AI Gateway is the service between a GitLab instance and the AI models behind GitLab Duo, the company's AI features. Most customers never touch it, because GitLab runs it for them. The exception is GitLab Duo Self-Hosted, where a Self-Managed customer deploys the gateway as a Docker container or Helm chart.
Those self-hosted gateways are the only ones exposed. GitLab's patch release notice says a fix "has already been deployed for GitLab-hosted AI Gateways," that GitLab.com, GitLab Dedicated and Self-Managed instances using the hosted gateway "do not need to take action," and that it contacted self-hosted gateway customers before publishing. If you started a container from the model-gateway image yourself, this is yours to patch.
Which version to upgrade to
GitLab's docs tell you to run the AI Gateway image whose version matches your GitLab release line, using the newest self-hosted-vX.Y.*-ee tag for your GitLab version X.Y. So the fix you need depends on which GitLab you run:
| Your AI Gateway version | Affected? | Upgrade to |
|---|---|---|
| 19.4.0 | Yes | 19.4.1 (self-hosted-v19.4.1-ee) |
| 19.3.0 to 19.3.1 | Yes | 19.3.2 (self-hosted-v19.3.2-ee) |
| 19.2.0 to 19.2.3 | Yes | 19.2.4 (self-hosted-v19.2.4-ee) |
| 18.1.6 to 19.1.x | Yes | No patched image on these lines; upgrade GitLab to 19.2 or later, then its matching gateway |
| Before 18.1.6 | Not listed as affected | No action for this CVE |
The affected ranges come from the advisory and the NVD entry for CVE-2026-90970, which both say "18.1.6 before 19.2.4." The fourth row is our reading, not a GitLab statement: the advisory ships fixes only for 19.2, 19.3 and 19.4, which are exactly the three lines GitLab's maintenance policy lists as receiving security fixes as of October 4. If your instance is on 19.1 or older, plan a GitLab upgrade, not just a gateway swap.
What an attacker needs
GitLab's description is narrow: an authenticated user with Duo Agent Platform access can "escape the prompt template sandbox via a specially crafted flow configuration," which leads to arbitrary command execution on the gateway. Flows are the multi-step AI workflows users build on the Duo Agent Platform; GitLab's custom flows documentation says they reached general availability in GitLab 19.2 and have been on by default for Self-Managed since 18.8.
The weakness is CWE-1336, template injection: user input reaches a template engine that treats part of it as code. GitLab's CVSS 3.1 vector, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, means it works over the network with low privileges and no victim interaction. In plain terms, an ordinary account with Duo Agent Platform access is enough; no admin role is required.
Why that's serious: per GitLab's install docs, the gateway container is started with the JWT signing keys it uses to authenticate AI requests. Command execution on that host could expose those keys and whatever else the server can reach. That last point is our inference; GitLab hasn't described the impact beyond command execution.
How to upgrade a self-hosted AI Gateway
GitLab's AI Gateway upgrade steps are short. For Docker:
- Check the current image and digest with
docker images --digests | grep ai-assist. - Stop and remove the container:
sudo docker stop gitlab-aigw, thensudo docker rm gitlab-aigw(use your own container name). - Pull the patched tag for your release line, for example
self-hosted-v19.4.1-ee, and run it again with the same environment variables and keys. - Confirm the digest changed.
For Helm, set the new image tag in your upgrade. The same docs warn that chart versions before 0.7.0 default to imagePullPolicy: IfNotPresent, which can skip a re-published image under an unchanged tag, so pin the image by digest or set the pull policy to Always.
If you can't upgrade today, GitLab's advisory gives no stopgap. Limiting who has Duo Agent Platform access narrows who could try it, but that's our suggestion, not GitLab guidance.
Why it matters
This is the second critical template flaw in the gateway's flow handling this year. The NVD entry for CVE-2026-1868, published in February 2026, also scored 9.9 and described insecure template expansion through crafted Duo Agent Platform flow definitions, fixed then in 18.6.2, 18.7.1 and 18.8.1. If you run the gateway yourself, its patch cadence is now its own job, separate from GitLab's monthly releases.
What happens next
As of October 4, there is no public sign of attacks. A CISA assessment attached to the NVD record on October 2 lists exploitation as "none" and the attack as not automatable, while rating the technical impact "total." BleepingComputer's report mentions no active exploitation either. GitLab credits the researcher invisiblemeerkat, via HackerOne, and has published no technical details beyond the advisory. NVD's own analysis is still pending, so watch the record for changes.
For more on how attacks are reaching AI tooling, see our coverage of the Zammad breach DIVD blamed on an AI agent, and the rest of our vulnerability coverage.
Bottom line
The GitLab AI Gateway vulnerability only needs your attention if your Self-Managed GitLab uses a self-hosted AI Gateway. If it does, upgrade the gateway to 19.2.4, 19.3.2 or AI Gateway 19.4.1, whichever matches your GitLab line, and verify the image digest changed. On GitLab 19.1 or older, there's no patched gateway for your line, so plan the GitLab upgrade. Everyone on GitLab.com, Dedicated or the hosted gateway is already covered, according to GitLab.
FAQ
Do GitLab.com users need to do anything about CVE-2026-90970?
No. GitLab says the fix is already deployed to its hosted AI Gateways, so GitLab.com, GitLab Dedicated and Self-Managed instances that use the GitLab-hosted gateway need no action.
Are 19.2.4, 19.3.2 and 19.4.1 GitLab versions or AI Gateway versions?
They are AI Gateway versions, published as Docker image tags such as self-hosted-v19.4.1-ee. GitLab's docs say to match the gateway's version to your GitLab release line, so a GitLab 19.3 instance takes 19.3.2.
Is CVE-2026-90970 being exploited?
Not as far as anyone has reported as of October 4, 2026. A CISA assessment on the NVD record lists exploitation as "none," and GitLab hasn't reported attacks.
Can an outsider exploit it without an account?
No. The advisory requires an authenticated user with Duo Agent Platform access. That account needs no admin rights, though, which is why GitLab rates it 9.9.