Three Things That Broke When GitLab Handed Its AI Gateway a 9.9

The AI Gateway was supposed to be the boring part. A thin service that sits between your GitLab instance and whatever model is answering your developers’ questions this quarter. Nobody files a change ticket to think hard about the plumbing between the IDE and the LLM. That’s precisely how a service ends up privileged, trusted, and running with more reach than anyone remembers granting it.

Then GitLab shipped an advisory rating a flaw in that plumbing 9.9 out of 10. For context, 10.0 is reserved for the kind of thing that ruins a long weekend from the public internet with no credentials. A 9.9 is its slightly more polite sibling: it wants someone to be logged in first, and then it will cheerfully let that someone run commands on the box.

Three things broke when that score landed. Let me walk the timeline, because the order matters more than the panic.

Beat one — the Gateway shipped as “just the connector”

The AI Gateway is the component that brokers GitLab Duo traffic: it takes requests from your GitLab instance and talks to the model backends, self-hosted or vendor-provided. The Duo Agent Platform rides on top of that — the feature set the advisory specifically ties to this flaw.

Architecturally, it’s a classic trust chokepoint. Everything AI-flavoured funnels through one service, and that service runs close enough to your infrastructure to be useful. Useful and privileged are the same word with different PR departments.

What broke here was an assumption. The Gateway was treated as glue — low-ceremony, low-scrutiny — while quietly being a component that, if it executes attacker-chosen commands, hands you a foothold inside the GitLab deployment. That’s the lateral-movement risk the advisory is really about. Command execution on the Gateway isn’t the prize; it’s the doorway.

Beat two — this week, the advisory posts

GitLab published the security advisory this week describing a critical vulnerability in the AI Gateway that allows command execution. The conditions, as GitLab states them:

• Self-hosted GitLab only. If you live on GitLab.com SaaS, GitLab operates that stack. This advisory is about the Gateway you deployed yourself.
• Duo Agent Platform must be enabled. No Duo, no exposed surface. An instance without the AI features turned on is not in scope for this particular flaw.
• The attacker must be authenticated and hold Duo Agent Platform access. This is not unauthenticated RCE. Someone needs a valid login with the relevant permission.

Resist the urge to exhale at that last point. “Authenticated user” on an internal developer platform is not a high bar. It’s every engineer, every contractor, every service account someone wired up and never rotated, and every credential that leaks through a phished laptop or a committed token. The 2 a.m. version of this incident isn’t a shadowy external actor — it’s a developer account that got popped, and now the attacker is running commands through a service you forgot counted as attack surface.

That’s why the 9.9 is honest. The authentication requirement knocks a tenth off the theoretical maximum, and the rest of the score reflects that the payoff is command execution on a privileged service.

One guardrail I’ll hold firmly: I’m not going to describe the mechanism, and GitLab wisely didn’t hand out a recipe either. You don’t need to understand how the lock works to know you should change it.

On version numbers — and a sourcing note you should respect. The brief asks for exact affected and patched version strings, and I’m not going to print numbers I can’t stand behind. The reporting I’m working from describes the flaw, the 9.9 rating, and the self-hosted-plus-Duo preconditions, but does not give me a verified affected-through / fixed-in range I’d trust in your change ticket. So treat this as a flagged gap: the authoritative version strings live in GitLab’s official advisory, which lists the affected range and the fixed releases across GitLab’s most recent supported minor lines. Pull them from there, match them to what you run, and don’t take a version string from a blog — including this one.

Beat three — the morning after, you find out what you actually run

Here’s the part that breaks for most teams: nobody is certain whether Duo Agent Platform is enabled, or where the Gateway is running. It got switched on during an AI pilot, the pilot became permanent through inertia, and the runbook never caught up.

So before you schedule anything, inventory. Report-only, nothing destructive:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# --- Report mode only. Nothing here changes state. ---
​
# 1) What GitLab version is actually installed?
sudo gitlab-rake gitlab:env:info 2>/dev/null | grep -iE 'gitlab version|version'
​
# Omnibus fallback if rake isn't handy:
sudo head -n 20 /opt/gitlab/version-manifest.txt 2>/dev/null
​
# 2) Is an AI Gateway / Duo service running on this host?
#    Container deployments:
sudo docker ps --format '{{.Image}}\t{{.Names}}\t{{.Status}}' 2>/dev/null \
  | grep -iE 'ai-gateway|duo' || echo "no ai-gateway/duo containers seen"
​
#    Systemd / process view:
sudo systemctl list-units --type=service 2>/dev/null \
  | grep -iE 'ai.gateway|duo' || echo "no ai-gateway/duo services seen"
ps -ef | grep -iE 'ai[-_]gateway|duo' | grep -v grep
​
# 3) Is Duo configured in the GitLab Rails config?
sudo grep -riE 'duo|ai_gateway' /etc/gitlab/gitlab.rb 2>/dev/null \
  | grep -vE '^\s*#' || echo "no explicit duo/ai_gateway config in gitlab.rb"

Cross-check the application side too: in the GitLab admin area, confirm whether GitLab Duo / Agent Platform is enabled for the instance and which groups or users carry the access. The command-line view tells you what’s deployed; the admin settings tell you who can reach it. You want both answers before you decide how fast to move.

The order of operations, from most to least obvious

Lead with the patch. Upgrade self-hosted GitLab to a fixed version listed in GitLab’s advisory — this is the real fix, and everything below is a stopgap for the hours or days until your change window opens. Match your current minor release to GitLab’s patched release for that line so you’re not forced into a larger upgrade under pressure.

If you genuinely can’t patch tonight, GitLab’s own guidance points at reducing the exposed surface, and the logic is straightforward:

• Disable the Duo Agent Platform if you can live without the AI features for a day or two. No Duo access, no precondition for the flaw. This is the cleanest compensating control and the one I’d reach for first.
• Restrict Duo Agent Platform access to the smallest possible set of trusted accounts if a full shutoff isn’t politically survivable. Fewer holders of the required permission means fewer accounts that can be abused — a smaller blast radius, not a fix.
• Watch the Gateway in the meantime. Unusual process spawns or outbound connections from that service during the exposure window are exactly what you’d want your EDR and host logs flagging.

Treat compensating controls as what they are: a tourniquet. They buy time; they don’t close the wound. The upgrade does.

Urgency: this week, and lean toward tonight

Call it immediate for internet-reachable instances, this week for everyone else running Duo. A 9.9 with authentication as the only gate, on a self-hosted developer platform where authenticated accounts are plentiful and occasionally compromised, is not a next-cycle ticket. GitLab’s advisory does not mention active exploitation, and I won’t manufacture a threat actor for you — but the arithmetic of “any logged-in Duo user → command execution → lateral movement” doesn’t need embellishment to justify a short change window.

The next dated beat on the calendar is yours to set: the maintenance slot where you apply the fixed release. Put it on the board before the one where someone asks why the AI plumbing had a shell.