SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

GitLab AI Gateway flaw crosses from a custom flow into server commands

CVE-2026-90970 lets a user with Duo Agent Platform access, under certain conditions, escape a prompt-template sandbox on a self-hosted AI Gateway. The patch decision depends on which gateway a GitLab instance actually uses.

By Parminder Kumar Sharma · · 10 min read

The affected component is a separate service

GitLab has released AI Gateway 19.2.4, 19.3.2 and 19.4.1 to fix CVE-2026-90970, a critical flaw rated 9.9. In GitLab's account, a person already authenticated and able to use the Duo Agent Platform could, under certain conditions, submit a specially crafted custom-flow configuration that escapes a prompt-template sandbox and causes arbitrary commands to run on the AI Gateway. That is server-side command execution, not merely an AI assistant producing an unsafe answer.

The crucial scoping question is where the AI Gateway runs. A GitLab Self-Managed installation can use its own gateway, GitLab's hosted gateway, or a hybrid arrangement in which different features take different routes. GitLab says it already fixed its hosted gateways; GitLab.com, GitLab Dedicated and self-managed customers whose affected features use GitLab's hosted gateway need no action for this advisory. Operators with a self-hosted gateway do need to check the gateway image itself. Upgrading only the main GitLab application would not demonstrate that this separate service is patched.

Why a flow configuration is a sensitive input

A custom flow is not a chat message. It is a configured, multi-step workflow managed in a GitLab project and enabled for other projects under defined visibility and access rules. GitLab's documentation describes a YAML configuration for the flow, a managing project, triggers and agents that can perform work. A person creating a flow in the product UI normally needs a Maintainer or Owner role in its managing project. The security notice, however, only states that the potential attacker is authenticated and has Duo Agent Platform access. It does not establish that the UI creation role is the minimum role for the vulnerable path.

That distinction matters because the input is treated as configuration for a server-side service, not as ordinary untrusted text to be summarised. Prompt templates should be rendered only within the intended sandbox. GitLab says a specially crafted flow configuration could escape it and reach commands on the AI Gateway. A prompt that persuades a model to answer badly and a configuration that makes the gateway process execute code are different failure modes. The latter crosses from data into the host application's execution context. The advisory does not explain the exact template syntax or parsing defect, so no responsible reconstruction can go further than that confirmed boundary.

The three trust decisions in a custom flow deployment.

  1. Boundary
    Project to flow
    Expected behaviour
    An authorised user supplies workflow configuration
    Why it matters here
    The actor is authenticated; the exact minimum permission for this flaw is not public
  2. Boundary
    Flow to template
    Expected behaviour
    Configuration is interpreted within a template sandbox
    Why it matters here
    GitLab identifies this sandbox as the escaped boundary
  3. Boundary
    Template to gateway host
    Expected behaviour
    Template content must not become operating-system commands
    Why it matters here
    The stated impact is arbitrary command execution on the AI Gateway

The disclosed TTP: configuration becomes execution

A custom flow is meant to let an authorised user configure an AI workflow. GitLab's customisation guidance describes project-level flow definitions; its security notice identifies a specially crafted flow configuration as the trigger here. The trusted operation is to interpret a prompt template inside its sandbox. The failure is that attacker-controlled configuration can break out of that boundary and reach command execution in the gateway process.

The public advisory does not provide the payload, an endpoint, an observed persistence method, or evidence that a model response alone triggers the flaw. Those missing details matter. A defender should not write an invented detection rule around a guessed string or claim a complete attack chain from the release note. The defensible TTP is limited to the actor's access, the manipulated configuration surface, the sandbox crossing and the execution result GitLab states.

Disclosed attack conditions, separated from unanswered incident questions.

  1. Stage
    Entry
    What GitLab establishes
    Authenticated user with Duo Agent Platform access
    What remains unpublished
    Minimum role and exact permission combination
  2. Stage
    Input
    What GitLab establishes
    Specially crafted custom-flow configuration
    What remains unpublished
    Payload, endpoint and template syntax
  3. Stage
    Boundary
    What GitLab establishes
    Escape from the prompt-template sandbox
    What remains unpublished
    Precise implementation defect
  4. Stage
    Impact
    What GitLab establishes
    Arbitrary command execution on AI Gateway
    What remains unpublished
    Victim count, observed follow-on activity

Why 9.9 is a severity score, not an outbreak report

GitLab publishes a CVSS v3.1 score of 9.9, with fields AV:N · AC:L · PR:L · UI:N · S:C · C:H · I:H · A:H. They describe an attack reachable over a network, with low attack complexity and low privileges after authentication, no separate victim interaction, a changed security scope and high possible effects on confidentiality, integrity and availability. The score expresses the potential consequence under the scoring assumptions. It does not tell us whether anyone exploited the bug, how often custom flows were reachable, or what an attacker actually did in a customer's environment.

The changed-scope and high-impact fields help explain why this is more serious than an incorrect AI answer: the hypothetical compromise moves beyond the trust boundary of the original configuration into the gateway's execution environment. But the public notice does not identify the process account, container privileges, reachable secrets, outbound routes or exploit reliability. None of those should be silently filled in from the score. The practical priority comes from the vendor's immediate-upgrade guidance for affected self-hosted gateways, followed by an exposure assessment for the period in which the vulnerable version ran.

The version and hosting matrix

Affected ranges and first fixed AI Gateway releases in GitLab’s 2 October notice.

  1. AI Gateway line
    18.1.6 through 19.2
    Affected
    From 18.1.6, before 19.2.4
    First fixed release
    19.2.4
  2. AI Gateway line
    19.3
    Affected
    Before 19.3.2
    First fixed release
    19.3.2
  3. AI Gateway line
    19.4
    Affected
    Before 19.4.1
    First fixed release
    19.4.1

The product distinction is easy to miss because a GitLab instance and its AI Gateway have separate versions. GitLab's architecture guide describes a fully self-hosted route, a GitLab-hosted route and a hybrid setup. In a hybrid setup, the answer may differ by feature. Check the gateway URL and deployed container or Helm image, then map which Duo features actually use it. Do not infer the gateway version from the GitLab web interface's version.

GitLab says a fix was already deployed for its hosted gateways. Its notice directs every affected self-hosted gateway to one of the patched releases immediately. This is a configuration and deployment inventory task before it is a generic 'update GitLab' ticket.

Patch decision by gateway route, according to GitLab.

  1. Deployment route
    Self-hosted AI Gateway
    Action for this advisory
    Check exact gateway image; upgrade an affected line
  2. Deployment route
    GitLab-hosted AI Gateway
    Action for this advisory
    No customer gateway update required; GitLab says it fixed the service
  3. Deployment route
    Hybrid
    Action for this advisory
    Check each relevant feature route; patch any affected self-hosted gateway

Find the running gateway, not just the GitLab version

The AI Gateway is a separately deployed service. GitLab's installation guide describes a container image with an AI Gateway service and a Duo Agent Platform service, and separate HTTP and gRPC paths. It also documents versioned self-hosted-vX.Y.Z-ee image tags. A change to the GitLab application does not prove that the gateway image running behind those paths changed. Check the actual container or Kubernetes workload and its image digest or tag, then compare that deployed version with the three fixed lines in the notice. Record the pre-change and post-change values so the fix can be audited.

Next trace feature routing. GitLab's self-hosted model guide says a hybrid deployment can send a feature using a GitLab-managed model to GitLab's hosted AI Gateway while another feature uses the customer's gateway. The label 'self-managed GitLab' is therefore not enough to decide exposure; the relevant feature and its gateway destination are the unit of analysis. Conversely, owning a self-hosted gateway does not mean every AI request reaches it. Where several gateways or environments exist, inventory each one, including staging systems and standby workloads that could be promoted later.

Take this with you

Keep four pieces of evidence for each environment

  • The gateway endpoint actually configured for the relevant Duo feature, including hybrid routes.
  • The running image tag or digest and the workload or host on which it runs.
  • The patched image tag or digest after rollout, plus service health and a representative feature test.
  • The period the affected image was running and who could edit or submit custom-flow configuration then.

An operator sequence that tests the actual boundary

Take this with you

Verify and act

  • Inventory AI Gateway deployments, image tags and feature routing, including hybrid configurations.
  • Compare each self-hosted gateway with the affected ranges and move to 19.2.4, 19.3.2 or 19.4.1 as appropriate.
  • Confirm the new container or Helm workload is running and the GitLab instance still reaches the intended gateway.
  • Review who could create or change custom flows during the exposure period; preserve relevant change and gateway logs before drawing incident conclusions.

GitLab's installation guide shows why the image tag matters: the AI Gateway is deployed as its own service and generally tracks the GitLab version. Verification should inspect the running service, not just a desired configuration file or a completed change request. Restricting custom-flow permissions may reduce exposure while an update is arranged, but GitLab presents upgrading the affected gateway as the fix.

There is no published claim here that customer data was stolen or that an exploit is circulating. For a potentially exposed gateway, reviewing who had flow access and whether configurations changed is a prudent investigation step, not evidence that those events occurred. The decisive control remains the patched gateway version.

What an investigation can check without inventing an exploit signature

If a vulnerable self-hosted gateway was reachable, begin with a narrow evidence question: who could submit or modify flow configuration, and which flows changed while that image ran? Preserve the relevant project audit history, flow definitions, gateway application logs, container or host process telemetry and outbound network records where those sources exist. Compare unexpected flow changes with the responsible user's activity and change tickets. If gateway telemetry shows an unusual child process or outbound connection, investigate it as a lead, not as a vendor-confirmed indicator of this CVE.

GitLab has not supplied a payload, detection pattern or exploit endpoint in the public release. That means a search for one guessed string would create false reassurance. The same restraint applies to a lack of findings: missing or short-retention logs cannot prove that exploitation did not occur. Document what was observable, what was not retained and whether the relevant custom-flow function was enabled. Preserve evidence before rotating or deleting the old gateway workload, and follow your normal incident process if independent suspicious activity is found. These are investigative choices inferred from the disclosed entry surface and impact; they are not a claim that GitLab observed such activity.

Evidence questions tied to the disclosed route.

  1. Question
    Could a flow be changed?
    Useful record
    Flow configuration and project audit history
    Interpretation limit
    Permission or change alone is not exploitation
  2. Question
    Did the gateway behave unexpectedly?
    Useful record
    Gateway, container and process telemetry
    Interpretation limit
    No public exploit signature exists for a definitive match
  3. Question
    Could execution reach elsewhere?
    Useful record
    Network egress and host access records
    Interpretation limit
    Potential reach is not proof that data left

The decision in one sentence

For this advisory, the decisive question is whether any Duo feature used an affected self-hosted AI Gateway image. If yes, update that image to the fixed release for its line and verify the running service. If no, retain the route evidence that supports that conclusion. The public record supports the boundary and the remedy; it does not support a fabricated exploit walkthrough or a breach claim.

Sources

  1. PrimaryAI Gateway critical patch releaseGitLabaccessed 2026-10-02
  2. PrimarySelf-hosted models and gateway choicesGitLabaccessed 2026-10-02
  3. PrimaryCustomise Duo Agent PlatformGitLabaccessed 2026-10-02
  4. PrimaryInstall the GitLab AI GatewayGitLabaccessed 2026-10-02
  5. PrimaryCustom flows and project permissionsGitLabaccessed 2026-10-02

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.