CVE-2026-75871 is a high severity (CVSS 8.2) server-side request forgery in the GitLab AI Gateway. A user with Duo Agent Platform access can redirect model requests to a server they control and capture Google Vertex credentials. Update the gateway to a patched release listed in the GitLab advisory.
What's affected
- Product: GitLab AI Gateway component.
- Affected: 18.10 to 19.0.12, 19.1 to 19.1.7, and 19.2 to 19.2.2.
- Fixed: GitLab says it remediated the issue. The pages I could load do not name the fixed builds, so take the exact versions from the GitLab work item. The affected ranges end at 19.0.12, 19.1.7 and 19.2.2, so you need a later patch in the same line.
- Weakness: CWE-918, server-side request forgery.
- CVSS 8.2 (high), vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N. Not listed in CISA KEV.
How to check if you're exposed
Start with your own deployment model. If you only use GitLab.com, GitLab runs the gateway for you. If you self host GitLab and run the AI Gateway yourself, find its version.
# if you run the gateway as a container
docker ps --format '{{.Image}}' | grep -i ai-gateway
Compare the image tag against the affected ranges. Then list who has Duo Agent Platform access, since the record says an authenticated user with that access is needed. Look in the gateway's outbound traffic logs for model requests going to hosts that are not your approved model provider endpoints.
What to do now
- Open the GitLab work item linked in the record and note the fixed AI Gateway version for your release line.
- Upgrade the AI Gateway to that version or later. Keep the gateway and the GitLab instance on matching supported versions.
- Restrict Duo Agent Platform access to the users who need it until the upgrade is done.
- Restrict the gateway host with egress rules so it can only reach your model provider endpoints.
- If you suspect misuse, rotate the Google Cloud Vertex credentials and signing keys the gateway uses, and review audit logs for the period before the upgrade.
Why it matters
The record describes a crafted inline flow configuration that overrides the HTTP Host header. That sends outbound model requests to an endpoint the user controls, so whatever credentials the gateway attaches to those requests go with them.
This is an old class with a new setting. A service that holds cloud credentials and makes requests on behalf of users has to pin where those requests may go. Treat any AI gateway as a credential holder, give it narrow egress, and keep user supplied configuration away from request headers.
Quick check
Does this affect GitLab.com users?
The record covers the AI Gateway component by version. Self hosted operators should check their gateway version, and GitLab hosts its own on GitLab.com.
Why does egress filtering help?
If the gateway can only reach your model provider, a redirected request has nowhere to go.
Sources
Last reviewed: 19 October 2026.
