GitLab fixed a critical AI Gateway flaw, its own servers first

"GitLab has remediated an issue in the GitLab AI Gateway that, under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway."

Put simply, someone who could already log in and use GitLab's AI agent tools could have broken out of a fenced-off area and run their own commands on the gateway server. The flaw is in the prompt templates behind custom flows. Those are AI workflows people build on the Duo Agent Platform to automate tasks with several steps.

Why does a code-hosting company have an AI gateway at all? GitLab's Duo features, from code suggestions to chat to agents, send requests to large language models. The gateway sits in the middle, passing those requests along and handling the answers. GitLab runs one for most customers. Some organizations would rather keep that traffic in-house, so they run their own through GitLab Duo Self-Hosted.

This isn't a bug just anyone on the internet could hit. The attacker needs an account and access to the agent platform. GitLab still rated it critical, though, because the gateway is a sensitive box. GitLab's own install guide says a self-hosted gateway holds signing keys for the tokens it issues, and that those keys "must be treated as sensitive credentials." The Hacker News flagged the same point. The gateway also talks to the GitLab instance and to the organization's AI model providers.

Who needs to update

GitLab is clear about who's already safe. Its post says "a fix has already been deployed for GitLab-hosted AI Gateways." Customers on GitLab.com, GitLab Dedicated, and self-managed installations that use a GitLab-hosted gateway "are protected and do not need to take action."

That leaves the self-hosted crowd. GitLab lets self-managed customers run their own gateway, mostly so AI requests and answers stay inside their own network. If that's you, these are the affected versions, according to GitLab:

• every gateway version from 18.1.6 up to, but not including, 19.2.4
• 19.3 versions before 19.3.2
• 19.4 versions before 19.4.1

The fixed versions are 19.2.4, 19.3.2 and 19.4.1. The gateway is installed separately from GitLab itself, as a Docker image or a Helm chart, so it has its own update steps. GitLab points admins to its self-hosted gateway install documentation.

There's one gap to know about. No fix is listed below 19.2.4, so gateways from 18.1.6 through the 19.1 line don't get a patched version on their own branch. The Hacker News pointed out that GitLab's install guide tells admins to match the gateway to their GitLab minor version, and the advisory doesn't say whether a 19.2.4 gateway works with older GitLab releases. If you're on an older line, the safe move is to plan an upgrade of GitLab itself. GitLab's maintenance policy currently lists 19.4, 19.3 and 19.2 as the releases that get security fixes.

GitLab hasn't listed a workaround for gateways that can't be updated yet. The Hacker News also noted that the advisory doesn't explain how to tell whether a gateway was tampered with before it was patched.

That second gap matters more if lots of users can reach your gateway. It's sensible to check the gateway's logs for anything odd. Our suggestion: rotate its signing keys after the update. It's cheap insurance, though GitLab hasn't asked customers to do it.

Has anyone been hit?

There's no sign of it. GitLab's post doesn't mention any attacks. And CISA added an assessment to the CVE record on 2 October that lists exploitation as "none."

That's the best way for a critical bug to show up. It gets found, fixed on the vendor's own servers, quietly flagged to the customers who need to act, and only then announced. GitLab says it did that outreach "prior to this release post."

GitLab thanked a researcher using the handle invisiblemeerkat "for responsibly disclosing this issue." The credit on the CVE record links to that researcher's HackerOne profile, and HackerOne is where GitLab runs its bug bounty.

It's not the first flaw of its kind, either. GitLab fixed another AI Gateway bug, CVE-2026-1868, in February, and rated that one 9.9 too. Both are template engine weaknesses in the same class. AI plumbing is new code, and new code is where researchers are finding things. We saw the same pattern in September when CISA's catalog picked up a flaw in LiteLLM, the AI model proxy, in CISA adds seven exploited flaws, including LiteLLM, to KEV.

Why it's worth doing today

GitLab has had a busy few weeks. BleepingComputer reported that last month GitLab patched a maximum-severity path traversal bug, CVE-2026-85706, in its Community and Enterprise editions, and CISA added it to its exploited-flaws list a day later.

That's the reason not to sit on this one. The AI Gateway bug isn't on CISA's list, and with luck it never will be. But once a fix is public, people start comparing the old code with the new. The gap between "patch released" and "someone's using it" keeps getting shorter. CISA keeps that list in its Known Exploited Vulnerabilities catalog, and CISA's three-day patch clocks explain how fast US agencies now have to move once a bug lands there.

If you run your own gateway, the checklist is short:

• Check which gateway version you're running.
• Update to 19.2.4, 19.3.2 or 19.4.1, whichever matches your line.
• Review who has Duo Agent Platform access, since that's the access the attack needs.

What I won't do is explain how the template escape works. GitLab hasn't published those details, and I'm not going to fill them in. Patch first. The write-ups can wait.