CVE-2018-19576
Description
GitLab CE/EE, versions 8.6 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, are vulnerable to an access control issue that allows a Guest user to make changes to or delete their own comments on an issue, after the issue was made Confidential.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE from 8.6 to 11.5 before 11.3.11, 11.4.8, and 11.5.1 allows Guest users to edit or delete their own comments on issues after the issue is made confidential.
Vulnerability
GitLab Community Edition and Enterprise Edition, versions 8.6 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, contain an access control vulnerability. A user with Guest permissions can edit or delete their own comments on an issue, even after that issue has been marked as confidential. The bug resides in the notes controller's authorization check, which fails to re-verify access when a Guest user attempts to modify their existing comment on a confidential issue [1].
Exploitation
An attacker must already be a Guest-level user on a GitLab project (no further authentication or special privileges required). The attacker first creates a comment on a non-confidential issue. If the issue is later made confidential by another user, the Guest can still edit or delete that comment via direct API requests, such as a PUT request to the notes endpoint. The server does not enforce the confidential restriction for the owner of the comment [1].
Impact
A Guest user can alter or remove their own previously posted comments on confidential issues. This may allow the guest to change the information visible to other users (including project members with higher privileges) or to remove evidence of their past statements. Since guests cannot originally view confidential issues, this breaks the intended confidentiality model and could lead to information manipulation or hiding of user activity [1].
Mitigation
The issue is fixed in GitLab CE/EE versions 11.3.11, 11.4.8, and 11.5.1. Users should upgrade to one of these patched releases or later. No workarounds are documented; upgrading is the recommended mitigation [1].
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2- GitLab/CE/EEdescription
- Range: >= 8.6, < 11.3.11 || >= 11.4, < 11.4.8 || >= 11.5, < 11.5.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization re-check when editing or deleting comments on issues that have been made Confidential."
Attack vector
An attacker with Guest role posts a comment on a public issue, then the issue owner marks the issue as Confidential. The attacker replays a PUT or DELETE request to the notes endpoint (e.g., `PUT /sandeep01/test/notes/99078322`) using their own session cookie and the correct note_id and target_id. Because the server does not re-check the user's permission to access the now-confidential issue, the request succeeds and the Guest user can edit or delete their own comment [ref_id=1].
Affected code
The vulnerability is in the NotesController handling PUT and DELETE requests for comments (notes) on issues. The vulnerable endpoints are `PUT /:namespace/:project/notes/:note_id` and `DELETE /:namespace/:project/notes/:note_id`. The controller fails to re-verify the user's access permissions after an issue is made confidential, allowing a Guest user who previously had access to their own comment to continue editing or deleting it.
What the fix does
The advisory does not include a patch diff, but the fix (implemented in GitLab 11.3.11, 11.4.8, and 11.5.1) adds an authorization check that verifies the user's ability to access the parent issue before allowing note modification or deletion. This ensures that when an issue becomes Confidential, Guest users—who lack access to Confidential issues—can no longer edit or delete their comments on that issue [ref_id=1].
Preconditions
- authAttacker must have a Guest role account on the target GitLab project
- inputAttacker must have posted a comment on the issue before it was made Confidential
- configThe issue must be changed to Confidential after the comment was created
- inputAttacker must know the note_id and target_id of the issue and comment
Reproduction
1. As a Guest user, add a comment on any open issue in the project. 2. Have the issue owner change the issue to Confidential. 3. Replay the vulnerable PUT or DELETE request (e.g., `PUT /sandeep01/test/notes/99078322` with `target_type=issue&target_id=13921643¬e%5Bnote%5D=helloasdfghjk`) using the Guest user's session. 4. The comment is edited or deleted despite the issue being Confidential [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- about.gitlab.com/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released/mitrex_refsource_MISC
- gitlab.com/gitlab-org/gitlab-ce/issues/51238mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.