CVE-2025-2938 Overview
CVE-2025-2938 is a privilege escalation vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw affects all versions from 17.3 before 17.11.5, 18.0 before 18.0.3, and 18.1 before 18.1.1. Authenticated users could gain elevated project privileges by requesting access to projects when role modifications occurred during the approval process. The unintended permission grants resulted from a business logic flaw in how GitLab handled role changes during pending access requests. The issue is tracked under [CWE-840] (Business Logic Errors).
Critical Impact
Authenticated GitLab users could escalate their project privileges by exploiting race conditions and role-modification logic in the project access approval workflow, leading to high impact on confidentiality, integrity, and availability.
Affected Products
- GitLab Community Edition (CE) versions 17.3 through 17.11.4
- GitLab Enterprise Edition (EE) versions 18.0 through 18.0.2
- GitLab CE/EE version 18.1.0
Discovery Timeline
- 2025-06-26 - CVE-2025-2938 published to NVD
- 2025-08-12 - Last updated in NVD database
Technical Details for CVE-2025-2938
Vulnerability Analysis
The vulnerability resides in GitLab's project access request approval workflow. When a user requests access to a project, GitLab queues the request for an authorized maintainer or owner to approve. The approval path assigns a role to the requesting user. The flaw occurs when role modifications take place during the approval process, granting permissions higher than intended. An authenticated attacker with a low-privilege GitLab account could request access to a target project and manipulate the timing or sequence of role changes to receive an elevated role such as Maintainer or Owner. The flaw enables a network-based attack with low complexity and only requires low privileges, with no user interaction beyond standard approval workflows.
Root Cause
The root cause is a business logic error [CWE-840] in the access request approval routine. GitLab did not adequately reconcile concurrent or interleaved role modifications against the role assigned during approval. The result is a state inconsistency that grants the requesting user a higher-privileged role than the approver intended to assign.
Attack Vector
The attack vector is network-based and requires an authenticated GitLab account with the ability to submit access requests. The attacker submits an access request to a project where role modification activity occurs during approval processing. Because the approval flow does not validate the final effective role against the intended role, the user receives elevated privileges. With Maintainer or Owner privileges, the attacker can read confidential source code, push malicious commits, modify CI/CD pipelines, exfiltrate secrets, or pivot through GitLab's runner infrastructure.
No verified proof-of-concept code is publicly available. Technical details are tracked in GitLab Issue #529006 and HackerOne Report #3063091.
Detection Methods for CVE-2025-2938
Indicators of Compromise
- Unexpected role assignments on projects following recent request_access events in GitLab audit logs.
- Members appearing with Maintainer or Owner access who were never explicitly granted those roles by a project administrator.
- Rapid sequence of member_created and member_updated events for the same user within the access approval workflow.
- Unusual CI/CD pipeline modifications or secret variable reads originating from newly added project members.
Detection Strategies
- Query the GitLab audit log API for member_access_granted and member_role_updated events and correlate them with prior access_request events from the same user.
- Compare assigned project roles against expected role baselines derived from group membership policies.
- Alert on any non-administrator account that gains the Maintainer or Owner role on a project within a short window of submitting an access request.
Monitoring Recommendations
- Forward GitLab audit events, Rails production logs, and API access logs to a centralized log platform for correlation and retention.
- Track project membership changes against an approved baseline and flag any divergence for review.
- Monitor CI/CD job activity from recently added project members for unusual secret access, runner usage, or push events to protected branches.
How to Mitigate CVE-2025-2938
Immediate Actions Required
- Upgrade GitLab CE/EE to a fixed version: 17.11.5, 18.0.3, or 18.1.1 or later.
- Audit all project memberships granted since deploying any affected GitLab version and revoke unauthorized elevated roles.
- Rotate any CI/CD secrets, deploy tokens, and access tokens stored in projects where unauthorized role escalation may have occurred.
- Review protected branch and pipeline configurations for unauthorized modifications.
Patch Information
GitLab addressed the vulnerability in versions 17.11.5, 18.0.3, and 18.1.1. Self-managed GitLab administrators should apply the upgrade through standard package management or the official Omnibus update process. GitLab.com is operated by GitLab Inc. and has received the fix on the SaaS platform. Refer to GitLab Issue #529006 for upstream fix details.
Workarounds
- Restrict the ability to request project access by disabling the access request feature on sensitive projects until patching is complete.
- Require manual administrator review of all newly granted project memberships during the exposure window.
- Limit which user accounts can be granted Maintainer or Owner roles through group-level membership policies.
# Verify GitLab version after upgrade
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5
# Disable project access requests via the API for a sensitive project
curl --request PUT --header "PRIVATE-TOKEN: <admin_token>" \
"https://gitlab.example.com/api/v4/projects/<project_id>?request_access_enabled=false"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


