CVE-2021-39918
Description
Incorrect Authorization in GitLab EE affecting all versions starting from 11.1 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allows a user to add comments to a vulnerability which cannot be accessed.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE fails to enforce 'Only Project Members' visibility on vulnerability report discussions, allowing unauthorized users to inject comments.
Vulnerability
An incorrect authorization vulnerability in GitLab EE affects versions 11.1 up to 14.3.6, 14.4 up to 14.4.4, and 14.5 up to 14.5.2. The issue occurs in the vulnerability report discussion feature: when the project's Security & Compliance visibility is set to "Only Project Members", the application does not enforce this restriction on comment creation. Users can add comments to vulnerability discussions even if they are not project members, provided they obtain the discussion ID [1].
Exploitation
An attacker needs a valid GitLab account and must know the victim project's discussion ID for a vulnerability report. The attacker first joins a discussion on an issue in the same project (any issue) to observe the request format. Then, they craft a new comment request, changing the in_reply_to_discussion_id parameter to the victim's vulnerability discussion ID. The request is sent using the authenticated session. No special network position or race window is required; the attacker only needs to have any access to the project (e.g., as a guest) to view the project at all [1].
Impact
Successful exploitation allows an unauthorized user to post comments on vulnerability reports that are intended to be visible only to project members. This leads to information disclosure (the attacker may observe or influence discussions about security findings) and undermines the confidentiality of vulnerability handling. The attacker does not gain elevated privileges beyond the ability to inject comments into a restricted discussion [1].
Mitigation
The vulnerability is fixed in GitLab EE versions 14.3.6, 14.4.4, and 14.5.2. Administrators should upgrade to one of these patched versions immediately. No workarounds are documented in the available references, and the issue is not listed on the CISA KEV [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: >=11.1 <14.3.6, >=14.4 <14.4.4, >=14.5 <14.5.2
- Range: >=11.1, <14.3.6
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization check allows any authenticated user to reply to Vulnerability Report discussions using a known discussion_id, bypassing the "Only Project Members" access restriction."
Attack vector
An attacker who is not a project member can post comments on Vulnerability Report discussions by supplying a known `discussion_id` in a reply request [ref_id=1]. The attacker first obtains the `discussion_id` (e.g., by having previously seen the vulnerability report, or by intercepting a victim's request) and then crafts a reply to an issue thread, replacing the `in_reply_to_discussion_id` parameter with the stolen ID [ref_id=1]. The server fails to verify that the user is authorized to access the vulnerability discussion, allowing the unauthorized comment to be posted [ref_id=1].
Affected code
The vulnerability is in the authorization logic for Vulnerability Report discussions in GitLab EE. The issue is tracked in the GitLab issue tracker [ref_id=1] and affects versions 11.1 through 14.3.6, 14.4 through 14.4.4, and 14.5 through 14.5.2. No specific function or file path is named in the advisory.
What the fix does
No patch diff is included in the bundle. The advisory [ref_id=1] states that the expected correct behavior is to "restrict user can't reply on discussion of vulnerability report" when the user is not authorized. The fix would involve adding an authorization check that verifies the commenting user has the required project membership (i.e., the "Only Project Members" setting) before allowing a reply to a Vulnerability Report discussion, regardless of whether the attacker knows the `discussion_id`.
Preconditions
- configThe target project must have Security & Compliance visibility set to 'Only Project Members'
- inputThe attacker must know a valid discussion_id from a Vulnerability Report discussion
- authThe attacker must have a GitLab account and be able to send API requests to the project
Reproduction
1. As victim, create a project, enable SAST in Security & Compliance, upload a PHP file with `<?php eval($_POST['888']);?>`, wait for pipeline to pass, and go to Vulnerability Report. 2. At Vulnerability Report, change a vulnerability status, add a comment, intercept the request, and note the `discussion_id`. 3. As attacker, go to the victim's project, add an issue, start a thread, intercept the reply request, and change the `in_reply_to_discussion_id` to the stolen `discussion_id`. 4. Send the request. 5. As victim, go to Vulnerability Report and observe the attacker's comment [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-39918.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/329916mitrex_refsource_MISC
- hackerone.com/reports/1180043mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.