Self-hosted GitLab AI gateways can run commands from a flow

By George Bailey   Published: 10/05/26   4 min read

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.

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

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

Hunt / verify

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

George Bailey

George Bailey is a cybersecurity researcher and writer at CyberExperts, covering cyber threats, AI, cloud security, vulnerabilities, and defensive strategies. His goal is to help security professionals quickly understand what matters most and how it impacts their organizations.