GitLab AI Gateway Patch: Verify the Running Component, Not Just the Update

What changed, and which deployments need attention

The vulnerability record was published on 2 October 2026. GitLab's advisory covers AI Gateway versions from 18.1.6 before 19.2.4, the 19.3 branch before 19.3.2, and the 19.4 branch before 19.4.1. The vendor rates the issue critical and recommends affected self-hosted customers upgrade promptly (sources 1 and 2).

The distinction is deployment-specific. GitLab says customers using GitLab.com, GitLab Dedicated or a Self-Managed instance connected to a GitLab-hosted AI Gateway do not need action for this issue because the hosted gateway fix is deployed. A company running its own gateway must inspect that component. Owning a Self-Managed GitLab instance alone does not establish exposure (source 1).

This is a disclosed software vulnerability with a stated access prerequisite. The advisory does not establish that every installation was compromised. Leaders should preserve that distinction when briefing customers, suppliers and boards.

Map the gateway as a separate operating dependency

GitLab describes the AI Gateway as a combination of its AI Gateway service and Duo Agent Platform service. Its installation guidance uses authenticated requests and signed tokens, and documents separate signing keys for the services (source 3). That makes the gateway an explicit part of the delivery system rather than an invisible model connection.

GitLab also supports fully self-hosted, hybrid and GitLab-hosted configurations. In a hybrid setup, selected features can use GitLab-managed models through the hosted gateway while others use the customer's gateway (source 4). Ask the technical owner to map each business workflow to its actual gateway, model backend and operating team.

Our analysis: an inventory labelled only 'GitLab Duo enabled' is too coarse for an incident decision. Record the running image or package, environment, configuration owner and dependent workflows.

Build a patch-to-recovery record

Use a short record that connects the advisory to the service your business relies on. The following is an operational framework, not a claim that GitLab prescribes this exact process.

First, establish scope. Identify the gateway instance, running version, hosting arrangement and authorised Duo users. Assign an owner who can decide whether to pause affected workflows while remediation proceeds.

Second, retain the relevant configuration and available service evidence before changes. Protect credentials and sensitive repository content when collecting logs. If there are signs of compromise, involve the organisation's incident-response team rather than treating a successful update as closure.

Third, apply the vendor-supported update for the affected branch. Verify the running replacement after restart and confirm that obsolete instances no longer receive traffic. Keep a continuity route that does not restore the vulnerable service.

Finally, test representative workflows and access boundaries. GitLab provides administrative health checks for connectivity and authentication (source 3). Supplement those with a normal authorised task, an expected rejection and confirmation that logging reaches the responsible team. Record the results and the person accepting restoration.

Make recovery evidence a procurement requirement

The commercial question is who can prove the service is fixed. Ask a managed provider for the affected component, remediation date and deployment evidence. For an internal platform, require the same information from its operating owner. Neither a vendor announcement nor a green health indicator alone answers every recovery question.

This story differs from our earlier self-hosted AI operating-contract analysis: it concerns a named, newly disclosed gateway flaw and the evidence needed to close a specific remediation. ELYMENT AI's practical approach is to connect autonomous work to accountable owners, narrow permissions and visible recovery procedures.

Sources

• GitLab: AI Gateway critical patch release (Accessed 5 October 2026) - Vendor advisory, affected gateway ranges, fixed versions and distinction between self-hosted and already patched hosted gateways.
• NIST NVD: CVE-2026-90970 (2 October 2026) - GitLab-assigned vulnerability record and publication date.
• GitLab: Install the AI Gateway (Accessed 5 October 2026) - Gateway services, authentication and administrative health checks.
• GitLab: Self-hosted models (Accessed 5 October 2026) - Fully self-hosted, hybrid and hosted gateway configurations and operating responsibilities.

Continue learning

• Self-hosted AI needs an operating contract
• An AI business operating system
• Explore ELYMENT AI

Frequently asked questions