Table of Contents
Key Takeaway
- GitLab patched CVE-2026-90970, a CVSS 9.9 command-execution flaw in the AI Gateway that serves GitLab Duo’s AI features — fixed in gateway releases 19.2.4, 19.3.2, and 19.4.1, all published October 2.
- Only teams that SELF-HOST the AI Gateway need to act. GitLab.com, GitLab Dedicated, and self-managed instances using GitLab’s hosted gateway are already protected.
- An attacker needs only a low-privileged account with Duo Agent Platform access — no admin role, no user interaction — and gains arbitrary command execution on the gateway server.
- Gateways running anything below 19.2.4 — including the entire 18.x line from 18.1.6 up — have no fixed release in their own lane, so patching may require a GitLab upgrade too.
- Filipino impact: at least 153 Philippine companies run GitLab, and DevSecOps resellers push self-hosted AI setups to enterprises; a vulnerable self-hosted gateway turns every agent-flow user into a potential root of your CI/CD host.
The security world spent the last week learning what an AI agent can do when it escapes its sandbox. On October 2, GitLab disclosed that its own AI plumbing just needed a patch. The company fixed a critical vulnerability in the GitLab AI Gateway — the service that connects a GitLab instance to AI models — that could have allowed an authenticated user to escape the prompt template sandbox and run arbitrary commands on the gateway itself. Not on the model. Not in a chat window. On the server that holds the credentials for every AI model your developers use.
From today, every GitLab AI Gateway review conversation starts with one question: which version are you on?
This is the first 9.9-severity AI-infrastructure flaw disclosed by a major dev platform vendor during the rogue-agent era, it sits inside the GitLab AI Gateway, and it lands in the same week CISA rated its exploitation “none.” That combination — a critical server-side flaw in AI plumbing with zero reported exploitation — is a gift of a window. It will not stay open.
The Flaw in Verified Numbers
The GitLab AI Gateway flaw is now cataloged as CVE-2026-90970. Per the NVD record for CVE-2026-90970, published October 2, 2026, and GitLab’s advisory: the flaw affects “all versions of the AI Gateway from 18.1.6 before 19.2.4, 19.3 before 19.3.2, and 19.4 before 19.4.1” and, “under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, resulting in arbitrary command execution on the AI Gateway.”
The CVSS 3.1 vector on the GitLab AI Gateway flaw is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — network-reachable, low attack complexity, low privileges, no user interaction, scope changed, total impact across confidentiality, integrity, and availability. GitLab is the CNA. The weakness is CWE-1336: improper neutralization of special elements used in a template engine. In plain language, input the system was supposed to treat as data got treated as template syntax — server-side template injection, escaped.
Three details define who should actually worry:
- The entry point is a custom flow. The Duo Agent Platform sits inside the GitLab AI Gateway and lets users build agent workflows. A crafted flow configuration is the vehicle — meaning the attack surface is any user who can create or edit one.
- The privilege bar is low on the GitLab AI Gateway. An ordinary account with Duo Agent Platform access, not an administrator. On a busy engineering org, that is hundreds of people, including contractors.
- Scope changed (S:C in the vector). GitLab’s scoring says impact reaches beyond the gateway component. GitLab has not published what that covers, but the gateway’s own credentials for model endpoints and its network position between your GitLab instance and model hosts are the obvious inference — analyst Alex Kim’s team at Threat Frontier reads it the same way, and they flag it explicitly as their inference, not GitLab’s statement.
GitLab disclosed this alongside a dedicated patch release for the gateway itself, separate from the GitLab CE/EE 19.4.1, 19.3.3, and 19.2.7 application patch that shipped September 23. The version numbers overlap; the fixes do not. A self-managed instance with a self-hosted gateway may need both.
The third-party pattern repeats: Bitget’s $387.5M theft came through a security vendor’s zero-day (our autopsy of the money lane), and DIVD’s breach ran through Zammad self-hosted (the disclosure fight, the kill chain file). GitLab credited the discovery to invisiblemeerkat, a HackerOne researcher. The internal work item — 628842 — is private, and GitLab’s policy is to make security issues public on its tracker 90 days after release. CISA’s enrichment on the CVE record lists exploitation as “none,” automatable as “no,” and technical impact as “total,” added October 2. The flaw is not in CISA’s Known Exploited Vulnerabilities catalog as of that date.
Why Self-Hosters Are the Only Ones in the Blast Radius
Which deployments are exposed splits on one line: the GitLab AI Gateway is “a combination of two services that give access to AI-native GitLab Duo features”: the AI Gateway service and the GitLab Duo Agent Platform service. GitLab runs gateways for its hosted customers and has already fixed those. The blast radius is the self-hosted deployment — teams that run the gateway container alongside their own GitLab instance and model endpoints, usually to keep AI request and response data inside their own environment.
That data-sovereignty instinct is exactly why so many regulated shops self-host the GitLab AI Gateway. Philippine enterprises in banking, BPO, and government contracting often cannot send source code and AI traffic offshore at all, so the self-hosted gateway is the compliance-friendly choice. The GitLab AI Gateway flaw is the compliance-friendly choice attacking back: the container with the model credentials, code-suggestion payloads, and agent flows inside your perimeter is the one exposing a 9.9 command-execution path to the account next door.
“GitLab strongly recommends that those customers update immediately,” the company said, and it sent that guidance to self-hosted-gateway customers directly before publishing the advisory — a 1:1 heads-up before public disclosure. If your team runs a self-hosted GitLab with Duo enabled and nobody noticed October 2’s advisory, that silence is your exposure window.
What It Changes for Filipino Teams and Businesses
The GitLab AI Gateway vulnerability matters locally because GitLab’s pull in the Philippine market is real. DevSecOps integrator IT Group has pitched GitLab-based pipelines to Philippine enterprises as a unified platform, and public trackers list at least 153 Philippine companies using GitLab across industries — enough that BPO-adjacent dev shops, fintech teams, and LGU IT units will recognize their own stack in this advisory. Most of those deployments are self-managed; the AI Gateway self-hosting option is the natural next step as GitLab Duo adoption grows locally. Each step toward self-hosting AI is a step toward owning this GitLab AI Gateway CVE.
The budget line is unforgiving because CI/CD hosts sit on the crown-jewel path. A gateway compromise does not just expose model endpoints: source tokens, deployment keys, package registry credentials, and the runner network all live adjacent. A full GitLab environment rebuild and credential-rotation incident on a 10-person dev team runs into six figures in pesos once you count the downtime of every pipeline that feeds every repo (compare the containment arithmetic in our Bitget third-party breach piece, where credential-theft tooling was the pivot of a $387.5M loss). For a BPO whose contracts carry client SLAs, the larger number is the client-credential rotation conversation, not the hours.
There is also a hiring-and-skills line. The attacker needs no exploit-development skill at all — the entry point is a crafted flow configuration, which is configuration, not code. Every dev who can click the agent-flow builder is inside the perimeter. This is one more proof of the pattern we have tracked all month: AI infrastructure security failures do not require AI-genius attackers, they require ordinary accounts next to powerful plumbing.
The Patch Math — and the Gap GitLab Has Not Addressed
The GitLab AI Gateway fix table is easy to read:
- Gateway 18.1.6 to 19.2.3 → fixed in 19.2.4
- Gateway 19.3.0–19.3.1 → fixed in 19.3.2
- Gateway 19.4.0 → fixed in 19.4.1
Docker deployments of the GitLab AI Gateway stop and remove the running container, then pull and run the new image tag such as self-hosted-v19.4.1-ee with the same environment variables. Helm deployments set the new tag in the chart’s image setting. But GitLab’s own guide warns that Helm charts before 0.7.0, and Kubernetes by default, pull with an IfNotPresent policy that can silently miss a security patch published under an existing tag — so pin the image by digest and verify the digest of the running container after the upgrade.
Then there is the gap that will catch the sleepy ones: no fixed GitLab AI Gateway version exists below 19.2.4. Every gateway release from 18.1.6 through the whole 19.0 and 19.1 lines is stranded in the affected range.
Because the install guide pairs the gateway tag with the GitLab minor version, getting a fixed gateway may mean upgrading GitLab itself to 19.2 or later. The advisory does not address that case, and Threat Frontier’s remediation walkthrough — the most complete public one — directs such teams to check with GitLab support before running a mismatched gateway version. If your gateway is on 18.x today, your patch is not a container swap; it is a project plan.
GitLab has published no workaround. Threat Frontier’s mitigation suggestion, explicitly labeled theirs: because the attacker needs Duo Agent Platform access, cut that access down to the users you would trust with code execution on the gateway host — which is the right sentence to say out loud, because after this CVE that is literally what the role grants.
Detection Before the Patch — and What a Hit Looks Like
GitLab has published no indicators of compromise for the GitLab AI Gateway flaw. Until you patch, the practical triage is what Threat Frontier lists plus our own additions for a PH ops team:
- Find out whether you even run a self-hosted GitLab AI Gateway: the container image lives under gitlab-org/modelops/applied-ml/code-suggestions/ai-assist, with the HTTP service on port 5052 and the Duo Workflow gRPC service on port 50052.
- Look for unexpected child processes or shell activity inside the gateway container — the one process signature that should never be there.
- Look for unexpected outbound connections from the container: the gateway talks to model endpoints by design, and nowhere else.
- Review recently created or changed custom flows — the crafted flow configuration is the entry vehicle, and it may still be sitting in the UI.
- If anything looks off, rotate every credential the gateway holds for model endpoints first, and assume code-suggestion payloads flowing through the gateway could have been observed.
For teams using Wazuh or any EDR with Docker support, a shell spawn inside a container image that ships exactly two services is a low-noise alert to stand up tonight; the volume of true-positive child-process events from an AI Gateway container in normal operation is near zero.
The Bigger Pattern: AI Infrastructure Is the New Edge
Pull the camera back one week and the pattern is hard to miss. DIVD got breached through two Zammad zero-days by an autonomous AI agent. Bitget lost $387.5 million through a third-party security vendor’s zero-day. GitLab just patched a 9.9 in the AI infrastructure layer. Splunk, Okta, and Cloudflare disclosures used to be the “edge” that every incident-response plan started from; in this quarter of 2026, the AI plumbing — gateways, agent platforms, ticketing systems wired to agents — is where the kill chain lands first.
And the exploitation timeline is compressing. The DIVD agent moved autonomously. Bitget’s attacker had high-level internal credentials within a wallet-ops pipeline. A CVSS 9.9 with PR:L, UI:N, and S:C scoring is about as close to a public invitation as a flaw gets — the only reason CISA lists exploitation as “none” is that the fix shipped fast. Gateways that stay on 18.x will not have that luck forever: exploit chains for template-sandbox escapes are exactly what the autonomous-agent era automates first, as Unit 42 documented in July when an actor’s agent hunted critical CVEs across ten product families on its own.
What to Watch Next
- 90 days from October 2: GitLab’s policy publishes security work items on its tracker after 90 days — the full technical mechanics of CVE-2026-90970 go public around the end of December 2026. Watch for weaponization within weeks after that.
- CISA KEV: any addition of CVE-2026-90970 to the Known Exploited Vulnerabilities catalog; the current status is clean, and that is your deadline marker.
- 18.x answers: whether GitLab ships gateway fixes for the 18.1.6–19.1.x range or documents a supported mismatch; watch the 19.x patch release notes channel.
- Duo Agent Platform default grants: whether GitLab tightens who can edit agent flows by default — the low-privilege requirement is what makes this a 9.9.
For Your Own Checklist Right Now
Tonight, three commands: docker ps | grep ai-gateway (are you even exposed?), a check of your gateway version against the fix table, and a review of who holds Duo Agent Platform access. If the gateway is self-hosted and below 19.2.4, the upgrade is tonight’s job — not this quarter’s roadmap item. If you are on 18.x, open the GitLab support conversation in parallel with planning the GitLab upgrade, because those two tracks are now coupled.
And for everyone on GitLab.com or Dedicated, or self-managed with a GitLab-hosted AI Gateway: you are covered. Log in Monday and check the Duo features still work, then go back to worrying about the things that are your problem — like the 543,000 valid credentials currently sitting in public GitHub repositories.
FAQ
Do I need to patch if I only use GitLab.com?
No. GitLab runs the AI Gateway for GitLab.com, GitLab Dedicated, and customers using its hosted gateway, and says it has already fixed those deployments. Only self-hosted gateways are affected by CVE-2026-90970.
What versions fix the GitLab AI Gateway flaw?
AI Gateway releases 19.2.4, 19.3.2, and 19.4.1, published October 2, 2026. There is no fixed release below 19.2.4, so gateways running 18.1.6 through 19.1.x must move to a newer line, which may require upgrading GitLab itself to 19.2 or later.
Is CVE-2026-90970 being exploited in the wild?
CISA’s CVE-record enrichment lists exploitation as “none” as of October 2, 2026, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalog. GitLab’s advisory does not mention any exploitation. History says treat “not yet” as a countdown, not a verdict.
What does the GitLab AI Gateway actually do?
The GitLab AI Gateway is the pair of services behind GitLab’s AI features: the AI Gateway service handles model requests for code suggestions and Duo features, and the GitLab Duo Agent Platform service lets users build and run agent workflows. It holds credentials for model endpoints, which is why command execution on it is scored with scope-changed impact.
Could this have been a prompt-injection attack on the model?
No. GitLab’s description and the CWE-1336 classification identify server-side template injection in the custom-flow prompt-template system: the crafted flow configuration escapes the prompt template sandbox and executes on the gateway host. The model’s outputs are not part of the described attack path.
