CVE-2025-0673: GitLab CE/EE DoS Vulnerability

CVE-2025-0673 Overview

CVE-2025-0673 affects GitLab Community Edition (CE) and Enterprise Edition (EE) across multiple release branches. The flaw allows an unauthenticated attacker to trigger an infinite redirect loop, exhausting server resources and producing a denial of service condition. The issue is classified under CWE-835: Loop with Unreachable Exit Condition.

The vulnerability impacts GitLab versions 17.7 through 17.10.7, 17.11 through 17.11.3, and 18.0 through 18.0.1. GitLab addressed the flaw in versions 17.10.8, 17.11.4, and 18.0.2.

Critical Impact
Unauthenticated attackers can remotely degrade GitLab availability by forcing infinite redirect loops, disrupting source code management and CI/CD pipelines.

Affected Products

GitLab CE/EE versions 17.7 up to (but not including) 17.10.8
GitLab CE/EE versions 17.11 up to (but not including) 17.11.4
GitLab CE/EE versions 18.0 up to (but not including) 18.0.2

Discovery Timeline

2025-06-12 - CVE-2025-0673 published to NVD
2025-08-08 - Last updated in NVD database

Technical Details for CVE-2025-0673

Vulnerability Analysis

The vulnerability is a denial of service condition caused by an infinite redirect loop in GitLab's HTTP handling logic. An attacker reaches the vulnerable endpoint over the network without authentication or user interaction. The server returns successive HTTP redirects that point back through a path the application re-processes, producing unbounded redirection.

The condition aligns with CWE-835, where a loop lacks a reachable exit. Repeated redirect resolution consumes worker threads, network sockets, and memory. Sustained requests against the endpoint can degrade GitLab availability for legitimate users.

The impact is limited to availability. Confidentiality and integrity are not affected, and no privileges are required for exploitation. Further technical context is available in the GitLab Issue Discussion and HackerOne Report #2936949.

Root Cause

The root cause is improper termination of a redirect chain inside GitLab's request handling. Input validation does not detect or break the cyclical redirect condition. The application keeps following or generating redirects until resources are exhausted.

Attack Vector

The attack vector is network-based. An attacker sends crafted HTTP requests to a reachable GitLab instance, requiring no credentials and no user interaction. Repeated requests against the affected endpoint amplify the resource impact and can render the GitLab instance unresponsive.

No verified public proof-of-concept code is available. The vulnerability is described in prose because no validated exploit example has been published.

Detection Methods for CVE-2025-0673

Indicators of Compromise

Spikes in HTTP 3xx redirect responses originating from a single source IP or small set of IPs targeting GitLab endpoints.
Sustained high CPU, memory, or worker thread utilization on GitLab application servers (puma, workhorse) without a corresponding rise in legitimate request volume.
Increased request latency, request timeouts, and 5xx errors reported by upstream load balancers or reverse proxies fronting GitLab.

Detection Strategies

Inspect reverse proxy and GitLab Workhorse access logs for repeated requests to the same path producing chained 301/302/307 responses.
Correlate redirect anomalies with resource exhaustion metrics in application performance monitoring (APM) tooling.
Alert on long-lived HTTP connections and abnormal redirect counts per client over short time windows.

Monitoring Recommendations

Enable verbose logging on GitLab Workhorse and the front-end web server, capturing request paths, response codes, and client identifiers.
Track CPU, memory, and connection pool saturation on GitLab application nodes through Prometheus and Grafana dashboards.
Forward GitLab logs and infrastructure metrics to a centralized SIEM for correlation and alerting on denial of service patterns.

How to Mitigate CVE-2025-0673

Immediate Actions Required

Upgrade GitLab CE/EE to version 17.10.8, 17.11.4, or 18.0.2 depending on the deployed release branch.
Restrict network exposure of GitLab instances to trusted networks where operationally feasible until patching completes.
Place GitLab behind a reverse proxy or web application firewall configured to limit redirect chains and enforce request rate limits.

Patch Information

GitLab released fixed versions 17.10.8, 17.11.4, and 18.0.2. Administrators should apply the upgrade path that matches their current branch. Refer to the GitLab Issue Discussion for remediation details.

Workarounds

Configure upstream proxies to cap the maximum number of redirects served to a client per session.
Apply per-source-IP rate limiting at the load balancer or WAF to throttle abusive request patterns.
Monitor for and block clients producing sustained redirect-loop request signatures until the patch is deployed.

bash

# Example NGINX rate limiting in front of GitLab
http {
    limit_req_zone $binary_remote_addr zone=gitlab_rl:10m rate=20r/s;

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

        location / {
            limit_req zone=gitlab_rl burst=40 nodelay;
            proxy_pass http://gitlab_upstream;
            proxy_redirect off;
        }
    }
}