A logged-in user with Duo Agent Platform access can, under certain conditions, run commands on GitLab’s self-hosted AI Gateway. GitLab scored the flaw 9.9 and shipped fixes in gateway versions 19.2.4, 19.3.2, and 19.4.1. The gateway is the service that connects a GitLab instance to AI models. Only shops that host that connector themselves are in scope. If Duo is live on a box you operate, this is a same-day cybersecurity ticket. Folding it into the next GitLab upgrade cycle leaves a command-execution path sitting next to your source and your model keys.

Authenticated Duo User, Command Execution on the Self-Hosted Gateway

Your source-control platform grew a sidecar. The AI Gateway sits between GitLab and whatever model you pointed Duo at. A 9.9 on that host is command execution with a principal GitLab already trusted. Identity did its job. You still get a shell. The advisory is explicit: Duo Agent Platform access is part of the condition set. If you rolled Duo out because it felt like a coding assistant, you expanded the set of people who can reach a critical execution surface.

Most GitLab hardening work stops at the rails app, the runners, and the registry. The gateway is newer, thinner, and easier to omit from the asset list. It still runs on a server you own. It still has a listener. It still inherits tokens, model API keys, proxy settings, and whatever the process can read from disk or the environment. From that box you also inherit the east-west routes the gateway needs so it can talk to GitLab and the model provider. Those routes are the blast radius.

SaaS GitLab.com is the wrong mental model here. Self-hosting the gateway was a data-residency and control choice. This CVE is the ops bill for that choice. If the connector is down, Duo is dark. If the connector is up and unpatched, a logged-in Duo user is a candidate for host-level execution. Pick the outage. You can schedule a dark window. You cannot schedule the first public exploit path.

Microsoft: AI Finds and Weapons Bugs Faster Than Patch Queues

Microsoft’s 2026 Digital Defense Report, covering July 2025 to June 2026, describes attackers using AI to find bugs, build malware, and run intrusions faster than defenders can keep up. The company called it a near-term stretch where attackers collect the AI benefit first. Vulnerability discovery and weaponization used to have slack in them. That slack is gone. “AI is changing the physics of cybersecurity,” Microsoft said. You can argue with the metaphor. You should not argue with the clock.

A 9.9 on a self-hosted model connector is exactly the class of bug that report is describing. You do not get a leisurely maintenance window. If AI is helping people find and weaponize flaws faster than they get fixed, your job is to cut exposure before a write-up turns into a pastebin. Threat detection that only watches the GitLab web UI will miss this. The interesting process is on the gateway host. If your threat-protection stack is tuned for brute-force against sshd and 443 on the main GitLab VIP, you are watching the wrong door. The login already succeeded.

Treat the advisory as a race, not a newsletter item. The people who will poke this first already have Duo-shaped labs and a reason to care about model gateways. Your change ticket should read like an emergency isolation, with a patch, a key rotation, and a hunt. A “monitor for exploitation” line with no host-level telemetry is theater.

Cybersecurity Hardening for Isolated AI Gateway Hosts

Start with inventory. You cannot patch a connector you never listed. Search for AI Gateway packages, Duo Agent Platform nodes, and anything that presents the Duo model path. Confirm versions against 19.2.4, 19.3.2, and 19.4.1. If you cannot patch in hours, isolate first. Drop inbound from the general user network. Allow GitLab and an admin jump path only. If Duo can stay dark for a day, cut egress to the model provider so a shell has nowhere useful to call.

Rotate secrets after the patch, not before you know the box is quiet. Model API keys, GitLab tokens, and environment files on that host are in scope. Assume a logged-in Duo user could have read them. Hunt process trees, unexpected child shells, and outbound callbacks from the gateway service account. That hunt is incident response even if no alert fired. Defense in depth on GitLab that ignores this host is a diagram, not a control.

Put the gateway in a dedicated security group or VLAN. Users do not need a direct path to it; GitLab does. Default-deny inbound. No public IP. Your firewall policy for the GitLab VIP does not automatically cover a sidecar someone launched with a compose file. Auth still matters because this bug needs a logged-in user. Scope Duo Agent Platform to a named group. Watch for brute-force against GitLab logins that mint the session the gateway will trust. Fail2ban-style ipban controls, and tools such as IPBan Pro on the GitLab login path, shrink the set of sessions that can reach a 9.9. They do not replace the patch.

Keep one cheap canary: a rule that fires if the gateway process spawns a shell, a compiler, or a cloud CLI. Prove it with a test after every gateway upgrade. Silent rules are how you learn about command execution from a model bill.

• Confirm every AI Gateway host and patch to 19.2.4, 19.3.2, or 19.4.1 today
• Restrict gateway listeners to GitLab and admin networks; remove user-LAN and public reachability
• Revoke and reissue model keys and GitLab tokens bound to the gateway after isolation
• Scope Duo Agent Platform to a named group and remove org-wide access
• Alert on shells or unexpected children from the gateway service account, then test the alert

After Defenses Fail, Hunt the Gateway as a Compromised App Tier

RemoteThreat is betting that security teams need to test what happens after defenses fail. That is the right question for this advisory. GitLab auth and the edge firewall are the defenses. Both can succeed and you still get command execution on the gateway. A tabletop that stops at “we patched” never leaves the ticket queue.

Run the failure path. Assume a Duo user got a shell on the gateway last Tuesday. What can they read? Which tokens sit in env? Can they reach runners, a database exporter, or the package registry from that subnet? Does anyone notice a curl to a random IP from that host? Who owns the box in the CMDB? If the answer is “platform, maybe,” you have found the real gap.

Cyber security programs like to declare the SCM done because MFA is on and the scanner is green. The model connector is a separate program. Give it an owner, a critical patch SLA measured in hours, and a post-compromise drill that starts at command execution. If you never self-hosted the gateway, record that you accepted the vendor’s isolation story. If you self-hosted for residency, this 9.9 is what that burden looks like on a Friday.

Sources

• GitLab Patches Critical 9.9 AI Gateway Flaw Allowing Command Execution on Self-Hosted Servers
• AI is giving attackers a head start, Microsoft warns
• RemoteThreat Bets Security Teams Need to Test What Happens After Defenses Fail