CVE-2021-39902
Description
Incorrect Authorization in GitLab CE/EE 13.4 or above allows a user with guest membership in a project to modify the severity of an incident.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE 13.4+ allows guest users to modify incident severity due to incorrect authorization, violating access controls.
Vulnerability
In GitLab Community Edition (CE) and Enterprise Edition (EE) starting from version 13.4, an incorrect authorization vulnerability exists in the incident management feature [1]. The code path responsible for changing incident severity does not properly enforce permission checks, allowing a user with only guest membership in a project to modify the severity level of an incident [1]. The issue affects all versions from 13.4 up to and including the versions prior to fix release [1].
Exploitation
An attacker needs a GitLab account with guest-level access to a target project that has the incident management feature enabled [1]. The attacker must first be able to view an existing incident (or create one, if guest permissions allow incident creation). The vulnerability can be exploited by intercepting and replaying the HTTP request that updates incident severity, even after the user's role is demoted to guest, if the request is captured beforehand [1]. Specifically, an attacker can: (1) gain guest access to a project; (2) capture the severity change request using a proxy tool like Burp Suite; (3) after being demoted (or if already guest), replay the captured request to change the severity [1]. No additional authentication or privileges beyond guest access are required [1].
Impact
Successful exploitation allows an attacker with guest privileges to change the severity of an incident in a project [1]. This violates the intended access control policy, as guest users should only have read-only or minimal permissions and should not be able to modify incident attributes. The impact is limited to information integrity regarding incident severity, as the attacker can set misleading severity levels (e.g., downgrading a critical incident to low) [1]. No disclosure of sensitive data or code execution is achievable through this vulnerability [1].
Mitigation
GitLab fixed this vulnerability in version 14.3.2, 14.2.5, and 14.1.7, released on October 1, 2021 [1]. Users should upgrade their GitLab installation to one of these patched versions or later [1]. There is no workaround available for unpatched versions [1]. The issue is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.4
- Range: >=13.4, <14.2.6
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing server-side authorization check on the incident severity update endpoint allows a replayed request from a guest user to succeed."
Attack vector
An attacker with guest membership in a project can modify the severity of an incident by replaying a previously captured API request. The guest user first creates an incident while they have higher privileges, captures the severity-change request (e.g., via Burp), and is then demoted to Guest. Although the UI blocks the severity change after demotion, the replayed request still succeeds because the server does not re-authorize the action [ref_id=1]. This is an incorrect authorization check [CWE-863].
Affected code
The advisory does not specify exact files or functions. The issue is tracked in GitLab issue #341479 and involves the incident severity feature in GitLab CE/EE 13.4 and above [ref_id=1].
What the fix does
The advisory references a potential fix at issue #341479 note 690495909, but the bundle does not include the patch diff or the final remediation. The fix is expected to enforce server-side authorization checks on the incident severity update endpoint so that a guest user's request is rejected regardless of whether it was captured before demotion [ref_id=1]. No patch content is present in the bundle.
Preconditions
- authAttacker must have guest membership in the target project
- inputAttacker must capture the severity-change HTTP request while they have higher privileges (e.g., Reporter or above)
- configThe project must be running GitLab CE/EE version 13.4 or above
Reproduction
1. Create two accounts on GitLab. Create a group and invite the second account as an Owner. Create a project under the group. 2. From the second account, navigate to Groups -> Projects -> Monitor -> Create Incident, create an incident, and choose a severity. Capture the severity-change request in Burp and send it to Repeater. 3. From the first account, demote the second user to Guest. Refresh the second user's session — the UI now blocks severity changes. 4. Fire the captured request from Repeater. The severity is changed despite the user being a Guest [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-39902.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/341479mitrex_refsource_MISC
- hackerone.com/reports/1341674mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.