GitLab Group 2FA Bypass (CVE-2025-0605): Anatomy of a Subtle Access Control Flaw
Introduction
If you enforce two-factor authentication (2FA) across your GitLab groups, you expect every user to pass a second factor before they touch a repository. CVE-2025-0605 broke that expectation. Users could still push code or clone repositories without ever passing a second authentication factor, and this affected thousands of organizations that rely on GitLab's group access controls to enforce strong authentication. This post covers the technical root of the vulnerability, its real-world impact, and GitLab's rapid patch response.
About GitLab: GitLab provides integrated source control, CI/CD, and project management to over 100,000 organizations worldwide. Enterprise and open-source communities widely trust its security and compliance features, so an authentication flaw in the platform is a serious concern.
Technical Information
CVE-2025-0605 is a classic case of authentication enforced inconsistently across different access vectors. When a GitLab group is configured to require 2FA, every user should complete a second authentication step before accessing any group resource. GitLab enforced this correctly in the web interface, but the enforcement broke down at the protocol level.
Vulnerability Mechanism
The flaw is in the backend logic that handles Git protocol operations (e.g., git clone, git push). When a user authenticated through the Git CLI with a username and password, the backend did not check whether that user had completed 2FA enrollment, even when the group policy required it. Any user with valid credentials and sufficient group permissions (such as Developer or higher) could therefore perform Git operations on repositories in 2FA-enforced groups and skip the 2FA requirement entirely.
The web interface did not have this gap, because it enforced the 2FA check correctly. That inconsistency let attackers or insiders with valid credentials sidestep group security policies with standard Git tooling.
Attack Vector Example
Suppose a group mandates 2FA, and a user who has not configured 2FA tries to open a repository in the web UI. GitLab blocks them and prompts them to enroll in 2FA. The same user can still run:
git clone https://gitlab.example.com/group/project.git
At the prompt, they enter their username and password. The operation succeeds without 2FA, and they get the repository contents. git push and other Git operations work the same way, provided the user has the necessary permissions.
Root Cause
The authentication logic for Git protocol endpoints either lacked a 2FA check or implemented it improperly. Outside the web interface, the backend did not consistently enforce group-level 2FA requirements, and anyone with valid credentials and group access could exploit that gap.
CWE Classification:
- CWE-1390: Weak Authentication
- CWE-287: Improper Authentication
Patch Information
GitLab 18.0.1, the release that fixes CVE-2025-0605 on the 18.0 line, also addressed several other critical vulnerabilities:
- Large blob endpoint. Authenticated attackers could use this endpoint to exhaust server resources and cause denial-of-service conditions. The patch added proper access controls and resource management to prevent that.
- XPath validation in SAML responses. Improper validation let modified SAML responses bypass two-factor authentication requirements under specific conditions. The fix strengthened validation so that only properly authenticated responses are processed.
- Discord webhook integrations. An issue here could cause denial-of-service attacks. The patch added stricter input validation and rate limiting.
- Kubernetes integrations. Unbounded cluster tokens could lead to denial-of-service scenarios. The update enforces limits on token generation and adds validation checks to prevent abuse.
- Note positions. Unvalidated note positions could be exploited to cause denial-of-service conditions. The patch now validates note positions thoroughly, so only legitimate inputs are processed.
Patch source: GitLab 18.0.1 Patch Release
Affected Systems and Versions
CVE-2025-0605 affects the following GitLab versions:
- GitLab CE/EE 16.8 up to (but not including) 17.10.7
- GitLab CE/EE 17.11.0 up to (but not including) 17.11.3
- GitLab CE/EE 18.0.0 (fixed in 18.0.1)
Any group configured to require 2FA is vulnerable if it runs on one of these versions, regardless of deployment method (self-hosted, cloud, etc.).
Vendor Security History
GitLab has a strong record of transparent security practices, including a public bug bounty program and regular security releases. Its response to CVE-2025-0605 was fast, with patches released within a day of disclosure. Authentication and access control issues have recurred in GitLab's history, though (e.g., CVE-2024-12093). That pattern shows how complex a platform with this many features is to secure, and that the work is ongoing.
References
- NVD entry for CVE-2025-0605
- Official CVE entry
- GitLab Issue #514204
- HackerOne Report #2919391
- GitLab 18.0.1 Patch Release
Source: This report was created using AI
If you have suggestions for improvement or feedback, please email us at [email protected]
