A Duo User With a Flowchart Gets a Shell — GitLab’s 9.9 AI Gateway Sandbox Escape (CVE-2026-90970)

2026-10-02 AI Vulnerabilities & CVEs by al-ice.ai Editorial

GitLab's Friday advisory is the second time this year its AI Gateway has failed at the same boundary. CVE-2026-90970 — rated Critical, CVSS 9.9 — lets an authenticated user with Duo Agent Platform access escape the prompt template sandbox of a custom flow via a specially crafted flow configuration and execute arbitrary commands on the AI Gateway. That phrasing is GitLab's own, relayed in its 2 October 2026 advisory: the weakness is improper neutralisation in the template engine, CWE-1336, and the precondition is nothing more exotic than a login with access to the Duo Agent Platform.

The blast radius is bounded in one dimension and uncomfortable in another. Only organisations that host their own gateway are affected — GitLab.com, GitLab Dedicated, and self-managed instances using a GitLab-hosted gateway are already protected and need no action. But a self-hosted gateway is a credential-rich box: GitLab's install guide says it holds signing keys for JSON Web Tokens that must be treated as sensitive credentials, and it connects both to the GitLab instance and to the organisation's AI model providers. A shell there sits at the junction of source control and model traffic.

The versions that matter

The advisory's affected range, quoted verbatim across trackers, covers all AI Gateway versions from 18.1.6 before 19.2.4, 19.3 before 19.3.2, and 19.4 before 19.4.1. The fixes are 19.2.4, 19.3.2 and 19.4.1 — the same three lines GitLab's maintenance policy still supports with security fixes. Read that table the other way round and the gap appears: no fixed version is listed below 19.2.4, so every gateway from 18.1.6 through the 19.1 line sits inside the affected range with no patch line of its own, and the advisory does not say whether a 19.2.4 gateway interoperates with older GitLab minors. GitLab says it did targeted outreach to self-hosted gateway customers before publishing, and urges immediate upgrade — Docker deployments pull a new image tag such as self-hosted-v19.4.1-ee, Helm deployments set the new tag in the chart.

What the advisory does not contain is as notable as what it does. There is no workaround for gateways that cannot be updated yet, no detection guidance for checking whether a gateway was attacked before patching, and no named user role beyond Duo Agent Platform access. CISA's assessment on the CVE record, added the same day, lists exploitation as "none" — the lowest of its three values, short of even a public proof of concept. That is a snapshot, not a forecast: the precondition is an ordinary authenticated user, and custom flows — user-built AI workflows that automate multi-step tasks — are exactly the feature teams are encouraged to proliferate.

The pattern, not the product

February already ran this play. CVE-2026-1868, also rated 9.9, let a logged-in user reach the gateway through a crafted flow definition and cause denial of service or code execution — the same CWE-1336 template-engine class, the same flow-configuration attack surface, eight months apart. The new advisory does not mention the February flaw. Two 9.9s in one component in one year, both reachable by authenticated users through the feature that makes the gateway useful, suggests the sandbox around prompt templates is being patched hole-by-hole rather than re-thought.

And GitLab's September should sharpen the response. Last month the company patched a maximum-severity path traversal flaw (CVE-2026-85706) in Community and Enterprise Editions that exposed credentials and secrets to unauthenticated attackers — a flaw CISA added to its exploited-vulnerabilities catalog within a day, with a three-day federal patch deadline. That September patch wave, which we covered when GitLab's CI regex parser hid two 9.9 RCEs alongside four AI-feature fixes, keeps making the same point: the AI-adjacent surface — Duo, MCP scopes, gateways, prompt templates — is where GitLab's criticals now cluster. Defenders who still treat the AI Gateway as an accessory to the DevSecOps platform, patched on the platform's schedule, are a severity class behind.

What to do

Patch self-hosted gateways to 19.2.4, 19.3.2 or 19.4.1 now — the gateway has its own release line. The gateway ships as its own Docker image or Helm chart with its own update steps; a patched GitLab instance pointing at an unpatched gateway is still exposed. Gateways on 18.1.6 through 19.1 have no fixed version — plan an upgrade to a supported line, not a patch in place.
Treat the gateway as a credential store during incident review, not just a service. It holds JWT signing keys and talks to your model providers. Until you can rule out pre-patch exploitation — and the advisory gives no detection method — rotate gateway-held secrets and review Duo Agent Platform flow configurations for definitions you did not author.
Shrink who gets Duo Agent Platform flow authorship. The exploit precondition is an authenticated user with flow access. Custom flows accept configuration that reaches a template engine with a twice-broken sandbox; authorship should be a granted privilege with review, not a default entitlement.
Watch the KEV catalog, not just the advisory. CISA currently assesses exploitation as "none," but the September path-traversal twin went from patch to KEV in a day. If CVE-2026-90970 follows, federal deadlines will compress to days — patch on the advisory's timeline, not the catalog's.

Our verification was documentary: we fetched BleepingComputer's 2 October 2026 report and The Hacker News' same-day analysis, cross-checked the CVE identifier, CVSS 9.9 score, affected and fixed version ranges, CWE-1336 classification, HackerOne reporter credit (invisiblemeerkat), prior CVE-2026-1868 linkage, and CISA "none" exploitation assessment across both, with the advisory's affected-version wording confirmed verbatim via a third tracker. Quoted GitLab advisory phrasing is as relayed by these outlets. We did not test any GitLab instance or gateway and sent no traffic to any third-party deployment.

Sources: