CVE-2026-1388: GitLab CE/EE ReDoS Vulnerability

CVE-2026-1388 Overview

A Regular Expression Denial of Service (ReDoS) vulnerability has been identified in GitLab CE/EE affecting all versions from 9.2 before 18.7.5, 18.8 before 18.8.5, and 18.9 before 18.9.1. This vulnerability allows an unauthenticated user to cause a denial of service condition by sending specially crafted input to a merge request endpoint under certain conditions.

Critical Impact

Unauthenticated attackers can exploit this vulnerability remotely to cause service disruption, potentially affecting GitLab availability for all users of an affected instance.

Affected Products

• GitLab Community Edition (CE) versions 9.2 to 18.7.4
• GitLab Enterprise Edition (EE) versions 9.2 to 18.7.4
• GitLab CE/EE versions 18.8.0 to 18.8.4
• GitLab CE/EE versions 18.9.0

Discovery Timeline

• 2026-02-25 - CVE-2026-1388 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-1388

Vulnerability Analysis

This vulnerability is classified under CWE-1333 (Inefficient Regular Expression Complexity). The flaw exists in the merge request endpoint processing logic within GitLab. When a user submits input to this endpoint, it is processed by a regular expression that exhibits catastrophic backtracking behavior when given maliciously crafted input patterns.

The vulnerability is particularly concerning because it can be triggered by unauthenticated users, meaning attackers do not need valid credentials to exploit the flaw. The attack is network-accessible, requires no user interaction, and has low complexity to execute, making it an attractive target for denial of service attacks against GitLab instances.

Root Cause

The root cause of this vulnerability stems from inefficient regular expression patterns used in the merge request processing functionality. When certain input patterns are provided, the regex engine enters an exponential time complexity state due to catastrophic backtracking. This occurs when the regex contains ambiguous patterns that can match the same input in multiple ways, causing the engine to explore an exponentially growing number of possible matches.

Regular expressions vulnerable to ReDoS typically contain:

• Nested quantifiers (e.g., (a+)+)
• Alternation with overlapping patterns
• Groupings that can match empty strings followed by quantifiers

Attack Vector

The attack is executed remotely over the network by sending specially crafted HTTP requests to the vulnerable merge request endpoint. An attacker can construct input strings designed to trigger worst-case regex matching behavior. When the GitLab server processes this malicious input, the CPU becomes consumed by the regex evaluation, causing the service to become unresponsive.

The vulnerability affects the merge request functionality, which is a core feature of GitLab's collaborative code review workflow. A successful attack could prevent legitimate users from creating, viewing, or interacting with merge requests, severely impacting development workflows.

Since no authentication is required, any attacker with network access to a vulnerable GitLab instance can exploit this vulnerability. This includes internet-facing GitLab deployments that allow public access to certain endpoints.

Detection Methods for CVE-2026-1388

Indicators of Compromise

• Unusual CPU spikes on GitLab application servers, particularly in web worker processes
• Increased response times or timeouts for merge request-related API endpoints
• Application logs showing extended processing times for requests to /merge_requests endpoints
• Memory consumption patterns consistent with regex processing loops

Detection Strategies

• Monitor GitLab application server CPU utilization for sustained high usage without corresponding user activity increases
• Implement request timeout monitoring to detect endpoints that consistently exceed normal response times
• Review web server access logs for repeated requests to merge request endpoints from single IP addresses or unusual patterns
• Deploy Web Application Firewall (WAF) rules to detect and block requests containing suspicious regex-triggering patterns

Monitoring Recommendations

• Enable GitLab's built-in request profiling to identify slow endpoint processing
• Configure alerting for CPU utilization thresholds on GitLab application servers
• Monitor request queue depths and worker thread availability
• Implement rate limiting on merge request endpoints to mitigate automated exploitation attempts

How to Mitigate CVE-2026-1388

Immediate Actions Required

• Upgrade GitLab CE/EE to version 18.9.1, 18.8.5, or 18.7.5 depending on your current version branch
• If immediate patching is not possible, implement network-level access controls to restrict access to the vulnerable endpoint
• Enable rate limiting on the affected merge request endpoints to reduce the impact of potential exploitation
• Review access logs for any evidence of exploitation attempts prior to patching

Patch Information

GitLab has released patched versions addressing this vulnerability. Organizations should upgrade to the following versions based on their current deployment:

• Version 18.9.1 for those on the 18.9.x branch
• Version 18.8.5 for those on the 18.8.x branch
• Version 18.7.5 for those on the 18.7.x branch or any version from 9.2 through 18.7.4

Detailed patch information is available in the GitLab Patch Release Notes. Additional technical discussion can be found in the GitLab Issue Discussion and the original HackerOne Vulnerability Report.

Workarounds

• Implement a reverse proxy or WAF rule to filter requests to merge request endpoints containing potentially malicious patterns
• Configure request timeout limits at the web server level to terminate long-running regex operations
• Restrict network access to GitLab instances to trusted IP ranges where possible
• Consider temporarily disabling public access to merge request endpoints if the instance must remain unpatched

# Example nginx rate limiting configuration for merge request endpoints
# Add to your GitLab nginx configuration

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

location ~ ^/.*/-/merge_requests {
    limit_req zone=merge_request_limit burst=20 nodelay;
    proxy_read_timeout 30s;
    proxy_pass http://gitlab-workhorse;
}