CVE-2025-1754: GitLab Auth Bypass Vulnerability

CVE-2025-1754 Overview

CVE-2025-1754 affects GitLab Community Edition (CE) and Enterprise Edition (EE) across versions 17.2 through 17.11.4, 18.0 through 18.0.2, and 18.1.0. The flaw allows unauthenticated attackers to upload arbitrary files to public projects by sending crafted API requests. The underlying weakness is classified as [CWE-306] Missing Authentication for Critical Function. Exploitation can lead to resource abuse and unauthorized content storage on affected GitLab instances.

Critical Impact
Unauthenticated attackers can upload arbitrary files to public GitLab projects over the network, enabling storage abuse and hosting of unauthorized content on trusted infrastructure.

Affected Products

GitLab CE/EE versions 17.2 up to but not including 17.11.5
GitLab CE/EE versions 18.0 up to but not including 18.0.3
GitLab CE/EE version 18.1.0 (fixed in 18.1.1)

Discovery Timeline

2025-06-26 - CVE-2025-1754 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-1754

Vulnerability Analysis

The vulnerability resides in a GitLab API endpoint that accepts file uploads tied to public projects. The endpoint fails to enforce authentication before processing upload requests. Attackers can therefore submit crafted HTTP requests and persist arbitrary file content on the target GitLab instance without providing credentials.

The issue is scoped to public projects, which are reachable by anonymous users by design. Because GitLab treats these upload paths as low-trust, integrity is impacted while confidentiality and availability remain intact. The result is unauthorized content storage that consumes disk, bandwidth, and object storage quotas.

Root Cause

The root cause is missing authentication on a file upload API path, mapped to [CWE-306]. GitLab did not require an authenticated session or valid token before writing user-supplied file data associated with public projects. This authentication gap turns a project-scoped feature into an open upload sink.

Attack Vector

Exploitation is remote and network-based. An attacker sends crafted API requests to the vulnerable upload endpoint of a reachable GitLab instance. No user interaction and no prior authentication are required. Attackers can automate uploads to inflate storage, seed malicious payloads for later reference, or abuse the GitLab domain for content hosting.

Technical details are documented in the GitLab Issue Report and the HackerOne Security Report.

Detection Methods for CVE-2025-1754

Indicators of Compromise

Unauthenticated HTTP requests to GitLab upload API endpoints originating from unexpected source IP addresses.
Sudden growth in storage consumption on public projects without corresponding authenticated user activity in audit logs.
Files stored under public project uploads that do not match any commit, issue, or merge request created by an authenticated user.

Detection Strategies

Correlate GitLab production_json.log and api_json.log entries for upload requests with a null or anonymous user_id field.
Alert on high-volume POST requests to upload endpoints from a single client IP within short time windows.
Baseline normal upload traffic per public project and flag statistical deviations for review.

Monitoring Recommendations

Forward GitLab application, API, and audit logs to a central analytics platform for anonymous upload correlation.
Monitor object storage and filesystem usage on GitLab nodes for unexpected growth patterns.
Track outbound reputation for any URLs pointing to /uploads/ paths on the GitLab domain to detect abuse hosting.

How to Mitigate CVE-2025-1754

Immediate Actions Required

Upgrade GitLab CE/EE to version 17.11.5, 18.0.3, or 18.1.1 or later as appropriate for the deployed branch.
Review public projects for unexpected files uploaded during the exposure window and remove unauthorized content.
Rotate any secrets or tokens that may have been referenced in uploaded content on affected instances.

Patch Information

GitLab addressed the flaw in versions 17.11.5, 18.0.3, and 18.1.1. Administrators running self-managed GitLab should apply the vendor-provided packages for their platform. GitLab.com SaaS tenants receive fixes centrally. Refer to the GitLab Issue Report for advisory details.

Workarounds

Restrict network access to the GitLab API from untrusted networks using firewall rules or a reverse proxy allowlist until the patch is applied.
Temporarily convert non-essential public projects to internal or private visibility to reduce the attack surface.
Enforce Web Application Firewall (WAF) rules that block unauthenticated POST requests to GitLab upload endpoints.

bash

# Configuration example: verify GitLab version after upgrade
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5

# Example NGINX rule to block anonymous uploads at the edge
location ~* /api/v4/.*/uploads {
    if ($http_authorization = "") { return 401; }
    if ($cookie__gitlab_session = "") { return 401; }
    proxy_pass http://gitlab_backend;
}