Skip to main content
CVE Vulnerability Database

CVE-2024-2878: GitLab Branch Search DoS Vulnerability

CVE-2024-2878 is a denial of service vulnerability in GitLab CE/EE that allows attackers to disrupt services using crafted branch search terms. This article covers the technical details, affected versions, and mitigation.

Published:

CVE-2024-2878 Overview

CVE-2024-2878 is a denial of service vulnerability affecting GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw allows an unauthenticated attacker to disrupt service availability by submitting crafted search terms for branch names. The issue impacts all versions from 15.7 prior to 16.9.7, from 16.10 prior to 16.10.5, and from 16.11 prior to 16.11.2. GitLab addressed the vulnerability in patch releases on May 8, 2024. The weakness is classified under [CWE-770] (Allocation of Resources Without Limits or Throttling), reflecting inadequate constraints on resource consumption during branch name search operations.

Critical Impact

Remote unauthenticated attackers can render GitLab instances unavailable by issuing specially crafted branch name search queries, disrupting source code management, CI/CD pipelines, and developer workflows.

Affected Products

  • GitLab CE/EE versions 15.7 through 16.9.6
  • GitLab CE/EE versions 16.10 through 16.10.4
  • GitLab CE/EE versions 16.11 through 16.11.1

Discovery Timeline

  • 2024-05-08 - GitLab releases patch versions 16.9.7, 16.10.5, and 16.11.2
  • 2025-02-05 - CVE-2024-2878 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-2878

Vulnerability Analysis

The vulnerability resides in GitLab's branch name search functionality. The search handler fails to properly limit computational resources when processing unusual or malformed branch name search terms. Attackers can craft inputs that cause the backend to consume excessive CPU, memory, or processing time. Repeated requests amplify the impact and can exhaust available worker processes. The flaw requires no authentication, no user interaction, and is exploitable over the network against any reachable GitLab instance.

Under [CWE-770], the application accepts unbounded work without enforcing throttling or input complexity limits. This pattern is common in regex-driven or pattern-matching search implementations where adversarial inputs trigger catastrophic backtracking or pathological execution paths. The EPSS score of 17.649% places this issue within an elevated probability band for near-term exploitation activity.

Root Cause

The root cause is missing resource constraints during the parsing and matching of user-supplied branch name search terms. The search component processes input without bounding execution time, recursion depth, or memory allocation. Specific details of the affected code path are documented in GitLab Issue #451918 and the HackerOne Report #2416356.

Attack Vector

An attacker submits crafted search queries to GitLab endpoints that handle branch name lookups. Because the attack vector is network-based and requires no privileges, internet-exposed GitLab instances are directly reachable. Repeated requests can saturate workers and degrade or halt service for all users. The vulnerability does not expose data or allow code execution, but it disrupts availability of repositories, merge requests, and CI/CD operations.

No verified public proof-of-concept code is referenced in the advisory. Refer to the GitLab Patch Release 16.11.2 for the official disclosure.

Detection Methods for CVE-2024-2878

Indicators of Compromise

  • Sudden spikes in CPU or memory usage on GitLab Rails or Sidekiq workers correlated with search activity.
  • HTTP requests to branch search endpoints containing unusually long, repetitive, or pattern-heavy query strings.
  • Increased rates of 5xx responses or request timeouts from GitLab API endpoints handling refs and branches.
  • Worker process restarts or out-of-memory events in GitLab application logs without corresponding deployment changes.

Detection Strategies

  • Inspect web server and reverse proxy logs for repeated calls to branch-search API paths from a single source.
  • Establish performance baselines for GitLab search endpoints and alert on latency or error-rate deviations.
  • Correlate slow request logs from gitlab-rails with source IP reputation and request frequency.

Monitoring Recommendations

  • Forward GitLab production logs, NGINX access logs, and host telemetry to a centralized SIEM for correlation.
  • Track Sidekiq queue depth, Puma worker utilization, and database query duration as availability signals.
  • Alert on anomalous request patterns targeting /api/v4/projects/*/repository/branches and related search endpoints.

How to Mitigate CVE-2024-2878

Immediate Actions Required

  • Upgrade GitLab CE/EE to version 16.9.7, 16.10.5, 16.11.2, or later as soon as feasible.
  • Audit internet exposure of GitLab instances and restrict access to trusted networks where possible.
  • Apply rate limiting at the reverse proxy or web application firewall in front of GitLab.
  • Review recent access logs for evidence of abusive search query patterns.

Patch Information

GitLab released fixed versions 16.9.7, 16.10.5, and 16.11.2 on May 8, 2024. Full details are available in the GitLab Patch Release 16.11.2 announcement. Self-managed customers should follow the standard upgrade procedure for their installation method (Omnibus, Helm, source, or Docker).

Workarounds

  • Enforce GitLab's built-in user and IP rate limits to throttle search requests.
  • Place GitLab behind a WAF and block abnormally long or pattern-heavy branch search query parameters.
  • Restrict anonymous access where business requirements allow, reducing exposure of search endpoints.
  • Monitor and auto-restart unhealthy GitLab workers to limit the duration of degraded service.
bash
# Example: enable application-level rate limiting in /etc/gitlab/gitlab.rb
gitlab_rails['rate_limit_requests_per_period'] = 300
gitlab_rails['rate_limit_period'] = 60
gitlab_rails['throttle_unauthenticated_enabled'] = true
gitlab_rails['throttle_unauthenticated_requests_per_period'] = 100
gitlab_rails['throttle_unauthenticated_period_in_seconds'] = 60

# Apply configuration
sudo gitlab-ctl reconfigure

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.