CVE-2024-11274: GitLab Information Disclosure Vulnerability

CVE-2024-11274 Overview

CVE-2024-11274 affects GitLab Community Edition (CE) and Enterprise Edition (EE) across a range of 16.x and 17.x releases. The vulnerability allows injection of Network Error Logging (NEL) headers in the Kubernetes proxy response. An attacker who tricks an authenticated user into visiting a crafted URL can exfiltrate session data through the browser's NEL reporting mechanism. The flaw is tracked under CWE-601 (URL Redirection to Untrusted Site) and impacts confidentiality and integrity across a changed scope.

Critical Impact
Successful exploitation permits exfiltration of GitLab session data from users who interact with a malicious link, enabling account takeover of developers and maintainers with access to source code and CI/CD pipelines.

Affected Products

GitLab CE/EE versions 16.1 through 17.4.5
GitLab CE/EE versions 17.5 through 17.5.3
GitLab CE/EE versions 17.6 through 17.6.1

Discovery Timeline

2024-12-12 - CVE-2024-11274 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-11274

Vulnerability Analysis

The vulnerability resides in GitLab's Kubernetes proxy component, which forwards requests from GitLab users to Kubernetes API endpoints. The proxy fails to sanitize response headers received from upstream, allowing an attacker to influence the NEL and Report-To headers returned to the user's browser.

Network Error Logging is a browser mechanism that reports network-level errors to an operator-controlled endpoint. When an attacker can control these headers on a GitLab origin response, the browser stores a reporting policy scoped to gitlab.com (or the self-hosted host). Subsequent requests that trigger errors then send request metadata, including URL paths and cookies exposed through referrer data, to the attacker-controlled collector.

Exploitation requires an authenticated user (PR:L) and user interaction (UI:R) with a crafted link. The scope change (S:C) reflects that the injected browser policy persists beyond the vulnerable component and leaks data to an external origin.

Root Cause

The root cause is missing output validation on headers returned from the Kubernetes proxy path. GitLab treats upstream response headers as trusted and passes NEL and Report-To values back to the client without filtering. This allows an attacker who controls a reachable endpoint through the proxy to inject arbitrary browser reporting policies.

Attack Vector

An attacker crafts a URL pointing to the GitLab k8s proxy endpoint that resolves to an upstream returning attacker-controlled NEL and Report-To headers. The victim, who must be authenticated to GitLab, clicks the link. The browser stores the malicious reporting policy against the GitLab origin. Requests generated from the victim's session that meet the failure conditions defined in the policy then transmit metadata, including URL paths that may embed session identifiers or tokens, to the attacker's collector.

See the GitLab issue #504707 and the HackerOne Report #2813673 for the disclosure record.

Detection Methods for CVE-2024-11274

Indicators of Compromise

Outbound requests from GitLab users' browsers to unknown domains carrying application/reports+json payloads, indicating a NEL reporting policy is active.
HTTP responses from /api/v4/projects/*/environments/*/proxy or similar k8s proxy paths containing NEL or Report-To headers referencing external hosts.
Session activity from GitLab accounts originating from IP addresses inconsistent with the user's historical geolocation shortly after the user clicks an external link.

Detection Strategies

Inspect GitLab reverse proxy or web server logs for k8s proxy responses that carry NEL or Report-To headers, and alert on any value not matching the organization's expected reporting endpoint.
Correlate GitLab access logs with EDR browser telemetry to identify sessions where users navigated to k8s proxy URLs with unusual query parameters immediately before authentication anomalies.
Hunt for GitLab audit events showing session reuse from new IPs on accounts belonging to developers with cluster access.

Monitoring Recommendations

Enable GitLab audit event streaming to a centralized log platform and retain proxy access logs for at least 90 days.
Monitor egress traffic from developer workstations for connections to newly observed domains that receive POST requests with reporting media types.
Track privileged GitLab role assignments and CI/CD variable access to catch downstream abuse after possible session theft.

How to Mitigate CVE-2024-11274

Immediate Actions Required

Upgrade GitLab CE/EE to version 17.4.6, 17.5.4, or 17.6.2 or later, depending on your current major release.
Revoke active sessions and rotate personal access tokens for users who may have followed suspicious k8s proxy links since the vulnerable versions were deployed.
Audit Kubernetes cluster integrations attached to GitLab projects and remove any that are unused or unowned.

Patch Information

GitLab addressed the vulnerability in versions 17.4.6, 17.5.4, and 17.6.2. The patch strips or validates NEL and Report-To headers returned by the Kubernetes proxy before forwarding them to the client. Self-managed administrators should follow the upgrade path defined in the GitLab Issue #504707 advisory. GitLab.com SaaS tenants are already patched.

Workarounds

Disable Kubernetes cluster integrations on GitLab projects until the instance is upgraded.
Restrict network egress from GitLab users' browsers to prevent NEL report submissions to unapproved external collectors.
Enforce short session lifetimes and require re-authentication for sensitive actions such as CI/CD variable modification and token issuance.

bash

# Verify installed GitLab version on a self-managed instance
sudo gitlab-rake gitlab:env:info | grep -i 'GitLab information' -A 5

# Example Omnibus upgrade to a fixed release
sudo apt-get update && sudo apt-get install gitlab-ee=17.6.2-ee.0
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart