CVE-2026-7471: GitLab EE SSRF Vulnerability

CVE-2026-7471 Overview

CVE-2026-7471 is a Server-Side Request Forgery (SSRF) vulnerability in GitLab Enterprise Edition (EE). The flaw affects all versions from 18.8 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. An authenticated user with control of a virtual registry upstream can coerce the GitLab server to issue requests to internal hosts due to improper input validation. The issue is tracked under [CWE-918] and was patched in GitLab Patch Release 18.11.3 on May 13, 2026.

Critical Impact

An authenticated attacker controlling a virtual registry upstream can pivot through GitLab to reach internal-only network services, enabling reconnaissance of otherwise unreachable infrastructure.

Affected Products

• GitLab EE versions 18.8 up to (but not including) 18.9.7
• GitLab EE versions 18.10 up to (but not including) 18.10.6
• GitLab EE versions 18.11 up to (but not including) 18.11.3

Discovery Timeline

• 2026-05-13 - GitLab releases patch version 18.11.3 addressing the issue
• 2026-05-14 - CVE-2026-7471 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-7471

Vulnerability Analysis

The vulnerability resides in GitLab EE's virtual registry feature. Virtual registries allow GitLab to proxy and cache artifacts from upstream package sources. When an authenticated user configures a virtual registry upstream, GitLab fetches resources from the supplied location on behalf of the user.

GitLab fails to properly validate the upstream destination before issuing the outbound request. An attacker who can configure or modify the upstream URL can direct the server to internal hosts unreachable from the public internet. The result is a classic SSRF condition, classified as [CWE-918]: Server-Side Request Forgery.

The attack requires authentication and the privilege to control a virtual registry upstream, which limits the population of potential abusers. Exploitation complexity is higher than typical SSRF flaws because of these prerequisites, and the impact is confined to confidentiality of information reachable on internal networks.

Root Cause

The root cause is improper validation of user-supplied upstream URLs in the virtual registry component. The application accepts arbitrary host targets without enforcing an allowlist of permitted destinations or blocking RFC 1918 address space, loopback interfaces, and link-local ranges.

Attack Vector

An authenticated user with control over a virtual registry configuration sets the upstream URL to an internal target such as http://169.254.169.254/ (cloud metadata) or http://localhost:6379/ (internal Redis). When GitLab attempts to proxy a registry request, the backend issues an HTTP request to the attacker-chosen host. Response data or differential timing can reveal information about internal services.

No verified exploit code is publicly available. Refer to the GitLab Work Item #594196 for upstream tracking.

Detection Methods for CVE-2026-7471

Indicators of Compromise

• Outbound HTTP requests from GitLab application servers to RFC 1918 ranges, 127.0.0.0/8, or 169.254.0.0/16 originating from the virtual registry service.
• Audit log entries showing virtual registry upstream URL changes by non-administrative users.
• Unexpected DNS resolutions from GitLab hosts targeting internal hostnames not associated with normal CI/CD workflows.

Detection Strategies

• Inspect GitLab production logs for virtual registry upstream configuration events and correlate with the source user identity.
• Monitor egress traffic from GitLab nodes for connections to internal-only address space.
• Compare configured upstream URLs against an allowlist of approved external registries.

Monitoring Recommendations

• Enable GitLab audit events for package registry configuration changes and forward them to a centralized SIEM.
• Alert on any outbound connection from GitLab to cloud metadata endpoints such as 169.254.169.254.
• Track GitLab version inventory to ensure all instances are running 18.9.7, 18.10.6, 18.11.3, or later.

How to Mitigate CVE-2026-7471

Immediate Actions Required

• Upgrade GitLab EE to 18.9.7, 18.10.6, or 18.11.3 as appropriate for your release branch.
• Audit existing virtual registry upstream configurations and remove any pointing to internal or unexpected hosts.
• Review the list of users with permission to configure virtual registries and reduce privileges where unnecessary.

Patch Information

GitLab addressed the issue in patch release 18.11.3 published on May 13, 2026. Apply the fix by upgrading to a patched version on each supported branch. See the GitLab Patch Release 18.11.3 advisory for upgrade instructions.

Workarounds

• Restrict outbound network access from GitLab application servers using egress firewall rules that deny traffic to internal subnets, loopback, and cloud metadata addresses.
• Disable the virtual registry feature if it is not in active use within your environment.
• Limit the role permissions required to create or modify virtual registry upstreams to trusted administrators only.

# Example egress restriction (iptables) blocking GitLab access to internal metadata and RFC1918
iptables -A OUTPUT -m owner --uid-owner git -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner git -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner git -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner git -d 192.168.0.0/16 -j REJECT