Self-Hosted GitLab AI Gateway: Trust Boundary After CVE-2026-90970

A CVSS 9.9 template-sandbox escape on the self-hosted AI Gateway. GitLab-hosted gateways are already fixed. Yours is a separate asset, with its own keys.

PoCForge research card: self-hosted GitLab AI Gateway CVE-2026-90970
A CVSS 9.9 template-sandbox escape on the self-hosted AI Gateway. GitLab-hosted gateways are already fixed. Yours is a separate asset, with its own keys.
Not a prompt-injection write-up. On 2 October 2026 GitLab patched CVE-2026-90970 in the self-hosted AI Gateway: an authenticated user with Duo Agent Platform access could escape the custom-flow prompt-template sandbox and run commands on the gateway. CVSS 3.1 is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), CWE-1336. GitLab-hosted gateways were already fixed. The customers who must move are the ones who self-host the gateway.

PoCForge (Cyber Security) already publishes methodology for agents as an attack surface and a prompt-injection lab. Those are about what the model is willing to do with a tool. CVE-2026-90970 is a different boundary: the template engine that wraps a custom flow, on the host that brokers prompts to a model. This note does not repeat jailbreak technique and does not reconstruct the flow configuration GitLab withheld.

1. What the 2 October advisory actually says

GitLab’s patch note, AI Gateway 19.2.4, 19.3.2 and 19.4.1, states that under certain conditions an authenticated user with Duo Agent Platform access could escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway. The CVE record matches that wording. Impacted AI Gateway versions: all from 18.1.6 before 19.2.4, 19.3 before 19.3.2, and 19.4 before 19.4.1. Fixed versions are 19.2.4, 19.3.2 and 19.4.1. GitLab says there is no fixed release below 19.2.4, so the 18.1.6 through 19.1 line is inside the affected range and has to jump forward.

GitLab.com, GitLab Dedicated, and self-managed instances that use a GitLab-hosted gateway do not need to act. A fix was already deployed on GitLab-hosted gateways. GitLab also says it contacted self-hosted gateway customers before the public post. The advisory, as published, does not list a workaround and does not publish indicators for activity that predates the patch.

Secondary reporting on 3 October 2026 (including coverage that cites a CISA ADP enrichment on the CVE record dated 2 October) described exploitation as not known at that snapshot, with no public proof of concept called out. ADP fields change. Re-read the live CVE record before you quote “not exploited” in a risk acceptance. Absence on a given day is not a finding that the gateway was untouched.

2. Trust boundary: who asks, what executes

A self-hosted AI Gateway exists so prompts and model responses stay in the customer’s environment. That is a confidentiality decision. CVE-2026-90970 shows the cost: the component that holds model credentials and sits next to the GitLab instance is now the thing that must be patched on its own calendar. The gateway is a separate image or chart. Matching “we are on GitLab 19.3.2” does not tell you the gateway tag.

Trust boundaryPoCForge / interactive
Trust boundarySelect the hop you are testing. This is the boundary the advisory names, not a prompt-injection recipe and not a reproduction.01 · CALLERDuo user02 · FLOWTemplate input03 · HOSTGateway04 · SECRETSKeys on that host
01 · Caller

A Duo Agent Platform user

A GitLab user who can use the Duo Agent Platform. Privileges required are low, not administrator. The advisory does not require anyone else to click anything.

02 · Custom flow

Template input, not model obedience

A flow configuration is user-influenced template input. The weakness class is CWE-1336, improper neutralisation in a template engine — not “the model obeyed a prompt”.

03 · Gateway host

Command execution on the AI Gateway

Escape leads to command execution on the AI Gateway. Scope is changed: confidentiality, integrity and availability of the gateway, and whatever that host can reach. The gateway image or chart is a separate asset from the GitLab application version.

04 · Secrets on that host

Name the keys, then rotate after upgrade

Model provider keys, GitLab tokens the gateway uses to call back, and any JWT signing material stored for that call path should be treated as in the blast radius if execution was possible. GitLab’s public note does not prescribe a key-rotation runbook. The test objective is still: can you name those secrets and rotate them?

Select the hop you are testing. This is the boundary the advisory names, not a prompt-injection recipe and not a reproduction.

JWT keys deserve their own line because gateways commonly authenticate back to the product with signed tokens. If the gateway process can be driven into command execution, any signing key or long-lived JWT on that filesystem or in that environment is a credential, not a configuration detail. Rotating them is an assume-breach control after an exposure window. It is not a claim that GitLab published a specific key-compromise indicator, and it is not a substitute for the version upgrade.

3. Version matrix

Gateway line in use Status Move to
18.1.6 through 19.1.x Affected; no patched build on that line 19.2.4 (confirm compatibility with the GitLab minor you run — the advisory does not promise a 19.1 app works unchanged with a 19.2.4 gateway)
19.2 before 19.2.4 Affected 19.2.4
19.3.0–19.3.1 Affected 19.3.2
19.4.0 Affected 19.4.1
GitLab-hosted gateway GitLab says already patched No gateway action; still know which mode you are in

Maintenance context from GitLab’s own lines: security fixes for this component were published on 19.2, 19.3 and 19.4. An estate stuck on 19.1 or earlier is not “one patch behind”. It is on a line the advisory does not repair in place.

Version linePoCForge / interactive
No in-place fix

Jump forward

Affected, and GitLab does not publish a patched build on that line. Move to 19.2.4 and confirm compatibility with the GitLab minor you run. The advisory does not promise a 19.1 application works unchanged with a 19.2.4 gateway.

Before 19.2.4

Move to 19.2.4

19.2 before 19.2.4 is affected. The fixed build on this line is 19.2.4.

19.3.0–19.3.1

Move to 19.3.2

19.3.0 and 19.3.1 are affected. The fixed build on this line is 19.3.2.

19.4.0

Move to 19.4.1

19.4.0 is affected. The fixed build on this line is 19.4.1.

Already covered

No gateway action

GitLab says GitLab.com, GitLab Dedicated, and self-managed instances that use a GitLab-hosted gateway were already fixed on GitLab’s side. Still record which mode you are in, so a later self-hosted move is not a surprise.

Match the gateway tag, not the GitLab application version. There is no patched build below 19.2.4.

4. Test objectives for a human-led review

Authorised objectives. None of these is “craft a flow and pop a shell”.

  1. Mode. Is AI served by a GitLab-hosted gateway or a self-hosted one? Write the image tag or chart version, not the GitLab application version, into the asset register.
  2. Population. Who has Duo Agent Platform access? Low privilege is enough. Contractors, trial groups and shared automation accounts count.
  3. Separation. Which network segment holds the gateway, which identities it uses towards the model provider, and which token it uses towards GitLab? Draw that before discussing CVSS.
  4. Logs. What is retained on the gateway, for how many days? The public advisory does not give a detection recipe. If you have no logs, say “cannot assess pre-patch abuse”, not “no abuse”.
  5. Keys. Inventory JWT signing material and bearer tokens on the gateway. If the unpatched build was reachable by anyone with Duo Agent Platform access, plan rotation after upgrade and record the gap.
  6. Change path. How fast can the image be replaced, independently of the GitLab upgrade window? A 9.9 on a host you can only change monthly is an operational finding even after this CVE is closed.
Defender checklistPoCForge / interactive

Self-hosted gateway, after 2 October 2026








0 checked

Ticks stay in this browser. They are not written back to the engagement file.

If the question is “can a prompt steer a tool”, use the agent lab note. If the question is “can a logged-in developer reach operating-system execution on the AI broker”, use this CVE. The October Loom bulletin is the cloud-control-plane cousin: Loom for AWS and SageMaker Spaces. A self-managed GitLab that is also late on CVE-2026-85706 has two patch debts, not one — the file-read issue is on the application, this one is on the gateway.

For an engagement, put the gateway in scope explicitly. “AI features enabled” on a statement of work is not the same as permission to review the self-hosted gateway’s version, secrets and logs.

Sources

Frequently asked questions

Do GitLab.com customers need to patch CVE-2026-90970?

GitLab says no. GitLab.com, GitLab Dedicated, and self-managed instances using a GitLab-hosted AI Gateway were covered by a fix GitLab deployed on its own gateways. Only self-hosted AI Gateway installations in the affected version ranges need to upgrade.

Is this prompt injection?

The weakness GitLab names is CWE-1336, special elements in a template engine, on custom flow prompt templates, leading to command execution on the gateway. That is a sandbox escape in the gateway’s template handling. It is not the same class of issue as a model following an injected instruction, even though both can show up in an “AI feature” review.

Should JWT keys be rotated?

If an unpatched self-hosted gateway was available to Duo Agent Platform users, treat secrets on that host — including JWT signing material and tokens used to call GitLab or a model provider — as potentially exposed and rotate them after the upgrade. GitLab’s public advisory does not publish a key-rotation procedure or indicators of compromise; rotation is an assume-breach control, not a vendor IoC match.

Is there a workaround?

The 2 October advisory does not provide one. Compensating ideas such as removing Duo Agent Platform access shrink who can reach the condition; they are not a fix. The versions GitLab names are 19.2.4, 19.3.2 and 19.4.1.