CVE-2026-1184: GitLab EE Denial of Service Vulnerability

CVE-2026-1184 Overview

CVE-2026-1184 is a denial-of-service vulnerability affecting GitLab Enterprise Edition (EE). The flaw resides in file upload handling where improper validation allows a low-privileged user to cause service disruption. Affected versions include all releases from 11.9 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. The weakness is categorized under CWE-502: Deserialization of Untrusted Data. GitLab addressed the issue in the 18.11.3 patch release on May 13, 2026.

Critical Impact

An authenticated attacker can disrupt GitLab availability by uploading a specially crafted file, impacting development pipelines and source control operations across the organization.

Affected Products

• GitLab EE versions 11.9 through 18.9.6
• GitLab EE versions 18.10 through 18.10.5
• GitLab EE versions 18.11 through 18.11.2

Discovery Timeline

• 2026-05-13 - GitLab releases patch version 18.11.3
• 2026-05-14 - CVE-2026-1184 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-1184

Vulnerability Analysis

The vulnerability stems from improper validation of file uploads in GitLab EE. An attacker with low privileges can submit a specially crafted file that the application fails to validate correctly. Processing the malformed input drives resource exhaustion and renders the service unavailable to legitimate users.

The CWE-502 classification indicates the underlying issue involves deserialization of untrusted data. When the GitLab backend deserializes attacker-controlled content without sufficient guardrails, the operation consumes excessive resources or triggers an unrecoverable failure path. The result is a denial-of-service condition affecting the entire GitLab instance.

Root Cause

The root cause is missing or insufficient input validation before deserialization of uploaded file content. GitLab's file ingestion pipeline accepts payloads that should be rejected at the boundary. Without strict schema checks and resource limits, malicious input reaches a deserialization routine that exhausts memory or CPU.

Attack Vector

The attack requires network access to the GitLab instance and a valid authenticated session with low privileges. The attacker uploads a crafted file through a standard GitLab upload endpoint. No user interaction is required beyond the attacker's own request. Refer to the GitLab Patch Release 18.11.3 advisory and the HackerOne Report #3515842 for additional context.

Detection Methods for CVE-2026-1184

Indicators of Compromise

• Sudden spikes in CPU or memory consumption on GitLab application or Sidekiq worker nodes
• Unexpected 500 errors or worker restarts following a file upload request
• Authenticated upload requests from low-privilege accounts targeting attachment, import, or artifact endpoints

Detection Strategies

• Inspect GitLab production.log and application.log entries for upload requests immediately preceding service degradation
• Correlate Rails worker termination events with the originating user, IP address, and uploaded content type
• Audit Sidekiq job failures tied to deserialization or background processing of user-supplied files

Monitoring Recommendations

• Track per-user upload request rates and file sizes against historical baselines
• Alert when GitLab Unicorn or Puma worker memory exceeds configured thresholds during upload operations
• Forward GitLab application logs and host telemetry to a centralized analytics platform for cross-source correlation

How to Mitigate CVE-2026-1184

Immediate Actions Required

• Upgrade GitLab EE to 18.11.3, 18.10.6, or 18.9.7 as appropriate for your deployment branch
• Review authentication logs and revoke sessions or tokens for accounts that exhibit suspicious upload activity
• Restrict GitLab instance exposure to trusted networks where operationally feasible

Patch Information

GitLab released fixed versions 18.9.7, 18.10.6, and 18.11.3 on May 13, 2026. Details and upgrade instructions are available in the GitLab Patch Release 18.11.3 announcement and the associated GitLab Work Item #586634.

Workarounds

• Apply rate limiting on upload endpoints via GitLab application settings or an upstream reverse proxy
• Enforce maximum upload size limits at the web server (NGINX client_max_body_size) and GitLab attachment configuration
• Temporarily disable non-essential import and upload features for untrusted user tiers until patching completes

# Example NGINX upload size restriction for GitLab
http {
    client_max_body_size 25m;
    client_body_timeout 30s;
    limit_req_zone $binary_remote_addr zone=uploads:10m rate=10r/m;

    server {
        location /uploads/ {
            limit_req zone=uploads burst=5 nodelay;
        }
    }
}