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

By George Bailey   Published: 10/05/26   Updated: 10/10/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.

Get the CyberExperts Daily Brief: the day's top security news in 5 minutes. Free.

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

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

Stay Current

Newer CyberExperts coverage on this topic

This article still works as background. If you want the current picture, start with the freshest related coverage below and today's brief.

Latest Daily Brief

Wednesday’s brief: Barracuda gateways go from no login to root, then Chrome 157, cPGuard and WordPress

The fastest way to catch up on what changed after this article was published.

Read Today's Brief

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].