Any Duo Agent Platform account can run arbitrary commands on a GitLab AI Gateway server
GitLab has patched CVE-2026-90970, a CVSS 9.9 flaw that lets any authenticated Duo Agent Platform user run arbitrary commands on the AI Gateway server. Fixed releases are 19.2.4, 19.3.2 and 19.4.1 for self-hosted installs.
The Engineer · Build desk
What happened
- The flaw sits in the prompt template sandbox, the layer meant to isolate text a user sends to the model from the system's internal functions.
- Exploitation needs no administrator role and no memory bug; a valid account with access to the agent platform is enough.
- The post recommends updating immediately on any self-hosted deployment.
- The post's author says LLM-to-internal-systems connectors are usually deployed as one more utility inside the same network as everything else.
Why it matters
- exposure Every account with Duo Agent Platform access is a possible entry point to the Gateway host, so the exposed population is the user directory.
- constraint The post lists fixed versions only. A team on any other GitLab line cannot tell from this source whether it is affected.
- decision Patching closes this flaw. What the Gateway's service identity can reach, and whether tool calls are logged, decides the damage from the next one.
Command execution lands on the Gateway host [2]. That makes the host's service identity the first thing to look at. In our view, an attacker who escapes the sandbox inherits whatever that identity can reach.
The post puts the same check first. Confirm which identity the Gateway runs as and what it can reach, and if it can touch the internal network without restriction, that is the first thing to cut [7]. The second check is logging every tool call with its arguments and order, because without that trace a malicious execution gets lost in the noise [8]. Logging will not prevent an escape, but it gives a team a sequence to review afterwards.
The record here is a dev.to post, and it attributes the CVE and the 9.9 score to The Hacker News [4]. GitLab's own advisory text is not quoted. The three fixed versions sit on three separate minor lines, 19.2, 19.3 and 19.4 [10]. A team on any of those lines has a patch release to move to.
The author's remedy for the wider class is per-agent access control, strict versioning and network segmentation for any connector between an LLM and internal systems [11]. The author also proposes a test: run an AI Gateway on an isolated machine with no internet access, give it a prompt template with a known injection, and see whether the sandbox holds [9]. The test needs an injection that works on a vulnerable build, and the operator has to source one.
What to watch
- GitLab's own advisory, for the affected version range and the CVSS vector that produces 9.9.
- Any public proof-of-concept for CVE-2026-90970, which would shorten the patching window for self-hosted teams.
- Whether the Hacker News report the post cites adds detail on how the sandbox is escaped.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence45
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The flaw lives in the prompt template sandbox, the layer that should isolate the text a user sends to the model from the internal functions of the system.
- [2]
An authenticated user with access to Duo Agent Platform can escape the sandbox isolation and run arbitrary commands on the server where the AI Gateway runs.
- [3]
Exploiting the flaw does not require an administrator or a memory bug; a valid account with access to the agent platform is enough.
- [4]
The vulnerability is tracked as CVE-2026-90970 with a CVSS score of 9.9 and affects GitLab AI Gateway; the post attributes this to thehackernews.com.
- [5]
GitLab shipped patches in versions 19.2.4, 19.3.2 and 19.4.1.
- [6]
The post recommends updating immediately on any self-hosted deployment.
- [7]
The post advises checking which identity the AI Gateway runs as and what it can reach; if it can touch the internal network without restriction, that is the first cut.
- [8]
The post advises turning on logging of every tool call with its arguments and its order; without that trace, a malicious execution gets lost in the noise.
- [9]
The author would set up an AI Gateway on an isolated machine with no internet access and give it a prompt template with a known injection to see if the sandbox holds.
- [10]
The three fixed versions fall on three distinct minor lines: 19.2, 19.3 and 19.4.
- [11]
The author's reading is that LLM-to-internal-systems connectors should be treated as critical exposed services, with per-agent access control, strict versioning and network segmentation.
- [12]
According to the author, LLM-to-internal-systems connectors are deployed as one more utility inside the same network as everything else.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toGitLab AI Gateway sandbox escape leads to full RCE
1 article · October 15, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.