CVE-2023-4647: GitLab Projects API DoS Vulnerability

CVE-2023-4647 Overview

A Denial of Service (DoS) vulnerability has been discovered in GitLab affecting the projects API pagination mechanism. This vulnerability allows an attacker to bypass pagination controls in the projects API, potentially causing resource exhaustion and service disruption on affected GitLab instances. The issue stems from improper resource allocation without proper limits (CWE-770), enabling malicious actors to overwhelm server resources through uncontrolled API requests.

Critical Impact

Attackers can bypass API pagination controls to trigger resource exhaustion, potentially causing Denial of Service on GitLab instances and disrupting development workflows for all users.

Affected Products

• GitLab Community Edition versions 15.2 to 16.1.4
• GitLab Enterprise Edition versions 15.2 to 16.1.4
• GitLab Community Edition versions 16.2 to 16.2.4
• GitLab Enterprise Edition versions 16.2 to 16.2.4
• GitLab Community Edition version 16.3.0
• GitLab Enterprise Edition version 16.3.0

Discovery Timeline

• 2023-09-01 - CVE-2023-4647 published to NVD
• 2025-05-05 - Last updated in NVD database

Technical Details for CVE-2023-4647

Vulnerability Analysis

This vulnerability affects GitLab's projects API pagination functionality. Under normal operation, pagination controls limit the amount of data returned per API request to prevent server overload. However, the vulnerability allows these pagination safeguards to be bypassed, enabling attackers to request excessive amounts of data in a single request or series of rapid requests.

The flaw is classified as CWE-770 (Allocation of Resources Without Limits or Throttling), which occurs when the application does not properly constrain the allocation of resources requested by an actor. In this case, the projects API fails to enforce proper pagination boundaries, allowing an attacker to consume excessive server resources including CPU, memory, and database connections.

Root Cause

The root cause lies in insufficient validation of pagination parameters in the GitLab projects API. The API implementation does not properly enforce mandatory pagination or validate user-supplied pagination parameters, allowing requests that circumvent normal resource allocation controls. This enables an unauthenticated network attacker to trigger resource exhaustion by crafting API requests that bypass pagination entirely.

Attack Vector

The vulnerability is exploitable over the network without authentication or user interaction. An attacker can craft malicious API requests to the projects endpoint that bypass pagination controls. By sending these requests, the attacker can force the GitLab server to process and return large amounts of data, consuming server resources and potentially causing service degradation or complete unavailability.

The attack can be particularly effective against GitLab instances with large numbers of projects, as bypassing pagination on such instances would require the server to process significantly more data, amplifying the denial of service impact.

Technical details regarding the specific exploitation method can be found in the GitLab Issue Discussion.

Detection Methods for CVE-2023-4647

Indicators of Compromise

• Unusual volume of requests to /api/v4/projects or similar projects API endpoints
• API requests with abnormal or missing pagination parameters (per_page, page)
• Elevated server resource utilization (CPU, memory, database connections) correlating with API activity
• Error logs indicating database timeouts or memory exhaustion during API request processing

Detection Strategies

• Monitor API access logs for requests to the projects endpoint with unusually large per_page values or missing pagination parameters
• Implement rate limiting alerts on API endpoints to detect anomalous request patterns
• Configure application performance monitoring (APM) to alert on resource spikes associated with API activity
• Deploy web application firewall (WAF) rules to detect and block malformed pagination requests

Monitoring Recommendations

• Enable detailed logging for GitLab API requests, particularly for the projects API endpoints
• Set up alerting thresholds for API response times exceeding normal baselines
• Monitor database query performance for slow or resource-intensive queries originating from API handlers
• Implement real-time dashboards tracking API request volume and server resource consumption

How to Mitigate CVE-2023-4647

Immediate Actions Required

• Upgrade GitLab to version 16.1.5, 16.2.5, or 16.3.1 or later immediately
• Implement rate limiting on API endpoints if not already configured
• Monitor system resources and API logs for signs of exploitation attempts
• Consider temporarily restricting access to the projects API for untrusted networks if immediate patching is not possible

Patch Information

GitLab has released security patches addressing this vulnerability in the following versions:

• GitLab 16.1.5 for the 16.1.x branch
• GitLab 16.2.5 for the 16.2.x branch
• GitLab 16.3.1 for the 16.3.x branch

Organizations should upgrade to these patched versions or later releases as soon as possible. For detailed patch information, refer to the GitLab Issue Discussion.

Workarounds

• Configure a reverse proxy or WAF to enforce strict pagination parameters on projects API requests
• Implement rate limiting at the network or application level to restrict the number of API requests from a single source
• Restrict access to the projects API to authenticated users only if anonymous access is not required
• Consider network-level restrictions to limit API access to trusted IP ranges until patching is complete

# Example: Rate limiting configuration for nginx reverse proxy
# Add to nginx configuration to limit API request rates

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api/v4/projects {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://gitlab_upstream;
}