CVE-2024-9512 Overview
CVE-2024-9512 is a race condition vulnerability in GitLab Enterprise Edition (EE) that can expose private repositories under specific timing conditions. The flaw affects GitLab Geo secondary node synchronization. When a secondary node falls out of sync, an attacker can exploit the timing window to clone a private repository they should not have access to. The issue is tracked under CWE-367: Time-of-Check Time-of-Use (TOCTOU).
Critical Impact
Successful exploitation results in unauthorized disclosure of private repository contents through a network-accessible race condition, with no authentication or user interaction required.
Affected Products
- GitLab EE (Community and Enterprise) all versions prior to 17.10.8
- GitLab EE 17.11 prior to 17.11.4
- GitLab EE 18.0 prior to 18.0.2
Discovery Timeline
- 2025-06-12 - CVE-2024-9512 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-9512
Vulnerability Analysis
The vulnerability exists in GitLab's Geo replication feature, which mirrors repositories across primary and secondary nodes. Geo secondary nodes are intended to serve read-only requests, including git clone operations, based on the access control state replicated from the primary node.
A race condition occurs when a secondary node is temporarily out of sync with the primary. During this drift window, the access control decision and the repository read operation are not atomically bound. An attacker who times a clone request against an out-of-sync secondary can retrieve repository data whose visibility state has changed on the primary but not yet propagated.
The result is confidentiality loss without any impact to integrity or availability. Exploitation requires network access to a Geo secondary node and does not require authentication.
Root Cause
The root cause is a classic time-of-check to time-of-use flaw in the Geo secondary replication pipeline. GitLab evaluates repository visibility and authorization at one point in time, then services the clone request against a repository state that may reflect an earlier, more permissive configuration on the secondary node.
Attack Vector
The attack vector is network-based and requires timing precision. An attacker targets a GitLab deployment with active Geo replication. They must reach a secondary node while it is lagging behind the primary. A clone request issued during the sync gap can return private repository contents. Attack complexity is high because the attacker depends on transient replication lag rather than a deterministic input.
See the GitLab issue tracker entry #497748 and the HackerOne Report #2683469 for the vendor-tracked details.
Detection Methods for CVE-2024-9512
Indicators of Compromise
- Unexpected git clone, git fetch, or git-upload-pack operations against Geo secondary nodes for repositories the requester should not access.
- Repository access log entries on secondary nodes that do not have a corresponding authorization event on the primary.
- Elevated clone traffic to secondary nodes that correlates with periods of measured replication lag.
Detection Strategies
- Correlate Geo replication lag metrics with repository read events. Investigate any clone activity that occurs while a secondary reports out-of-sync status.
- Compare authorization decisions between primary and secondary nodes for the same repository over short time windows to surface visibility mismatches.
- Alert on anonymous or low-privilege sessions successfully cloning repositories marked private on the primary.
Monitoring Recommendations
- Continuously monitor Geo geo_status and replication lag counters exposed by GitLab and alert when secondaries exceed defined lag thresholds.
- Ship GitLab production, Gitaly, and Workhorse access logs to a centralized analytics platform for cross-node correlation of clone events.
- Track repository visibility changes on the primary and validate that read operations after each change occur only against fully synchronized secondaries.
How to Mitigate CVE-2024-9512
Immediate Actions Required
- Upgrade GitLab EE to 17.10.8, 17.11.4, 18.0.2, or later on all primary and Geo secondary nodes.
- Audit repository access logs on Geo secondary nodes for clone events that occurred during known replication lag windows prior to patching.
- Rotate credentials, tokens, and secrets stored in any repository whose visibility changed while a secondary was out of sync.
Patch Information
GitLab addressed the issue in versions 17.10.8, 17.11.4, and 18.0.2. Apply the fixed release that matches your current major/minor branch. Refer to the GitLab issue #497748 for the vendor's remediation record.
Workarounds
- Restrict network access to Geo secondary nodes so only trusted networks and authenticated users can reach clone endpoints until patching is complete.
- Temporarily disable or drain Geo secondaries that cannot maintain acceptable replication lag.
- Enforce stricter monitoring thresholds so that any secondary exceeding replication lag limits is removed from service automatically.
# Verify installed GitLab version and Geo replication status
sudo gitlab-rake gitlab:env:info | grep -i version
sudo gitlab-rake geo:status
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
