CVE-2025-11974: GitLab CE/EE DOS Vulnerability

CVE-2025-11974 Overview

CVE-2025-11974 is a resource exhaustion vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw affects all versions from 11.7 before 18.3.5, 18.4 before 18.4.3, and 18.5 before 18.5.1. An attacker can create a denial of service (DoS) condition by uploading large files to specific API endpoints. The vulnerability is classified under [CWE-770] Allocation of Resources Without Limits or Throttling. GitLab released patch version 18.5.1 on October 22, 2025 to remediate the issue.

Critical Impact
A network-based attacker can exhaust server resources by uploading oversized files to affected API endpoints, disrupting availability of GitLab services for legitimate users.

Affected Products

GitLab Community Edition (CE) versions 11.7 through 18.3.4
GitLab Enterprise Edition (EE) versions 18.4 through 18.4.2
GitLab CE/EE version 18.5.0

Discovery Timeline

2025-10-22 - GitLab releases security patch (18.5.1, 18.4.3, 18.3.5)
2025-10-27 - CVE-2025-11974 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-11974

Vulnerability Analysis

The vulnerability resides in specific GitLab API endpoints that accept file uploads without adequate size or rate constraints. When these endpoints process incoming requests, they allocate server memory, disk, or processing capacity proportional to the uploaded payload. An attacker submitting arbitrarily large files can consume storage, bandwidth, and worker threads until the GitLab instance becomes unresponsive.

The issue is tracked as [CWE-770] Allocation of Resources Without Limits or Throttling. The CVSS vector indicates a network-reachable attack that affects only availability. Confidentiality and integrity remain intact, but sustained exploitation degrades the platform for all users, including CI/CD pipelines, Git operations, and web console access.

Root Cause

The affected API endpoints did not enforce upload size limits or throttling controls appropriate for their function. This allowed request handlers to accept and buffer files large enough to exhaust available resources on the GitLab application or Sidekiq worker nodes. Additional technical context is available in the GitLab issue tracker discussion.

Attack Vector

Exploitation requires network access to the GitLab instance and a low-privileged authenticated session for the vulnerable endpoints. The attacker issues repeated POST or PUT requests carrying large file payloads to the affected upload endpoints. Each request forces the backend to allocate memory and I/O capacity, and concurrent requests amplify the impact. Self-managed GitLab instances exposed to the internet face the greatest risk because attackers can sustain the flood without egress limits.

See the GitLab Patch Release Announcement for the vendor's technical description.

Detection Methods for CVE-2025-11974

Indicators of Compromise

Unusually large HTTP request bodies directed at GitLab API upload endpoints from a single source or small set of sources.
Sustained spikes in Sidekiq queue depth, Puma worker saturation, or disk I/O on the GitLab application server.
Repeated 5xx responses or gateway timeouts correlated with upload traffic in NGINX or reverse proxy logs.

Detection Strategies

Parse GitLab production logs (production_json.log, api_json.log) for API requests exceeding an expected size baseline for the endpoint.
Correlate authentication events with upload volume per user token to surface abusive accounts.
Alert on abrupt drops in GitLab availability metrics (HTTP 200 rate, background job throughput) that coincide with inbound upload bursts.

Monitoring Recommendations

Instrument Prometheus metrics for gitlab_transaction_duration_seconds and request payload size histograms on API endpoints.
Forward GitLab, NGINX, and system-level metrics to a centralized SIEM for cross-source correlation.
Configure availability probes against representative GitLab endpoints to detect service degradation early.

How to Mitigate CVE-2025-11974

Immediate Actions Required

Upgrade self-managed GitLab CE/EE deployments to 18.5.1, 18.4.3, or 18.3.5 as applicable.
Restrict network exposure of GitLab administrative and API endpoints to trusted networks or VPN users where feasible.
Rotate any personal access tokens or deploy tokens suspected of being used in abuse patterns.

Patch Information

GitLab remediated the flaw in versions 18.5.1, 18.4.3, and 18.3.5. Details and download links are provided in the GitLab Patch Release Announcement. GitLab.com SaaS customers received the fix automatically. Self-managed operators should follow the standard upgrade path and verify version output after upgrade.

Workarounds

Enforce request size limits at the reverse proxy layer (for example, client_max_body_size in NGINX) tuned to legitimate upload needs.
Apply rate limiting on API upload endpoints via GitLab's built-in rate limits under Admin Area > Settings > Network.
Deploy a Web Application Firewall rule to drop oversized POST bodies targeting affected upload paths until the patch is applied.

bash

# Configuration example: NGINX request size limit for GitLab upstream
http {
    client_max_body_size 100m;

    server {
        listen 443 ssl;
        server_name gitlab.example.com;

        location /api/ {
            client_max_body_size 50m;
            proxy_pass http://gitlab_upstream;
        }
    }
}