On October 2, 2026, GitLab disclosed a critical flaw in its AI Gateway — the service that sits between your GitLab instance and the AI models behind Duo's coding and agent features. Tracked as CVE-2026-90970 and rated CVSS 9.9, it lets an authenticated user with Duo Agent Platform access escape the prompt-template sandbox and run arbitrary commands on the gateway. Patches shipped the same day for the three supported release lines: 19.2.4, 19.3.2, and 19.4.1. GitLab's own hosted gateways are already fixed — self-hosted ones are not. If you run your own gateway, this post tells you exactly whether you're exposed, which version to move to, and how to verify the fix.
The AI Gateway is the proxy that every GitLab AI request passes through: code suggestions, chat, and Duo Agent Platform flows. If you self-host it — the option GitLab offers for teams that want AI request and response data to stay inside their own network — that gateway container is a privileged piece of your agent infrastructure. A sandbox escape there is not a GitLab bug you can file and forget; it's command execution on infrastructure that sees your engineers' code and prompts.
What the vulnerability is
GitLab's AI Gateway processes flow configurations — structured descriptions of how an AI-assisted flow should behave, including prompt templates (the pre-written instruction wrappers the gateway fills in before calling a model). Those templates run inside a sandbox: the restricted execution environment that's supposed to guarantee templates can assemble text but never touch the host.
CVE-2026-90970 breaks that guarantee. A crafted flow configuration isn't adequately sanitized, and malformed template fields escape the sandbox. The underlying weakness is classified as CWE-1336 — improper neutralization, which is the formal way of saying the code didn't sufficiently validate the structure of what it was about to execute. The result: arbitrary command execution on the gateway, with the scope marked as changed — meaning the compromise can reach beyond the sandboxed component. Authentication is required (an attacker needs a valid GitLab account with Duo Agent Platform access), but no further user interaction is.
GitLab credited a HackerOne researcher, invisiblemeerkat, with the report. The disclosure came through GitLab's own security advisory on October 2, and GitLab had already notified customers with self-hosted gateways before the advisory went public.
Who is affected — and who isn't
| Your setup | Action needed |
|---|---|
| GitLab.com | None — GitLab patched its gateways already |
| GitLab Dedicated | None — already patched |
| Self-managed instance using a GitLab-hosted gateway | None — already patched |
| Self-hosted AI Gateway below the fixed versions | Patch immediately |
The trap here is that "self-managed GitLab" doesn't automatically mean "affected." The gateway ships as its own Docker image or Helm chart, separate from the main GitLab release. You're only exposed if you chose to host the gateway yourself — the deployment option for data-residency teams.
Warning: the affected-version range is wide. NVD lists every gateway release from 18.1.6 up to the fixed builds as vulnerable, which means if you've been self-hosting the gateway for a while without tracking its tags, assume you're exposed until you check the running image tag.
The fixed versions
These are AI Gateway versions, not GitLab versions — the gateway has its own release lines and its own update steps. As of October 2, 2026, GitLab's maintenance policy covers three lines, and each got a patch:
| Gateway version in use | First fixed version |
|---|---|
| 18.1.6 or later, before 19.2.4 | 19.2.4 |
| 19.3, before 19.3.2 | 19.3.2 |
| 19.4, before 19.4.1 | 19.4.1 |
Match the gateway image to your GitLab minor version — that's what GitLab's own install guide tells administrators to do, and it still holds when patching. Don't jump release lines; take the patch for the line you're already on.
What GitLab didn't say
Two gaps are worth naming because they decide how you treat this after patching.
There is no evidence of in-the-wild exploitation — and that's a snapshot, not a guarantee. GitLab's advisory does not say whether the flaw was used in attacks. CISA added an assessment to the CVE record on October 2 listing exploitation as "none," but CISA's values only cover three states (none, public proof of concept, active exploitation). A "none" on disclosure day means nobody had published a PoC yet, not that nobody had the bug.
The exact attack conditions aren't described. GitLab hasn't named the specific user role beyond Duo Agent Platform access, nor the crafted fields. That limits what you can audit for: you can't scan old logs for a signature of the attack, so the remediation is purely to patch and then treat the gateway as a component that needed hardening all along.
Step 1 - Check your running gateway version
Find out what you're actually running before you change anything. For a Docker deployment, the image tag tells you:
docker ps --format '{{.Image}}' | grep ai-gateway
Why this command: the gateway ships as a separate container, so docker ps on the host lists the image and tag. The tag encodes the gateway version (for example, a tag containing v19.4.1 is already past the fix line). If the tag is missing or latest, inspect the container to confirm what you're running.
You should see something like registry.gitlab.com/gitlab-org/modelops/apigw/self-hosted-v19.4.1-ee — the version is in the tag. For Helm, check the image.tag value in your deployed release:
helm get values <your-gateway-release> --namespace <your-namespace>
Note: if you can't find the gateway container at all, you're probably using a GitLab-hosted gateway — in which case you're already covered and can stop here.
Step 2 - Apply the patch for your deployment
Docker deployments. Stop and remove the running container, then pull and run the fixed image tag for your line (19.2.4, 19.3.2, or 19.4.1):
docker stop <gateway-container-name>
docker rm <gateway-container-name>
docker pull registry.gitlab.com/gitlab-org/modelops/apigw/self-hosted-v19.4.1-ee
Why pull-then-run instead of upgrading in place: the gateway image is stateless — configuration lives in your compose file or environment, not in the container. A fresh pull guarantees no old layer lingers.
Helm deployments. Change the tag in the chart's image setting, then deploy the release:
helm upgrade <your-gateway-release> <chart-path-or-repo> \
--namespace <your-namespace> \
--set image.tag=self-hosted-v19.4.1-ee
Replace self-hosted-v19.4.1-ee with the fixed tag for your line (19.2.4 or 19.3.2 if you're on those lines). Here's what each piece does: helm upgrade redeploys the release with the new image; image.tag pins the gateway version so future helm upgrade runs don't drift back. Match the tag to your GitLab minor version per GitLab's install guide.
Step 3 - Verify the gateway is on the fixed version
After the container is up, confirm the tag changed:
docker ps --format '{{.Image}}' | grep ai-gateway
You should see the fixed tag (v19.4.1 or your line's fix). Then confirm the gateway is healthy and answering traffic the way it was before the change — check the container logs for a clean startup with no repeated crash loops:
docker logs <gateway-container-name> --tail 50
You should see the gateway's normal startup sequence and no sandbox-related errors. If your GitLab instance was healthy before, an AI feature smoke test (one code suggestion or one Duo chat request) is the end-to-end proof: it exercises the exact prompt-template path the patch touches.
Harden beyond the patch
This bug is one instance of a pattern: every component that assembles or executes prompts for your agents is now privileged infrastructure, and most teams treat gateways and proxies as boring plumbing.
Four things worth doing this week:
- Put the gateway behind the same update discipline as GitLab itself. It ships separately, so it slips through "we patched GitLab" thinking. Pin the image tag, watch GitLab's security advisories for the AI Gateway line, and set a calendar reminder for patch Tuesday-adjacent reviews.
- Restrict who has Duo Agent Platform access. This flaw needed an authenticated user with platform access. Audit that access list the way you'd audit admin seats — a deprovisioned contractor's account should not retain a path to command execution.
- Network-isolate the gateway. The gateway only needs to talk to your GitLab instance and the model providers. Egress controls that limit where a compromised gateway can reach turn a 9.9 into a contained incident.
- Log flow configurations. You can't retroactively detect this attack, but logging crafted flow configs going forward gives you a record if the next sandbox bug arrives with a known signature.
Note: none of this replaces the patch. Hardening is the follow-up, not the alternative — a CVSS 9.9 sandbox escape outruns firewall rules the moment an insider credential is involved.
Key Takeaways
- CVE-2026-90970 is a CVSS 9.9 prompt-template sandbox escape in GitLab's self-hosted AI Gateway, disclosed October 2, 2026 — crafted flow configs lead to arbitrary command execution.
- Only self-hosted gateways are affected — GitLab.com, Dedicated, and GitLab-hosted gateways are already patched. Check your running image tag before assuming anything.
- Patch to 19.2.4, 19.3.2, or 19.4.1 depending on your line; these are gateway versions, not GitLab versions.
- CISA lists exploitation as "none" at disclosure — a snapshot, not a guarantee. Patch first, then review who holds Duo Agent Platform access.
Next step: check your gateway image tag today with the command in Step 1. If it's below a fixed version, schedule the patch for your next maintenance window — and while you're there, read our n8n October 2026 security update for the companion story of why agent-adjacent surfaces keep producing the worst bugs.
Sources: GitLab security advisory (Oct 2, 2026); The Hacker News, "GitLab Patches Critical 9.9 AI Gateway Flaw" (Oct 2, 2026); NVD CVE-2026-90970 record; redsecuretech.co.uk patch guide (Oct 2026).
Images: Unsplash / Pexels
Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/
Top comments (0)