GitLab disclosed a critical flaw in its self-hosted AI Gateway on October 2, 2026, and the numbers behind it are hard to ignore. The bug, tracked as CVE-2026-90970, carries a CVSS score of 9.9 out of 10, just a tenth of a point under the maximum. An authenticated user with access to GitLab’s Duo Agent Platform can craft a malicious flow configuration, break out of the prompt-template sandbox, and run arbitrary commands on the AI Gateway host, according to GitLab’s own advisory and reporting from The Hacker News and Security Affairs.
AI Gateway is the compute layer that powers GitLab Duo, the company’s AI coding assistant and agent suite. It runs on self-hosted GitLab instances and brokers the prompt flows that feed GitLab’s large language model integrations. A sandbox escape there does not just risk one repository. It risks the machine that every AI-assisted code suggestion, review, and automated flow passes through. GitLab shipped fixes within days, but the disclosure adds another entry to a growing 2026 list of near-maximum-severity bugs found in the tools developers now rely on to write and ship code faster. It joins a steady stream of security disclosures shattered.io has tracked this year, most of them pointing at the same weak spot: the infrastructure behind AI-assisted development.
What CVE-2026-90970 Actually Does
CVE-2026-90970 targets the prompt-template engine inside GitLab’s self-hosted AI Gateway. The GitHub Advisory Database and the official CVE record describe it as improper neutralization of special elements in a template engine, a flaw family better known as server-side template injection. In practice, a user who already has access to GitLab’s Duo Agent Platform can submit a specially built flow configuration that the engine fails to sanitize correctly. Instead of staying trapped inside the template sandbox, the malicious input escapes it and reaches the underlying operating system.
That escape hands the attacker arbitrary command execution on the AI Gateway host. It is worth being precise about the access bar here: this is not an anonymous, internet-facing bug. The attacker needs valid credentials and Duo Agent Platform permissions first. GitLab’s own documentation on how the Duo Agent Platform handles custom flows gives a sense of how deep that feature sits inside the product, and why a flaw there reaches so far.
Inside the Duo Agent Platform Sandbox Escape
Sandboxes exist precisely so that user-supplied templates, scripts, or flow logic can run without touching the host system underneath. GitLab built one into the AI Gateway so that custom Duo flows, the configurable automation chains that let teams wire AI steps into their pipelines, could execute safely even when written by users who are not platform administrators. CVE-2026-90970 shows that sandbox boundary was not airtight.
What a Prompt-Template Sandbox Is Supposed to Stop
A well-built sandbox stops a flow author from reaching anything outside the flow itself: no reading other users’ data, no touching the host filesystem, no spawning processes. The GitLab flaw breaks that model by letting a crafted flow configuration step outside the template engine’s intended boundary and execute commands directly on the gateway machine. Once an attacker can run commands on that host, they can plausibly pivot toward other services the AI Gateway talks to, including the models and credentials it uses to serve Duo requests across the instance.
Neither GitLab’s advisory nor the outlets covering it have published proof-of-concept exploit code, and this piece will not attempt to reconstruct one. What matters for defenders is the access chain: authenticated user, Duo Agent Platform permission, crafted flow, sandbox escape, command execution. Cut any link in that chain and the attack path closes.
Which GitLab AI Gateway Versions Are Affected
The CVE record lists three separate affected ranges inside the AI Gateway release line, which tracks the vulnerability across several months of shipped builds rather than a single release. Self-hosted instances running any of these ranges are exposed to CVE-2026-90970 until patched.
| AI Gateway Release Line | Affected Version Range | Fixed Version |
|---|---|---|
| 18.1.x – 19.2.x | 18.1.6 up to (not including) 19.2.4 | 19.2.4 |
| 19.3.x | Before 19.3.2 | 19.3.2 |
| 19.4.x | Before 19.4.1 | 19.4.1 |
That spread, from version 18.1.6 through the 19.4 branch, means the bug sat in production AI Gateway builds for multiple release cycles before GitLab’s security team caught and fixed it. Neither GitLab nor the databases tracking the advisory named the individual researcher or team who reported it, and no HackerOne submission has been publicly tied to the case. GitLab’s advisory credits the fix to its own security team without naming an external finder.
The Fix: GitLab Ships 19.2.4, 19.3.2, and 19.4.1
GitLab’s remediation path is straightforward on paper: upgrade the AI Gateway component to 19.2.4, 19.3.2, or 19.4.1 depending on which branch an instance tracks. The CVE record and GitHub Advisory Database both list October 2, 2026 as the publication date, with the National Vulnerability Database entry updated a day later on October 3. Admins running self-hosted GitLab with Duo Agent Platform enabled should treat the AI Gateway component as a standalone upgrade target, separate from the core GitLab Rails application, since the fix lives specifically in the gateway package.
# Check the installed AI Gateway version against the patched releases
docker exec gitlab-ai-gateway cat VERSION
# Patched releases to confirm you are running at or above:
# 19.2.4 (for the 18.1.6 - 19.2.x line)
# 19.3.2 (for the 19.3.x line)
# 19.4.1 (for the 19.4.x line)A GitHub Security Advisory tracking the issue under GHSA-5295-vp56-jghq mirrors the same version guidance, and GitLab’s release history is published on its official releases page for teams that need to confirm which build their instance is running before and after the upgrade.
Why AI Gateways Are Becoming a Prime Attack Surface
AI gateways sit at a strange junction in modern DevOps stacks. They hold model credentials, broker prompts, and increasingly execute multi-step agent flows on behalf of developers. That makes them valuable to attackers in a way a plain web server rarely is, because compromising the gateway can expose the keys and context an AI agent uses across an entire organization, not just one account.
The Agent Access Problem
Agent platforms like GitLab Duo, Salesforce Agentforce, and the AI gateways built into major cloud platforms all share a structural tension: they need to let users configure custom automation, but every configuration surface is also a potential injection point. GitLab’s shattered.io coverage of SalesBleed’s three flaws in Salesforce’s Agentforce and the CVSS 10 flaw in Azure AI Foundry both followed that same shape earlier this year. CVE-2026-90970 fits the pattern rather than breaking new ground, and that repetition is itself the story.
How CVE-2026-90970 Stacks Up Against Other 2026 Critical Flaws
GitLab’s AI Gateway bug lands in a crowded field this year. Several DevOps and AI-platform vendors have disclosed flaws scoring 9.5 or higher on the CVSS scale in 2026 alone. Lining them up shows just how routine near-maximum severity scores have become for the tools sitting closest to AI-assisted development.
| Vendor / Product | CVE | CVSS Score | Core Issue |
|---|---|---|---|
| GitLab AI Gateway | CVE-2026-90970 | 9.9 | Authenticated sandbox escape to command execution |
| WSO2 API Manager | — | 10.0 | Exploit gap of roughly four months, per shattered.io reporting |
| Cisco ISE | CVE-2026-76460 | 10.0 | Zero-day with no available workaround, per shattered.io reporting |
| Azure AI Foundry | — | 10.0 | Platform-side flaw patched without customer action, per shattered.io reporting |
| ConnectWise ScreenConnect | CVE-2026-84869 | 9.9 | Flaw under a three-day CISA remediation deadline, per shattered.io reporting |
| JetBrains TeamCity | CVE-2026-63077 | 9.8 | Exploited in ransomware attacks against roughly 160 servers, per shattered.io reporting |
What separates the GitLab case from several rows on that list is the access requirement. Cisco’s ISE zero-day and WSO2’s API Manager flaw involved far lower bars to exploitation. GitLab’s AI Gateway bug needs a logged-in user with Duo Agent Platform rights first. That narrower path is likely why GitLab landed at 9.9 rather than a flat 10.0, even though the outcome, arbitrary command execution, looks similar once an attacker clears that bar.
CVSS 9.9 Explained: Why Authentication Didn’t Lower the Score
CVSS scoring weighs several factors beyond whether an attacker needs credentials. Impact matters just as much as access. A flaw that grants arbitrary command execution on a host holding model credentials and proxying every AI-assisted code interaction scores high on confidentiality, integrity, and availability impact, even when the attacker needs to be logged in first. GitLab and the databases tracking CVE-2026-90970 have not published the exact CVSS vector string, so the precise breakdown of each metric is not public. The headline 9.9 figure is consistent across the CVE record, the GitHub Advisory Database, and the outlets that covered the disclosure, which gives confidence in the number even without the full vector.
Security teams should read that 9.9 as a signal about blast radius rather than ease of attack. An insider threat, a compromised developer account, or a contractor with excessive Duo Agent Platform permissions could all serve as the entry point an exploit needs.
No Known Exploitation Yet, But the Clock Is Running
As of this reporting, no evidence points to in-the-wild exploitation of CVE-2026-90970, and the flaw has not appeared on the CISA Known Exploited Vulnerabilities catalog. That absence of confirmed abuse is good news, but it is a snapshot, not a guarantee. Public disclosure of a detailed vulnerability class, template sandbox escape leading to command execution, tends to accelerate research interest even when no proof-of-concept has leaked publicly. The gap between disclosure and the first observed exploitation attempt has shrunk across 2026’s wave of critical CVEs, and GitLab’s self-hosted customer base is large enough to make this one worth tracking closely.
Rapid7’s vulnerability database logged the issue on the same day GitLab’s advisory went public, a sign that the vulnerability research community picked it up quickly. That speed cuts both ways. It helps defenders learn about the bug fast, and it also shortens the window before someone tries to reverse-engineer an exploit from the public advisory text alone.
A Pattern Emerges: AI Coding Tools Keep Shipping Critical Bugs
CVE-2026-90970 is not an isolated incident in the AI coding tool space this year. Shattered.io’s own coverage of Plugin4Shell bypassing SHA-pinning across four different AI coding agents documented a similar theme: features built to make AI-assisted development faster and more automated keep introducing bugs that undercut the security guarantees those same features were supposed to preserve. Add Nvidia’s push to build dedicated AI agent safety tooling with more than 100 partners, and a clear industry response is forming around the recognition that agent platforms need their own security category, not just inherited protections from the base products they extend.
The common thread across these cases is sandboxing. Every vendor building an AI agent or coding assistant has to answer the same question: how do you let users configure flexible, scriptable behavior without giving them a path to the underlying system? GitLab, Salesforce, and Microsoft’s Azure AI Foundry team have each shipped a version of that mistake in 2026. None of them did it carelessly. Sandboxing a template engine against every creative escape attempt is a genuinely hard engineering problem, and the industry’s track record this year suggests most teams are still working through it in production rather than solving it ahead of launch.
From DevOps CVEs to AI Gateway CVEs: A Short History
DevOps platforms have been a ransomware and espionage target for years. JetBrains TeamCity’s CVE-2026-63077 fed real-world ransomware intrusions against roughly 160 servers, and Atlassian, Jenkins, and GitLab itself have all weathered critical bugs in their core products across prior years tied to build pipelines, CI/CD runners, and authentication bypasses. What is new in 2026 is the shift in target: instead of attacking the pipeline that builds and deploys code, attackers and researchers are now finding flaws in the layer that generates and reviews code through AI.
That shift tracks the product shift. Two years ago, GitLab Duo was a feature add-on. In 2026, AI Gateway is infrastructure, running continuously, holding credentials, and executing flows with minimal human review at every step. Treating it with the same security rigor historically reserved for CI/CD runners and build servers is the logical next step, and GitLab’s own quick patch turnaround suggests the company’s security team already sees it that way.
What This Means for Enterprise GitLab Customers
For GitLab’s enterprise self-hosted customers, the practical fallout is an unplanned patch cycle rather than a breach notification. GitLab.com’s own hosted service is not described as affected in any of the available reporting, since the exposure is specific to self-hosted AI Gateway deployments running Duo Agent Platform. That narrows the customer base that needs to act, but it does not shrink it to a trivial size. GitLab counts a large share of regulated enterprises, government contractors, and financial institutions among its self-hosted customer base precisely because those organizations need to keep source code and AI processing inside their own infrastructure.
Those same organizations tend to run slower patch cycles than cloud-native shops, which raises the real risk here. A critical flaw with a known fix sitting unpatched for weeks inside a bank’s or a defense contractor’s self-hosted GitLab instance is a more attractive target than the same flaw inside a startup that redeploys infrastructure daily. GitLab’s advisory gives customers a specific, narrow upgrade path, which should make triage faster than it would be for a vaguer, harder-to-scope disclosure.
A Patch Checklist for Security and Platform Teams
Teams running self-hosted GitLab with Duo Agent Platform enabled have a short, specific list of actions to work through this week.
- Confirm whether Duo Agent Platform is enabled on any self-hosted GitLab instance in the environment.
- Check the installed AI Gateway version against the affected ranges: 18.1.6 through before 19.2.4, before 19.3.2, and before 19.4.1.
- Upgrade to 19.2.4, 19.3.2, or 19.4.1 depending on the active release branch.
- Audit which users and service accounts hold Duo Agent Platform permissions, and trim access that is not actively in use.
- Review AI Gateway host logs for unusual command execution or process spawning around the disclosure window.
- Treat GitLab’s AI Gateway as a distinct patch target going forward, separate from routine GitLab Rails updates.
None of these steps require exotic tooling. The harder part is organizational: many security teams still treat AI Gateway as a feature extension bundled with GitLab rather than a standalone service with its own patch cadence and its own permission model that deserves separate review.
Five Predictions for AI Gateway Security Through 2027
GitLab’s disclosure offers a useful marker for where AI gateway security is headed over the next year.
- Expect more CVSS 9-plus disclosures tied specifically to AI agent and flow-configuration features, as researchers now know where to look after this case and the Plugin4Shell and SalesBleed disclosures earlier in 2026.
- Vendors will start separating AI gateway components into their own release and patch tracks, mirroring how CI/CD runners eventually got dedicated security treatment after years of pipeline attacks.
- CISA or an equivalent national authority will likely push for AI gateway and agent platforms to appear explicitly in future Known Exploited Vulnerabilities guidance once a case with confirmed in-the-wild exploitation surfaces.
- Enterprise buyers will increasingly ask AI coding vendors for sandbox-escape testing results during procurement, the same way they already ask about SOC 2 and penetration test history.
- Expect at least one more major DevOps or AI platform vendor to disclose a sandbox-escape-class bug before the end of 2026, given how closely GitLab’s, Salesforce’s, and Microsoft’s cases this year resemble each other in root cause.
None of these are guarantees. They follow directly from the pattern this year’s disclosures have already set, and GitLab’s quick three-version patch rollout suggests the company is already preparing for more scrutiny of AI Gateway rather than less.
Frequently Asked Questions
What is CVE-2026-90970?
It is a critical vulnerability in GitLab’s self-hosted AI Gateway, rated CVSS 9.9, that lets an authenticated Duo Agent Platform user escape the prompt-template sandbox and execute arbitrary commands on the AI Gateway host.
Which GitLab versions are affected?
AI Gateway releases from 18.1.6 up to before 19.2.4, the 19.3 line before 19.3.2, and the 19.4 line before 19.4.1 are affected.
How do I fix it?
Upgrade the AI Gateway component to 19.2.4, 19.3.2, or 19.4.1, depending on which release branch the instance currently tracks.
Does this affect GitLab.com’s hosted service?
Available reporting describes the exposure as specific to self-hosted AI Gateway deployments running Duo Agent Platform, not GitLab’s hosted SaaS offering.
Has CVE-2026-90970 been exploited in the wild?
No evidence of in-the-wild exploitation has surfaced as of this reporting, and the flaw does not currently appear on the CISA Known Exploited Vulnerabilities catalog.
Why does a flaw that requires authentication still score 9.9?
CVSS scoring weighs the severity of the outcome alongside the access required to trigger it. Arbitrary command execution on a host that holds AI model credentials and brokers every Duo interaction carries a high impact score even when the attacker needs valid credentials first.
Who discovered the vulnerability?
GitLab’s advisory and the databases tracking the CVE do not name an outside researcher or firm. GitLab’s own security team is credited with the remediation.
Where can I verify the technical details myself?
The CVE record is tracked on the National Vulnerability Database and mirrored on the GitHub Advisory Database under GHSA-5295-vp56-jghq, alongside GitLab’s own version history on its releases page.
