GitLab AI Gateway: critical 9.9 flaw hits self-hosted deployments

The facts: CVSS 9.9 on the service that talks to the models

CVE-2026-90970 carries a CVSS score of 9.9 out of 10 and affects GitLab's AI Gateway. The company disclosed it on 2 October 2026, with an advisory that classifies it as critical.

The gateway is the service that connects a GitLab instance to AI models. According to the advisory as reported by The Hacker News^[1], a user who is already authenticated and has access to the Duo Agent Platform can run commands on the gateway, under certain conditions.

There are three patched versions: 19.2.4, 19.3.2 and 19.4.1. GitLab has already updated the gateways it runs itself. The alert concerns anyone hosting the gateway inside their own infrastructure, and BleepingComputer^[2] covered it as a critical remote code execution vulnerability.

The company notified those customers directly, before publishing the public text. The recommendation is to update immediately.

Who has to act, and who is already covered

The list of those who can stay put is clear. GitLab.com, GitLab Dedicated and self-managed instances that use a GitLab-hosted gateway are already in the clear, per the company's own statement.

Exposure remains for anyone who chose the other route. GitLab gives self-managed customers the option to host the gateway in house, so that requests and responses to the models stay inside the corporate perimeter. That choice exists for data confidentiality reasons.

Here the ledger flips. Anyone who decided to keep AI data in house now also owns the vulnerable component, the patch cycle and the operational risk. The gateway ships as a Docker image or as a Helm chart, with an upgrade path separate from GitLab's own.

Two teams and two calendars converge on a single point of exposure.

What the attacker needed

The severity of a flaw also shows in the list of what is missing from the requirements. Here that list is short.

The attacker needs a valid account on the instance and access to the Duo Agent Platform. Certain conditions also have to be met, and the advisory deliberately keeps those generic.

Left off the list: administrator privileges, a third-party exploit chain and any action by the victim. A score of 9.9 on a surface reachable by an authenticated internal user describes exactly this: the jump from the application layer to the gateway's execution layer.

The precise technical mechanism stays confidential, and that call is the right one. What matters is the class of problem: a component built to broker prompts and responses opens a path to command execution. Anyone who has read the 2026 advisories on agentic frameworks will recognise the recurring theme.

The patched versions, and the gap below 19.2.4

The version table deserves a slow read, because it says more than the technical description does.

Anyone running a gateway from 18.1.6 onward, up to 19.2.4, has to move to 19.2.4. The 19.3 line closes with 19.3.2, the 19.4 line with 19.4.1. For a Docker deployment the procedure means stopping the container, removing it and pulling the new image, for example self-hosted-v19.4.1-ee. Helm wants the new tag in the chart's image setting.

Below 19.2.4 the table stops. Every release from 18.1.6 through the 19.1 line falls inside the affected range, and for those lines there is no patched version.

The installation guide asks for a gateway image matching the GitLab minor version. The advisory says nothing on a practical point: compatibility between a 19.2.4 gateway and GitLab 19.1 or earlier. As of 2 October the maintenance policy lists 19.4, 19.3 and 19.2 as the lines receiving security fixes, the same three that got the gateway patch.

The underlying condition: the chosen perimeter becomes the target

The boundary built to protect data becomes the boundary to defend. That holds for gateway self-hosting as it held for egress proxies and on-premise vaults.

The security posture of AI systems runs two or three years behind the maturity of the infrastructure hosting them: that remains one of this desk's positions, and the case reinforces it. An AI gateway is a privileged network component, with credentials to the models and visibility into prompts. It deserves bastion host treatment.

Current practice often puts it somewhere else, inside the platform team's backlog.

Agent identity enters here too, the control plane of 2026. A Duo Agent Platform reachable by an authenticated user inherits that user's trust and carries it onto a service that executes. The boundary between whoever asks and whatever executes has to be made explicit at the authorisation layer.

What the advisory leaves unsaid

Two silences weigh more than the technical description.

The first: there is no workaround for gateways still waiting to be updated. Anyone with long change management windows faces a stark choice between shutting the service down and accepting the risk.

The second: the advisory says nothing on how to verify abuse that happened before the patch. Zero indicators of compromise and zero pointers to logs worth checking. Zero signatures. An administrator who updates today closes the door and stays blind to the past.

On the exploitation front, the US agency CISA added an assessment to the CVE record on 2 October, and marks exploitation there as absent. The other two available values cover the presence of a public proof of concept and active exploitation. That snapshot holds for that date, and deserves a re-read at every update to the record.

Three questions for the corporate AI team

This component's patch cycle has to be detached from GitLab's, in the asset register as in the operational calendar. A separate Docker image is a separate asset, with an owner answerable for its state.

1. Which version is running on the AI gateway in production today, and who updates it?
2. Does the gateway fall in the 18.1.6-19.1 window, the one with no patched version?
3. Which gateway logs are retained, and for how many days?

Anyone answering all three with a precise version number closes the day. Anyone answering "depends on the team" has found the real finding, and it concerns internal governance before the patch.

The third question is the expensive one. With no logs retained, after-the-fact verification stays impossible, and the same gap will return with the next advisory on the same class of components.

Decisions for the next planning cycle

For the CTO this is a question of inventory, before it is one of security. The list of self-hosted AI components holding credentials to the models has to be made explicit, with an owner and a version next to every line.

For the head of engineering the lever is update time. A Docker image replaceable in an hour changes the risk profile of a 9.9 flaw; one replaceable in three weeks multiplies it.

For the CFO the line item is the technical debt of self-hosting. Keeping AI data in house carries a recurring maintenance cost, and that cost belongs in the budget next to the confidentiality benefit.

For the procurement committee the contractual point is notification. GitLab warned customers with self-hosted gateways ahead of publication: a commitment of that kind deserves to appear in the contract, with defined timing and a declared channel.

The falsifiable prediction is this: within twelve months at least one other self-hosted AI gateway from a major vendor will receive a critical advisory with the same shape, namely an authenticated user reaching execution. The architectural model makes it likely.