On October 2, GitLab published a critical security release for its AI Gateway, the service that connects a GitLab instance to the language models behind Duo. The flaw is tracked as CVE-2026-90970 and carries a CVSS score of 9.9. Per the public reporting, a logged-in user with Duo Agent Platform access could run commands on the gateway under certain conditions. The fixed versions are 19.2.4, 19.3.2, and 19.4.1.
Two scoping details matter before anyone panics. First, the issue only affects organizations that run their own gateway. GitLab.com, GitLab Dedicated, and self-managed instances that use GitLab's hosted gateway were already patched and need no action. Second, exploitation requires an authenticated user with access to the agent platform, so this is not an unauthenticated internet-facing bug. That second point is less comforting than it sounds, and the rest of this article explains why.
This is also not the first time. In February, GitLab shipped fixes for CVE-2026-1868, another 9.9 in the same component family, described as insecure template expansion of user-supplied data through crafted Duo Agent Platform flow definitions. Two critical findings in the same product area in eight months is a signal about the category, not just about one vendor. Any self-hosted AI gateway deserves the scrutiny we usually reserve for CI runners and artifact stores.
Security teams often discount "requires authentication" when triaging. For AI gateways that discount is usually wrong, for three reasons that come from how these systems are deployed.
Treat the CVSS 9.9 literally. The score reflects that a low-privileged user can reach high impact across a trust boundary, which is precisely the situation in a multi-team engineering organization.
To see why this matters, list what a typical self-hosted gateway has in memory or on disk. In most deployments we review, the answer is longer than the owning team expects.
The gateway usually stores or reads API keys for one or more model providers, plus the tokens it uses to call back into the source control platform. Compromising it can mean spending money on someone else's account, reading prompts that contain proprietary code, and impersonating the platform to its own backend.
Every request that flows through carries source code, issue text, merge request discussions, and sometimes secrets that developers pasted into a chat window. Even if the gateway does not persist them, a foothold there lets an attacker observe traffic in flight. For regulated teams, that is a data exposure event regardless of whether anything was exfiltrated.
Gateways are frequently placed where they can talk to the platform, the model providers, and sometimes an internal inference cluster. That makes them a convenient jump host. If your network diagram shows the gateway in the same segment as your build runners, the blast radius extends to everything those runners can touch.
If you run a self-hosted gateway, here is the order of work we would follow this week.
Patching fixes this bug. It does not change the architecture that made the bug expensive. Three controls pay off regardless of vendor.
Run it as an unprivileged user in a container with a read-only root filesystem, dropped capabilities, and no mounted host paths. If an attacker gets command execution, they should land in a box with almost nothing in it. Pair that with a restrictive seccomp profile, and the cost of the next remote execution bug drops sharply.
Most gateways need to reach a short, known list of model endpoints and the platform itself. Enforce that list at the network layer with an egress proxy or network policy, and deny everything else. This single control turns many command execution bugs into noisy, low-value incidents because the attacker cannot download tooling or send data out.
Give the gateway its own network segment, separate from build runners and deployment infrastructure. Use short-lived credentials where providers allow them, and keep per-team provider keys so a leak is attributable and containable. If every team shares one master key, a gateway compromise is an organization-wide event.
Look at recent incidents and a pattern emerges. The flaws are not exotic model attacks. They are ordinary bug classes, template injection, command execution, missing authorization, showing up in the new layer of services that wraps models: gateways, agent runtimes, tool servers, and orchestration platforms. Those services are young, change fast, and often ship with broad privileges because teams are rushing to enable features.
The practical response is to bring them into the same lifecycle as everything else you operate. They need an owner, an inventory entry, a patch SLA, log shipping, and a threat model. A gateway that someone enabled during a pilot and forgot about is the most dangerous version, because nobody is watching its release notes.
Patch to a fixed release this week if you self-host, and verify your deployment model before assuming you are covered. Assume the gateway is a high-value target, so rotate its secrets, contain its network reach, and narrow who can use the agent features. Then treat the next AI platform release note the way you treat a runner or registry advisory, with a named owner and a deadline.
If you are not sure where your AI gateways, agent runtimes, and tool servers sit or who owns them, our AI consultancy and architecture review starts with exactly that inventory and turns it into a prioritized hardening plan.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.