CVE-2026-0958: GitLab CE/EE DoS Vulnerability

CVE-2026-0958 Overview

A denial of service vulnerability has been identified in GitLab CE/EE that allows unauthenticated attackers to exhaust system resources by bypassing JSON validation middleware limits. This vulnerability affects all GitLab versions from 18.4 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4. The flaw enables remote attackers to cause significant service disruption through memory or CPU exhaustion without requiring any authentication.

Critical Impact
Unauthenticated remote attackers can cause complete denial of service on GitLab instances by exploiting a flaw in JSON validation middleware, potentially disrupting critical development and CI/CD operations.

Affected Products

GitLab CE/EE versions 18.4 to 18.6.5 (fixed in 18.6.6)
GitLab CE/EE versions 18.7 to 18.7.3 (fixed in 18.7.4)
GitLab CE/EE versions 18.8 to 18.8.3 (fixed in 18.8.4)

Discovery Timeline

2026-02-11 - CVE CVE-2026-0958 published to NVD
2026-02-11 - Last updated in NVD database

Technical Details for CVE-2026-0958

Vulnerability Analysis

This vulnerability is classified under CWE-436 (Interpretation Conflict), which occurs when multiple systems or components interpret the same input differently, creating exploitable inconsistencies. In this case, the JSON validation middleware in GitLab CE/EE contains a flaw that allows attackers to craft requests that bypass intended resource consumption limits.

The attack can be executed remotely over the network without requiring any user authentication or interaction. When successfully exploited, the vulnerability leads to resource exhaustion—either memory or CPU—which can render the GitLab instance unresponsive or completely unavailable to legitimate users.

Root Cause

The root cause lies in a middleware interpretation conflict where JSON validation checks fail to properly enforce resource limits under certain conditions. Attackers can craft specially malformed or oversized JSON payloads that bypass the validation layer's protective limits, allowing the server to process requests that consume excessive system resources. This interpretation conflict between the validation middleware and downstream processing components creates an exploitable gap in the security controls.

Attack Vector

The attack is executed remotely over the network (Network attack vector) and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending specially crafted HTTP requests containing malicious JSON payloads to a vulnerable GitLab instance. The crafted payloads are designed to bypass the JSON validation middleware's size and complexity limits, causing the server to allocate excessive memory or consume significant CPU cycles processing the malformed input.

The vulnerability mechanism involves crafting JSON requests that exploit the interpretation conflict in the validation middleware. When the middleware fails to properly validate and limit resource consumption for certain payload structures, the server processes these requests without appropriate safeguards, leading to memory exhaustion or CPU starvation. For detailed technical information, refer to the GitLab Issue Discussion and the HackerOne Security Report.

Detection Methods for CVE-2026-0958

Indicators of Compromise

Abnormally high memory consumption on GitLab application servers without corresponding increase in legitimate user activity
Elevated CPU utilization patterns associated with JSON parsing operations
Unusual volume of large or malformed HTTP requests targeting GitLab API endpoints
GitLab service crashes or unresponsiveness coinciding with specific request patterns

Detection Strategies

Monitor GitLab application logs for repeated large JSON payload submissions from single IP addresses or unusual sources
Implement network-level detection for HTTP requests with abnormally large Content-Length headers targeting GitLab endpoints
Deploy application performance monitoring to detect sudden spikes in memory or CPU usage correlated with API requests
Review web server access logs for patterns of requests that precede service degradation

Monitoring Recommendations

Configure alerting thresholds for GitLab server memory and CPU utilization with rapid response escalation
Implement rate limiting at the load balancer or WAF level for requests to GitLab API endpoints
Enable detailed logging for JSON parsing operations to identify exploitation attempts
Monitor for service availability using health checks with short polling intervals during the patching window

How to Mitigate CVE-2026-0958

Immediate Actions Required

Upgrade GitLab CE/EE immediately to the patched versions: 18.6.6, 18.7.4, or 18.8.4 depending on your current version track
Review GitLab server logs for any indicators of prior exploitation attempts
Implement temporary rate limiting on external-facing GitLab endpoints if immediate patching is not possible
Consider temporarily restricting access to GitLab instances from untrusted networks until patches are applied

Patch Information

GitLab has released security patches addressing this vulnerability. Users should upgrade to the following versions:

Version 18.6.6 for users on the 18.6.x release track
Version 18.7.4 for users on the 18.7.x release track
Version 18.8.4 for users on the 18.8.x release track

Detailed patch information is available in the GitLab Patch Release Update.

Workarounds

Deploy a Web Application Firewall (WAF) rule to limit JSON payload sizes and enforce strict content-type validation
Implement network-level access controls to restrict GitLab access to trusted IP ranges where feasible
Configure reverse proxy or load balancer to impose request body size limits and connection rate limiting
Monitor and automatically block IP addresses exhibiting suspicious request patterns targeting GitLab endpoints

bash

# Example nginx rate limiting configuration
# Add to GitLab nginx configuration
limit_req_zone $binary_remote_addr zone=gitlab_api:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=gitlab_conn:10m;

# Apply to GitLab location blocks
location /api/ {
    limit_req zone=gitlab_api burst=20 nodelay;
    limit_conn gitlab_conn 10;
    client_max_body_size 10m;
    # ... existing configuration
}