CVE-2026-90970 hits the self-hosted GitLab AI Gateway with a 9.9 CVSS score. Who’s exposed, why patching alone isn’t enough, and what to check this week.
Table of Contents
GitLab shipped three emergency point releases on October 2 for a flaw that lives somewhere most self-hosted GitLab admins never think to check: the AI Gateway that powers Duo’s agent features. CVE-2026-90970 carries a CVSS score of 9.9, one tick below the maximum, and it affects a specific, narrow slice of GitLab deployments that happen to overlap heavily with the kind of small-to-midsize teams running GitLab on their own VPS or dedicated server rather than paying for GitLab.com or GitLab Dedicated.
How the GitLab AI Gateway flaw works
The vulnerability sits in how GitLab’s Duo Agent Platform handles custom flows, specifically the prompt templates those flows use. A user who already has access to the platform’s agent features can submit a specially crafted flow configuration that escapes the prompt template sandbox. GitLab’s own advisory classifies it under CWE-1336, improper neutralization of special elements in a template engine, which is a precise way of saying the sandbox trusted input it shouldn’t have. The result is arbitrary command execution on the AI Gateway host itself.
That “already has access” detail matters and most of the breathless coverage glosses over it. This isn’t an anonymous-attacker-from-the-internet bug. It requires a logged-in user with Duo Agent Platform permissions, which narrows the realistic threat model to insiders, compromised internal accounts, or anyone who’s been handed broader platform access than they should have. For a five-person dev shop where everyone has admin rights on the GitLab instance anyway, that distinction barely matters. For a larger org with real access tiers, it changes who you need to worry about.
What a “custom flow” even is
If you’ve never touched Duo Agent Platform, the terminology is the first barrier to understanding your own exposure. A custom flow is a configurable sequence of steps an AI agent runs against your GitLab data, things like “summarize every open merge request older than 30 days” or “draft a changelog entry from this week’s merged commits.” Teams build these to automate the kind of busywork that normally eats an engineering lead’s Friday afternoon.
The prompt template is the piece of each flow that tells the agent how to phrase its instructions and what data to pull in, and it’s exactly that template layer where the sandbox escape happens. Building a custom flow is meant to be approachable enough for a team lead to do without engineering help, which is also precisely why access to create one shouldn’t be treated as a low-stakes permission.
Who’s exposed, and who isn’t
GitLab drew a clean line here, and it’s worth reading carefully because it determines whether this CVE is a five-minute non-event or a this-week priority.
Not affected: GitLab.com users, GitLab Dedicated customers, and self-managed GitLab installations that point their Duo Agent Platform at a GitLab-hosted AI Gateway rather than running their own.
Affected: organizations running their own self-hosted AI Gateway instance. If you installed GitLab yourself on a VPS and never touched Duo or AI Gateway configuration, you’re not running the vulnerable component and this CVE doesn’t apply to you. If you deliberately stood up a self-hosted gateway to keep AI Gateway traffic inside your own network (a reasonable, common choice for teams with data-residency concerns), you’re in the blast radius.
The affected version ranges are specific: Gateway 18.1.6 through 19.1.x entirely, 19.2.x before 19.2.4, 19.3.x before 19.3.2, and 19.4.x before 19.4.1. GitLab’s fixed releases are 19.2.4, 19.3.2, and 19.4.1.
Why “just patch it” isn’t quite the full answer
GitLab’s advisory is unusually blunt about the limits of this fix: there is no workaround for gateways that can’t patch immediately, and there’s no method provided to detect whether the vulnerability was exploited before you patched. That second point is the one worth sitting with. Patching closes the door going forward; it doesn’t tell you whether someone already walked through it. If your self-hosted AI Gateway has been running an affected version for any length of time with real Duo Agent Platform usage, patching should be followed by a look at whatever command-execution or process-level logging you have on that host, not just a version bump and a shrug.
The vulnerability was reported through HackerOne by a researcher using the handle “invisiblemeerkat,” and as of October 2, CISA’s assessment listed no evidence of active exploitation and no public proof-of-concept code. That’s good news today. It’s also exactly the kind of critical, no-PoC-yet bug that tends to get a working exploit published within a week or two once researchers start picking apart the patch diff, so “no active exploitation yet” is not a reason to deprioritize this.
Should your team even be running its own gateway?
This CVE is a reasonable prompt to revisit a question on its own merits: why are you self-hosting the AI Gateway in the first place? For teams with genuine data-residency requirements (code or commit metadata that legally cannot leave your own infrastructure), the answer is clear and this CVE is just a cost of that decision; patch promptly and move on. For teams that stood up a self-hosted gateway by default, because that’s how the setup guide was written, or because nobody specifically chose the GitLab-hosted option, this is a good moment to reconsider.
GitLab-hosted gateways get patched centrally without you doing anything, and they’re explicitly outside the blast radius of this specific CVE. Running infrastructure you don’t need is its own quiet risk, independent of any single vulnerability.
The first question to answer: are you even running this?
Before doing anything else, confirm whether your installation has a self-hosted AI Gateway deployed at all. A meaningful number of self-managed GitLab instances, especially smaller ones on VPS or dedicated infrastructure, never set up Duo Agent Platform or its gateway component in the first place. If that’s you, this CVE is a non-issue and you can move on. If you’re not sure, check your GitLab admin area for AI Gateway configuration or ask whoever set up your instance whether Duo’s agent features were ever enabled. Don’t assume based on your GitLab edition; this is about whether the AI Gateway service specifically is running, not whether you’re on Community or Enterprise Edition.
If you are running a self-hosted gateway, the sequence is straightforward: identify your current gateway version, confirm it falls in the affected range, upgrade to 19.2.4, 19.3.2, or 19.4.1 depending on your branch, and then review platform access lists for your Duo Agent Platform to make sure the people who can create custom flows are the people who should be able to. Tightening that access list doesn’t fix the underlying sandbox flaw, but it does shrink the pool of accounts that could exploit it while you schedule the upgrade.
A pattern worth noticing, not just a one-off CVE
This isn’t the first time a critical GitLab vulnerability has specifically targeted a feature that self-hosted installations opted into rather than core version control functionality; we walked through the patch process for an earlier self-hosted GitLab CVE here, and the pattern holding across both incidents is consistent: the attack surface keeps shifting toward the add-on features, not the base product. It also echoes a KVM isolation flaw we covered that hit VPS hosts because of a feature layered on top of the hypervisor, not the hypervisor’s core virtualization logic.
AI Gateway, agent platforms, custom flow engines, these are all relatively new surfaces bolted onto mature software, and new surfaces get less scrutiny than code that’s been hardened for a decade.
That’s not a knock on GitLab specifically. It’s a reason to treat every AI-adjacent feature you’ve enabled on self-hosted software, from any vendor, as a genuinely separate thing to patch and monitor, not an extension of a product you’ve already locked down. If your team evaluates new GitLab features by asking “does this run on our server or does GitLab run it for us,” you’ll catch issues like this one faster than reading CVE databases after the fact.
What to do this week
If you’re running self-hosted GitLab on your own VPS or dedicated server, three things are worth doing in order: confirm whether AI Gateway is deployed at all, patch to the fixed release for your branch if it is, and audit who currently has Duo Agent Platform access regardless of whether you’ve patched yet. None of this requires GitLab support or a consultant; it’s a version check, an upgrade, and a permissions review. The part that takes real judgment is the logging review if you’ve been running an affected version for a while, since GitLab itself doesn’t give you a clean way to confirm after the fact whether the flaw was used against you.
GitLab’s own advisory and The Hacker News’ coverage have the full technical detail if you need it for an internal security writeup. For most small teams running their own instance, the short version above covers what changes this week.