GitLab.com can skip this. A self-hosted AI Gateway cannot. On October 2 GitLab patched a critical bug that lets a logged-in user with Duo Agent Platform access break out of a custom-flow prompt template and run commands on the gateway you host yourself.
If you host the AI gateway, the flow editor is a shell.
What happened
CVE-2026-90970 is in GitLab’s AI Gateway, the service that sits between a GitLab instance and the models behind Duo. GitLab runs that gateway for GitLab.com, GitLab Dedicated, and self-managed instances that use a GitLab-hosted gateway, and those are already fixed. The customers who have to act are the ones who installed their own gateway so prompts and responses stay in their environment.
Don’t Miss the Policy Changes That Affect Security Decisions
Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.
By subscribing you agree to our Privacy Policy.
Free. Weekday mornings. 5 minutes or less.
GitLab says an authenticated user with Duo Agent Platform access could escape the prompt-template sandbox through a crafted custom flow and execute commands on the gateway. It is CWE-1336, the same class as a February gateway bug (CVE-2026-1868) that GitLab also scored 9.9. This one is scored 9.9 as well. The advisory does not name a tighter role than Duo Agent Platform access, and it does not list a workaround.
CISA added an assessment on the CVE record on October 2 marking exploitation as none — not “proof of concept,” and not “active.” There is no KEV entry. The gateway still holds JWT signing keys and a path back to the GitLab instance and to your model providers, which is why “no exploit yet” is a window, not a reason to leave 19.1 in place.
The version numbers that matter are the gateway’s, not only the GitLab application’s. GitLab installs the gateway as its own Docker image or Helm chart. Fixed gateway tags: 19.2.4, 19.3.2, and 19.4.1. Everything from 18.1.6 up through the 19.1 line has no listed fix below 19.2.4, and GitLab’s maintenance policy at disclosure covered 19.4, 19.3, and 19.2. If you are on an older GitLab minor, confirm a 19.2.4 gateway is actually supported beside it before you assume the tag will boot.
Why it matters
A self-hosted gateway exists specifically because someone decided AI traffic should not leave the building. That box is now the one a low-privilege Duo user can try to turn into a shell. The signing keys on it are how the gateway proves itself to GitLab.
Most companies are not in scope. The failure mode is the team that turned on self-hosted Duo in a pilot and never put the gateway image on the patch list.
What to do first
- Ask one question: do we run our own AI Gateway container or Helm release? If the answer is no — GitLab.com, Dedicated, or a GitLab-hosted gateway — stop. You are not in scope.
- If yes, read the running image tag. Update Docker to a fixed tag such as self-hosted-v19.4.1-ee (or 19.3.2 / 19.2.4 to match your line). Helm: set the chart image tag and roll it.
- Verify the gateway version after the rollout. The main GitLab version can look current while the gateway image is old.
- Until that tag is live, limit who can create or edit custom flows on the Duo Agent Platform.
- If the gateway was reachable by more people than you thought, plan to rotate the JWT signing keys after the upgrade and review gateway logs. GitLab does not provide a compromise check in the advisory.
Forward this
If someone on your team self-hosted GitLab Duo so prompts stay in-house: update the AI Gateway image to 19.4.1, 19.3.2, or 19.2.4. GitLab.com does not need this. The gateway version is a separate number from the GitLab version.
Details
- CVE: CVE-2026-90970 — prompt-template sandbox escape to command execution on a self-hosted AI Gateway. CVSS 9.9. CWE-1336.
- Auth: logged-in user with Duo Agent Platform access. Not unauthenticated.
- Not affected: GitLab.com, GitLab Dedicated, self-managed instances using a GitLab-hosted gateway.
- Affected gateway versions: 18.1.6 and later before 19.2.4; 19.3 before 19.3.2; 19.4 before 19.4.1.
- Fixed gateway versions: 19.2.4, 19.3.2, 19.4.1.
- Exploitation: CISA assessment “none” as of October 2, 2026. No public proof of concept noted in GitLab’s disclosure.
- Credit: HackerOne user invisiblemeerkat. Disclosed October 2, 2026.
Hunt / verify
- On the gateway host:
docker psorkubectl get deploy -Aand read the image tag. It should be 19.2.4, 19.3.2, or 19.4.1 or newer on that line. - Do not trust the GitLab admin UI version alone.
- Review who can create custom flows, and whether the gateway’s JWT signing key is in a secrets manager you can rotate.
Slack paste: Self-hosted GitLab AI Gateway only: bump the gateway image to 19.2.4, 19.3.2, or 19.4.1. GitLab.com is out of scope. CVE-2026-90970, no known exploitation yet — use the window.
Sources
- https://thehackernews.com/2026/10/gitlab-patches-critical-self-hosted-ai.html
- https://gitlab.com/gitlab-org/gitlab/-/work_items/628842
Start your morning with the signal that matters.
Get the biggest cybersecurity developments, why they matter, and where to go deeper on CyberExperts.
By subscribing you agree to our Privacy Policy.
Free. Weekdays. Built for operators.