GitLab's AI Gateway has a second 9.9 in 235 days, and only self-hosted gateways must patch

A login is worth 0.1 of a point

GitLab has scored the new AI Gateway flaw 9.9 out of 10, not 10.0, and the entire difference is the login. Take GitLab's own vector, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, change the privileges required metric from low to none, and the CVSS 3.1 formulas return 10.0. The advisory says an authenticated user with Duo Agent Platform access could, "under certain conditions", escape a prompt template sandbox through a specially crafted flow configuration and run arbitrary commands on the gateway. The conditions are not described in anything GitLab has published.

That score does not establish that anyone has used the flaw. CISA's coordinator assessment, added to the CVE record at 16:47 UTC on 2 October, lists exploitation as "none", and CVE-2026-90970 was not in CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.02, 1,733 entries) when we checked at 11:32 BST on Saturday 3 October. It does not say how many gateways exist, how many a logged-in user can reach, or what the commands would run as. And it does not put every GitLab server at risk: GitLab says only organisations that host their own gateway need to act.

This briefing reads GitLab's advisory, the CVE record and the NVD entry in full, then GitLab's own documentation for what the advisory leaves out. It stays at defender level: what to patch, how to find your version, and who can reach the thing. No exploit steps are published in the sources we read, and none appear here. It is written for UK teams that self-host GitLab with Duo.

What GitLab, the CVE record and CISA each say

The CVE record was published at 14:34 UTC on 2 October, which is 15:34 BST, and the NVD entry followed at 15:17 UTC. GitLab's patch release feed dates the advisory 2 October, a Friday. The CVE ID had been reserved on 14 September, 18 days earlier. A reservation is not a discovery date, but it suggests GitLab had the report by then. That is our inference, not GitLab's statement. The advisory gives no date for the fix, none for the fix to the hosted gateways, and none for the "targeted outreach" to self-hosted customers that it says came before the post. So the days between fix and advisory cannot be computed from anything published. The interval we can compute is the one that matters to you: one day since the advisory, as at Saturday morning.

Stated and not stated, from GitLab's advisory of 2 October 2026, the CVE record and NVD entry, and CISA's entry in the record, all read on 3 October

1. Point

   The flaw

   Stated

   An authenticated user with Duo Agent Platform access could, under certain conditions, escape the prompt template sandbox with a crafted flow configuration and run arbitrary commands on the gateway.

   Not stated

   The conditions. The template engine. The role the user needs.

2. Point

   Severity

   Stated

   CVSS 9.9, assigned by GitLab as the CNA. CWE-1336, template engine neutralisation. CISA: exploitation none, automatable no, technical impact total.

   Not stated

   An NVD score: the entry reads Awaiting Analysis. What lies beyond the gateway that a command could reach.

3. Point

   Affected versions

   Stated

   AI Gateway 18.1.6 up to, not including, 19.2.4; 19.3 before 19.3.2; 19.4 before 19.4.1.

   Not stated

   Whether older lines will be fixed. Whether anything before 18.1.6 was assessed.

4. Point

   Who must act

   Stated

   Self-hosted gateways. GitLab.com, Dedicated and self-managed instances on the GitLab-hosted gateway need no action.

   Not stated

   When the hosted gateways were fixed. Whether they were abused first. Whether Dedicated for Government is covered.

5. Point

   Exploitation

   Stated

   CISA's assessment on 2 October: none. Not in the KEV catalogue.

   Not stated

   Anything from GitLab. A way to tell whether a gateway was attacked.

6. Point

   Reporter

   Stated

   invisiblemeerkat, through HackerOne, thanked for responsible disclosure.

   Not stated

   When it was reported.

7. Point

   Workaround

   Stated

   None listed. The fix is an update.

   Not stated

   Whether any setting limits the exposure.

8. Point

   Exposure

   Stated

   No count, scan or telemetry appears in any source.

   Not stated

   How many gateways exist or face a network. What the commands run as. Whether code, prompts or keys are reachable.

Point	Stated	Not stated
The flaw	An authenticated user with Duo Agent Platform access could, under certain conditions, escape the prompt template sandbox with a crafted flow configuration and run arbitrary commands on the gateway.	The conditions. The template engine. The role the user needs.
Severity	CVSS 9.9, assigned by GitLab as the CNA. CWE-1336, template engine neutralisation. CISA: exploitation none, automatable no, technical impact total.	An NVD score: the entry reads Awaiting Analysis. What lies beyond the gateway that a command could reach.
Affected versions	AI Gateway 18.1.6 up to, not including, 19.2.4; 19.3 before 19.3.2; 19.4 before 19.4.1.	Whether older lines will be fixed. Whether anything before 18.1.6 was assessed.
Who must act	Self-hosted gateways. GitLab.com, Dedicated and self-managed instances on the GitLab-hosted gateway need no action.	When the hosted gateways were fixed. Whether they were abused first. Whether Dedicated for Government is covered.
Exploitation	CISA's assessment on 2 October: none. Not in the KEV catalogue.	Anything from GitLab. A way to tell whether a gateway was attacked.
Reporter	invisiblemeerkat, through HackerOne, thanked for responsible disclosure.	When it was reported.
Workaround	None listed. The fix is an update.	Whether any setting limits the exposure.
Exposure	No count, scan or telemetry appears in any source.	How many gateways exist or face a network. What the commands run as. Whether code, prompts or keys are reachable.

Attribution matters here. The 9.9 and the vector are GitLab's: the CVE record and the NVD entry both credit them to cve@gitlab.com, GitLab acting as the CVE Numbering Authority. NVD has not scored it itself. The only other party in the record is CISA's ADP entry, which carries an SSVC assessment and no CVSS score. All of this is a snapshot of 2 and 3 October. NVD can analyse the entry, and CISA can change its own, at any time.

What the 9.9 is made of

Three metrics in GitLab's vector decide the headline. Privileges required is low, which the CVSS specification defines as basic user capabilities. Scope is changed, which it defines as a flaw that can affect resources beyond the security scope of the vulnerable component. Confidentiality, integrity and availability impact are all high. We ran the CVSS 3.1 formulas four ways.

GitLab's vector with two metrics varied, computed by us from the formulas in the CVSS 3.1 specification. Only the first row is a published score

1. Variant of the vector

   As published by GitLab

   Privileges required

   Low

   Scope

   Changed

   Score

   9.9

2. Variant of the vector

   Login not required

   Privileges required

   None

   Scope

   Changed

   Score

   10.0

3. Variant of the vector

   Scope unchanged

   Privileges required

   Low

   Scope

   Unchanged

   Score

   8.8

4. Variant of the vector

   Both changed

   Privileges required

   None

   Scope

   Unchanged

   Score

   9.8

Variant of the vector	Privileges required	Scope	Score
As published by GitLab	Low	Changed	9.9
Login not required	None	Changed	10.0
Scope unchanged	Low	Unchanged	8.8
Both changed	None	Unchanged	9.8

Read it two ways. First, the login is cheap in score terms: removing it moves 9.9 to 10.0. Second, the scope call is the larger adjustment: without it the same flaw scores 8.8, which is 1.1 lower. A changed scope is GitLab's judgement that a command on the gateway can affect something beyond the gateway. The advisory does not say what. Neither row tells you how easy the login is to obtain. That is a fact about your accounts, not about CVSS.

Who needs to act, and on which versions

GitLab says a fix "has already been deployed" for gateways it hosts, and that customers on GitLab.com, GitLab Dedicated and self-managed instances using a GitLab-hosted gateway do not need to act. The case that needs care is self-managed. GitLab's documentation lists the cloud-based gateway as the default, and a self-hosted gateway as the option for customers who want request and response data to stay in their own environment. Self-hosted models are listed for Premium and Ultimate. In GitLab's hybrid configuration some features go to the hosted gateway and the rest to yours, which means your own gateway is still running, still called by your instance and still on whatever version you last installed.

Gateway versions from GitLab's advisory and the CVE record. These are AI Gateway versions, not GitLab instance versions

1. Gateway version in use

   Before 18.1.6

   In the advisory

   Not listed. Not stated whether that means unaffected or not assessed

   First fixed version

   Not stated

2. Gateway version in use

   18.1.6 up to 19.2.3

   In the advisory

   Affected

   First fixed version

   19.2.4

3. Gateway version in use

   19.3.0 and 19.3.1

   In the advisory

   Affected

   First fixed version

   19.3.2

4. Gateway version in use

   19.4.0

   In the advisory

   Affected

   First fixed version

   19.4.1

5. Gateway version in use

   19.2.4 or later, 19.3.2 or later, 19.4.1 or later

   In the advisory

   Fixed

   First fixed version

   None needed

Gateway version in use	In the advisory	First fixed version
Before 18.1.6	Not listed. Not stated whether that means unaffected or not assessed	Not stated
18.1.6 up to 19.2.3	Affected	19.2.4
19.3.0 and 19.3.1	Affected	19.3.2
19.4.0	Affected	19.4.1
19.2.4 or later, 19.3.2 or later, 19.4.1 or later	Fixed	None needed

The gap below 19.2 is the practical problem. Nothing is listed as fixed before 19.2.4, so a gateway on any 18.x, 19.0 or 19.1 release has no patch in its own line. GitLab's install guide says to run the gateway image whose tag matches your GitLab minor version, and the advisory does not say whether a 19.2.4 gateway works against an older instance. GitLab's maintenance page, as read on 3 October, lists 19.4, 19.3 and 19.2 as the maintained versions. On the face of it, then, an instance on 19.1 or earlier must upgrade to reach a patched gateway. That is our reading of the guide, not a statement from GitLab.

There is a precedent for asking for more. On 23 September GitLab backported the fixes for the critical path traversal CVE-2026-85706 to 19.0.9 and 18.11.12 "outside of our standard maintenance policy" so that administrators could skip an upgrade. Nothing similar is announced for the gateway.

The fixed numbers already mean something else

GitLab numbers its gateway releases to match its instance releases, but the patch numbers run separately. The install guide's own example has an instance on 18.2.1 and gateway images up to 18.2.2. That makes the fixed gateway versions easy to misread, because each one is also the number of a GitLab release that shipped earlier, and each of those was a critical patch release for the instance.

Dates from GitLab's patch release feed. Days computed by us, from the feed date to the gateway advisory on 2 October 2026

1. Fixed gateway version

   19.2.4

   Earlier GitLab release with that number

   17 August 2026, a critical patch release

   Days before the advisory

   46

2. Fixed gateway version

   19.3.2

   Earlier GitLab release with that number

   10 September 2026, a critical patch release that fixed a flaw CISA lists as exploited

   Days before the advisory

   22

3. Fixed gateway version

   19.4.1

   Earlier GitLab release with that number

   23 September 2026, a critical patch release

   Days before the advisory

   9

Fixed gateway version	Earlier GitLab release with that number	Days before the advisory
19.2.4	17 August 2026, a critical patch release	46
19.3.2	10 September 2026, a critical patch release that fixed a flaw CISA lists as exploited	22
19.4.1	23 September 2026, a critical patch release	9

So 19.3.2 on a ticket can mean the instance was patched for an exploited flaw on 10 September, or that the gateway was patched for this one on 2 October. They are different installs. An instance on 19.2.7 has a higher number than the fixed gateway 19.2.4 and tells you nothing about the gateway beside it. The only record that counts is the gateway's own image tag, which GitLab's docs give in the form self-hosted-vX.Y.Z-ee. An image started from a floating tag, or pinned by digest, hides it, and GitLab's docs say to use stable releases with an explicit version tag.

What "AI Gateway" actually names

The name does the first piece of misdirection. A gateway sounds like a pipe: requests go in, requests come out. GitLab's install guide describes something else, "a combination of two services": an AI Gateway service and a GitLab Duo Agent Platform service. They listen on HTTP port 5052 and gRPC port 50052, each has its own pair of signing keys, and the guide says the keys must be "treated as sensitive credentials". The gateway reaches your GitLab instance and your model providers, and the guide asks you to restrict its outbound traffic to those and to GitLab's licence server. That is a server that interprets configuration written by users.

The advisory's second friendly word is sandbox. A sandbox is a control, and the advisory describes its failure: a crafted flow configuration escapes the prompt template sandbox. The weakness class, CWE-1336, is improper neutralisation of special elements in a template engine. GitLab does not name the engine, and a prompt template sounds like text rather than something that can end in a command. February's flaw was the same class in the same component, as the next section shows.

The third friendly phrase is logged-in user. The advisory names no role, so the bar is whatever "Duo Agent Platform access" means on your instance. GitLab's documentation, read on 3 October, says this.

What GitLab's documentation says about access to the Agent Platform and custom flows, set against what the advisory says

1. Question

   Which accounts get the Agent Platform

   What GitLab's docs say

   It is on by default. The prerequisites list Duo turned on, plus Duo Pro or Enterprise, or Duo Core turned on for the instance or top-level group. Duo Core is included with Premium and Ultimate and is turned on automatically for new customers from 18.0.

   What the advisory says

   Only "Duo Agent Platform access".

2. Question

   Which tiers

   What GitLab's docs say

   Custom flows are listed for Free, Premium and Ultimate, with credits needed on Free. Self-hosted models are listed for Premium and Ultimate.

   What the advisory says

   Nothing.

3. Question

   Who can create a custom flow

   What GitLab's docs say

   Maintainer or Owner on the managing project.

   What the advisory says

   Not stated whether the exploit needs this step.

4. Question

   Who can run one

   What GitLab's docs say

   Developer, Maintainer or Owner, with the flow enabled in the project.

   What the advisory says

   Not stated.

5. Question

   Can an administrator switch it off

   What GitLab's docs say

   Yes: the Agent Platform can be turned off for the instance, and custom flows separately. Custom flows are on by default.

   What the advisory says

   Does not say either setting prevents this flaw.

Question	What GitLab's docs say	What the advisory says
Which accounts get the Agent Platform	It is on by default. The prerequisites list Duo turned on, plus Duo Pro or Enterprise, or Duo Core turned on for the instance or top-level group. Duo Core is included with Premium and Ultimate and is turned on automatically for new customers from 18.0.	Only "Duo Agent Platform access".
Which tiers	Custom flows are listed for Free, Premium and Ultimate, with credits needed on Free. Self-hosted models are listed for Premium and Ultimate.	Nothing.
Who can create a custom flow	Maintainer or Owner on the managing project.	Not stated whether the exploit needs this step.
Who can run one	Developer, Maintainer or Owner, with the flow enabled in the project.	Not stated.
Can an administrator switch it off	Yes: the Agent Platform can be turned off for the instance, and custom flows separately. Custom flows are on by default.	Does not say either setting prevents this flaw.

Two readings follow, and both are inference. If the exploit needs the flow-authoring step, the population is everyone holding Maintainer or Owner on any project where custom flows are on: count it on your instance rather than assume it is small. If it needs less, the population is wider. The advisory supports nothing more specific than "an authenticated user". What the documentation does show is that Duo access is governed by instance, group and project settings, and is on by default in places, rather than being a short named list.

GitLab's identity controls do not obviously help here. Composite identity, which GitLab documents as ensuring a flow "can never access more than the user who runs the flow", scopes what a flow can do through GitLab's API. The advisory describes commands on the gateway itself. The docs also say the flow's OAuth token is passed to the gateway to run the flow. Nothing in the sources says whether a process on the gateway can read it, or what the commands run as. Treat that as unknown, not as reassurance.

The second 9.9 in 235 days

As far as GitLab's feed and the CVE records show, this is the second 9.9 in this component. CVE-2026-1868, published on 9 February, carried the same score and the same vector, was filed under the same weakness class, CWE-1336, and concerned crafted flow definitions reaching template expansion in the gateway's Duo Workflow Service. The two CVE records are 235 days apart, 9 February to 2 October. GitLab's patch release feed, which goes back to May 2023, has two standalone AI Gateway patch releases, 6 February and 2 October, both critical.

From GitLab's two AI Gateway advisories as carried in its patch release feed, and the two CVE records

1. Detail

   CVE record published

   February: CVE-2026-1868

   9 February 2026

   October: CVE-2026-90970

   2 October 2026

2. Detail

   Score and weakness

   February: CVE-2026-1868

   9.9, same vector, CWE-1336

   October: CVE-2026-90970

   9.9, same vector, CWE-1336

3. Detail

   Fixed in gateway

   February: CVE-2026-1868

   18.6.2, 18.7.1, 18.8.1

   October: CVE-2026-90970

   19.2.4, 19.3.2, 19.4.1

4. Detail

   Found by

   February: CVE-2026-1868

   A GitLab team member, internally

   October: CVE-2026-90970

   invisiblemeerkat, through HackerOne

5. Detail

   What it could do

   February: CVE-2026-1868

   Denial of service or code execution on the gateway

   October: CVE-2026-90970

   Arbitrary command execution on the gateway

6. Detail

   Access needed, as worded

   February: CVE-2026-1868

   "Authenticated access to the GitLab instance is required"

   October: CVE-2026-90970

   An authenticated user with Duo Agent Platform access, under certain conditions

7. Detail

   Notice before the post

   February: CVE-2026-1868

   Not mentioned

   October: CVE-2026-90970

   Targeted outreach to self-hosted customers

Detail	February: CVE-2026-1868	October: CVE-2026-90970
CVE record published	9 February 2026	2 October 2026
Score and weakness	9.9, same vector, CWE-1336	9.9, same vector, CWE-1336
Fixed in gateway	18.6.2, 18.7.1, 18.8.1	19.2.4, 19.3.2, 19.4.1
Found by	A GitLab team member, internally	invisiblemeerkat, through HackerOne
What it could do	Denial of service or code execution on the gateway	Arbitrary command execution on the gateway
Access needed, as worded	"Authenticated access to the GitLab instance is required"	An authenticated user with Duo Agent Platform access, under certain conditions
Notice before the post	Not mentioned	Targeted outreach to self-hosted customers

What this does not establish: it does not say the October flaw is a bypass of the February fix, or a regression. GitLab does not say so, and the October advisory does not mention February. Two CVEs in one class can have different roots. What the shared record does show is a component whose job is to render user-written configuration, hit twice by the class of bug CWE-1336 describes. GitLab's own feed lists 15 CVE headings that name Duo or the AI Gateway among 218 for 2026 up to 2 October. That count is ours, by title keyword, and it measures headlines in a feed, not the rate of flaws.

On method, not accusation: GitLab found the February flaw itself, patched its hosted gateways before announcing both flaws, and in October contacted self-hosted customers before the post. It also sells Duo, and its documentation presents the self-hosted gateway as the way to keep request and response data in your own environment. The same documentation says what that costs: "You set up your infrastructure, and do your own maintenance." Self-hosting buys data control and passes the patching duty to you. Neither party's interest changes the version numbers above.

The UK clock, if the gateway is in scope

Nothing in the sources is specific to the UK, and we found no UK body that has published on this flaw. The UK relevance is a rule many UK organisations already carry. NCSC's Cyber Essentials requirements, version 3.3 of April 2026, say software in scope must be updated within 14 days of release where the update fixes vulnerabilities the vendor calls critical or high risk, or that score 7 or above on CVSS v3. GitLab calls this one critical and scores it 9.9. Counting from the advisory date of 2 October, 14 days ends on Friday 16 October 2026. IASME, which runs the scheme, says two questions on timely installation of high-risk or critical updates are automatic-fail questions for assessment accounts created after 26 April 2026, one of them covering applications.

Whether a self-hosted gateway sits inside your Cyber Essentials scope is a scoping decision, and no source decides it. The advisory carries only a date, so 16 October is our reading of the clock, not an assessor's.

What to do, in order

Ordered for a UK organisation that self-hosts GitLab with Duo. Steps one to four establish what you run and fix it. Step five covers lines that have no fix. Steps six to eight limit exposure and check. Step nine records it. The commands below are our own convenience, not GitLab's. If you run GitLab, our earlier briefing on the issue by email token is a separate matter and unrelated to this flaw.

docker ps --no-trunc | grep -i model-gateway
kubectl get deployments --all-namespaces -o wide | grep -i gateway

The question this leaves

GitLab has told you who the flaw needs: a logged-in user with Duo Agent Platform access, under conditions it has not described. It has told you which builds fix it. It has not told you whether anyone used it, what the commands would have run as, or how long a gateway sat reachable before 2 October.

Which of your accounts count as Duo Agent Platform access, and how long would it take you to produce that list?