GitLab AI Gateway Flaw Allows Command Execution
GitLab patched a critical flaw in its AI Gateway, a service connecting GitLab instances to AI models. The vulnerability allowed a logged-in user with Duo Agent Platform access to execute commands on self-hosted gateways. This flaw, fixed in gateway versions 19.2.4, 19.3.2, and 19.4.1, exposed organizations hosting their own AI infrastructure to unauthorized control. The extent of exploitation before the patch is unknown.
Severity: Critical · Category: Supply Chain
Impact: Unauthorized command execution on self-hosted AI gateway servers.
Source: The Hacker News · Oct 02 2026 · Original source
What Happened
A critical flaw was identified in GitLab's AI Gateway, a service responsible for connecting a GitLab instance to AI models. This vulnerability, tracked as CVE-2026-90970, could allow a logged-in user with Duo Agent Platform access to execute arbitrary commands on the gateway under certain unspecified conditions. The flaw is a template engine weakness, categorized as CWE-1336, and specifically affects the prompt template of a custom flow. Custom flows are AI-powered workflows created by users on the Duo Agent Platform to automate multi-step tasks. Exploitation involved escaping the prompt template sandbox via a specially crafted flow configuration, leading to command execution on the gateway. GitLab disclosed the flaw on October 2 and credited HackerOne user invisiblemeerkat with its report.
Timeline
- February — GitLab fixed another gateway flaw, CVE-2026-1868, also rated 9.9 and a template engine weakness.
- October 2, 2026 — GitLab disclosed the critical flaw (CVE-2026-90970) in its AI Gateway.
- October 2, 2026 — The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added an assessment to the CVE record, listing exploitation as "none".
Technical Analysis
The vulnerability, identified as CVE-2026-90970, was rated critical by GitLab with a CVSS score of 9.9 out of 10. It is classified as a template engine weakness, specifically CWE-1336, and resides within the prompt template of a custom flow on the Duo Agent Platform. A logged-in user with Duo Agent Platform access could exploit this by crafting a flow configuration designed to escape the prompt template sandbox, thereby achieving arbitrary command execution on the gateway. The advisory did not specify the exact conditions or user role required beyond general Duo Agent Platform access. This flaw shares the same class of template engine weakness (CWE-1336) as a previous gateway vulnerability, CVE-2026-1868, which GitLab fixed in February and also rated 9.9 for potential denial of service or code execution.
Impact
The critical flaw allowed for arbitrary command execution on self-hosted AI Gateway servers. This directly affected organizations that chose to host their own AI Gateway, an option GitLab offers for keeping AI request and response data within the customer's environment. Self-hosted gateways are known to store signing keys for JSON Web Tokens (JWT), which GitLab's install guide designates as sensitive credentials. These gateways also establish connections to the main GitLab instance and to the organization's AI model providers. While the advisory did not confirm any active exploitation, CISA's assessment on October 2 listed exploitation as "none".
Discovery & Response
GitLab disclosed the flaw on October 2, following a report by HackerOne user invisiblemeerkat. The company released fixes for the AI Gateway in versions 19.2.4, 19.3.2, and 19.4.1. GitLab stated that it had already applied these fixes to AI Gateways it hosts for its customers, meaning customers on GitLab.com, GitLab Dedicated, and self-managed instances utilizing a GitLab-hosted gateway were not required to take action. However, GitLab strongly recommended that self-managed customers who host their own gateway update immediately, having sent this guidance to them prior to publishing the advisory. The advisory did not provide any workarounds for gateways that could not be updated or a method to determine if a gateway had been compromised before an update.
How Fencio prevents this
The agent trusted a component it had never verified: a package, an extension, a skill, or a server that looked legitimate. When that component changed or was compromised, the agent carried the payload straight into a trusted environment.
Fencio inventories every tool, server, and skill an agent can reach, pins their versions and declared capabilities, and blocks calls when a component starts doing something its manifest never declared, like reading env files or mailing new recipients.