CVE-2023-1084
Description
An issue has been discovered in GitLab CE/EE affecting all versions before 15.7.8, all versions starting from 15.8 before 15.8.4, all versions starting from 15.9 before 15.9.2. A malicious project Maintainer may create a Project Access Token with Owner level privileges using a crafted request.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A project Maintainer in GitLab can escalate to Owner by crafting a request to create a Project Access Token with Owner role, affecting versions before 15.7.8, 15.8.0-15.8.3, and 15.9.0-15.9.1.
Vulnerability
In GitLab CE/EE, a vulnerability exists in the project access token creation endpoint. A project Maintainer (who normally cannot assign Owner role to tokens) can bypass authorization checks by sending a crafted request that sets the token's access level to Owner. This affects all versions prior to 15.7.8, all versions from 15.8 before 15.8.4, and all versions from 15.9 before 15.9.2 [1].
Exploitation
An attacker with Maintainer role on a project sends a crafted HTTP POST request to the project's access tokens creation endpoint, specifying an access level of 50 (Owner) instead of the allowed lower levels. This bypasses the authorization check, creating a token with full Owner privileges. The feature requires a GitLab Premium or Ultimate subscription [1].
Impact
Successful exploitation grants the attacker Owner-level privileges on the project, allowing full control: managing members, altering settings, deleting the project, and accessing all project resources [1].
Mitigation
GitLab released fixes in versions 15.7.8, 15.8.4, and 15.9.2 on March 9, 2023. Users should upgrade to these versions or later. No workaround is documented [1].
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: before 15.7.8, 15.8 before 15.8.4, 15.9 before 15.9.2
- Range: >=0.0, <15.7.8
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing server-side authorization check on the access_level parameter when creating Project Access Tokens allows a Maintainer to escalate to Owner privileges."
Attack vector
A malicious project Maintainer sends a crafted POST request to the project's access token settings endpoint, setting `resource_access_token[access_level]=50` (the value for Owner role) in the form body [ref_id=1]. The server fails to enforce that a Maintainer can only create tokens with roles up to Maintainer (access_level 40), allowing the Maintainer to generate a token with Owner-level privileges [ref_id=1]. The attacker can then use this token to perform any action in the project as an Owner.
Affected code
The vulnerability exists in the Project Access Token creation endpoint at `/-/settings/access_tokens` within GitLab CE/EE. The issue is that the server-side controller handling token creation does not properly validate the `resource_access_token[access_level]` parameter against the requesting user's permissions.
What the fix does
The advisory does not include a patch diff, but the expected correct behavior is that the server should restrict the `access_level` parameter based on the requesting user's role [ref_id=1]. A Maintainer should only be permitted to create tokens with roles up to Maintainer, Guest, Reporter, or Developer — never Owner. The fix would involve adding server-side authorization checks to validate that the requested access level does not exceed the creator's own permissions before issuing the token.
Preconditions
- authAttacker must have at least Maintainer role on the target project
- configTarget project must be on a GitLab instance (Premium tier required to verify, but the bug itself is not tier-gated)
- networkAttacker must be able to send a crafted HTTP POST request to the project's access token settings endpoint
- inputAttacker must supply access_level=50 (Owner) in the request body
Reproduction
1. As a Maintainer on a project, send a POST request to `/-/group_name/-/project_name/-/settings/access_tokens` with the body containing `resource_access_token[access_level]=50` and desired token name/expiry/scopes [ref_id=1]. 2. The server returns a new Project Access Token with Owner-level privileges. 3. Use this token to perform any Owner-level action on the project [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.