CVE-2024-3035: GitLab Privilege Escalation Vulnerability

CVE-2024-3035 Overview

CVE-2024-3035 is a permission check vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw affects all versions from 8.12 prior to 17.0.6, 17.1 prior to 17.1.4, and 17.2 prior to 17.2.2. The issue allows Large File Storage (LFS) tokens to read and write to user-owned repositories beyond their intended scope. The vulnerability maps to CWE-639 (Authorization Bypass Through User-Controlled Key) and requires authenticated network access to exploit.

Critical Impact
Authenticated attackers with a valid LFS token can read from and write to user-owned repositories, compromising source code confidentiality and integrity across affected GitLab instances.

Affected Products

GitLab CE/EE versions 8.12 through 17.0.5
GitLab CE/EE versions 17.1.0 through 17.1.3
GitLab CE/EE versions 17.2.0 and 17.2.1

Discovery Timeline

2024-08-08 - CVE-2024-3035 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-3035

Vulnerability Analysis

GitLab implements Large File Storage (LFS) to manage large binary artifacts outside standard Git object storage. LFS operations use short-lived tokens scoped to specific repositories and operations. The permission check for these tokens failed to correctly enforce boundaries against user-owned repositories. As a result, an attacker in possession of a valid LFS token could pivot beyond the intended repository and perform read and write operations against other repositories owned by the user.

The vulnerability falls under authorization bypass through user-controlled key patterns. The server-side authorization logic relied on token context without re-validating that the requested repository fell within the token's intended scope. Successful exploitation impacts both confidentiality and integrity of source code assets.

Root Cause

The root cause is an incomplete permission check in the LFS token validation path. The check did not consistently verify that the target repository matched the repository for which the LFS token was issued. This gap allowed the same credential to be reused across user-owned repositories that should have required separate authorization.

Attack Vector

An authenticated attacker with low privileges and a valid LFS token issues LFS API requests targeting repositories other than the one the token was scoped for. Because the authorization layer does not reject the mismatched context, the attacker gains read and write access to user-owned repositories. Exploitation requires no user interaction and is performed over the network against the GitLab instance. Full technical detail is documented in GitLab Issue #452297 and HackerOne Report #2424715.

Detection Methods for CVE-2024-3035

Indicators of Compromise

LFS API requests where the authenticated user's token was originally issued for a different repository than the one being accessed.
Unexpected git-lfs push or pull operations against repositories the source user does not normally interact with.
Anomalous write activity to user-owned repositories originating from LFS endpoints rather than standard Git operations.

Detection Strategies

Review GitLab production logs (production_json.log, api_json.log) for LFS endpoint access patterns that cross repository boundaries within a single session.
Correlate LFS token issuance events with subsequent repository access to identify token reuse across distinct projects.
Baseline expected LFS traffic per user and alert on deviations, particularly write operations to repositories without prior LFS history.

Monitoring Recommendations

Ingest GitLab audit logs and Rails logs into a centralized log platform for retention and query.
Monitor for repository content changes committed through the LFS path rather than authenticated Git pushes.
Alert on authentication events from LFS tokens followed by access to repositories outside the token's original scope.

How to Mitigate CVE-2024-3035

Immediate Actions Required

Upgrade GitLab CE/EE to version 17.0.6, 17.1.4, or 17.2.2 or later, depending on the current release branch in use.
Rotate LFS tokens for all users after applying the patch to invalidate any credentials that may have been abused.
Audit user-owned repositories for unauthorized commits, branch changes, or LFS object modifications since the vulnerable window began.

Patch Information

GitLab addressed CVE-2024-3035 in versions 17.0.6, 17.1.4, and 17.2.2. Administrators running versions from 8.12 up to those releases must upgrade to a fixed version. Details are available in GitLab Issue #452297.

Workarounds

No official workaround has been published; upgrading to a fixed version is the required remediation.
Restrict network access to the GitLab instance to trusted users and networks while patching is in progress.
Temporarily disable LFS for sensitive projects if immediate patching is not feasible.

bash

# Verify installed GitLab version prior to and after patching
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5

# Debian/Ubuntu upgrade example to a fixed release
sudo apt-get update && sudo apt-get install gitlab-ee=17.2.2-ee.0

# RHEL/CentOS upgrade example
sudo yum install gitlab-ee-17.2.2-ee.0