VYPR
← All advisories
Unrated severityNVD Advisory· Published Jul 10, 2019· Updated Aug 5, 2024

CVE-2018-19575

CVE-2018-19575

Description

GitLab CE/EE, versions 10.1 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 insecure direct object reference issue that allows a user to make comments on a locked issue.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

GitLab CE/EE 10.1–11.5.0 allows any user to comment on locked or confidential issues by manipulating the noteable_id in a POST request.

Vulnerability

GitLab Community Edition and Enterprise Edition, versions 10.1 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 insecure direct object reference (IDOR) issue. A user can bypass the intended restriction that prevents commenting on locked or confidential issues by intercepting a note creation request and altering the noteable_id parameter to reference a locked issue's note ID [1].

Exploitation

An authenticated attacker with the ability to comment on any public issue in the same project can exploit this by first identifying a locked or confidential issue's noteable ID (e.g., by observing a background AJAX request to a URL like /noteable/issue/11023080/notes). The attacker then crafts a POST request to /notes while changing the note%5Bnoteable_id%5D value from a permitted issue's ID to the locked issue's ID. No special privileges or user interaction is required beyond being able to comment on a non-locked issue [1].

Impact

Successful exploitation allows an attacker to post comments on issues that have been locked by project maintainers or are confidential. This leads to unauthorized information disclosure (if the attacker can read the locked issue) and violates the expected access controls, potentially exposing sensitive discussions or enabling further social engineering [1].

Mitigation

GitLab addressed this vulnerability in versions 11.3.11, 11.4.8, and 11.5.1. Users should upgrade to one of these patched releases or later. No workaround is available for unpatched versions. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of the publication date [1].

References
  1. Able to comment on issues even they are locked/confidential (#52523) · Issues · GitLab.org / GitLab FOSS · GitLab

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

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"Missing authorization check on the noteable_id parameter allows users to post comments on issues they do not have permission to access."

Attack vector

An attacker who can comment on a public issue in a project can modify the `note[noteable_id]` parameter in the POST request to point to a locked or confidential issue's noteable ID. The attacker first captures the numeric noteable ID of a locked issue (e.g., by visiting the locked issue page and observing the URL pattern `/noteable/issue/

Affected code

The vulnerability lies in the notes creation endpoint, where the `note[noteable_id]` parameter is not validated against the user's permissions on the target issue. The advisory identifies that the issue is in the note creation logic that accepts a `noteable_id` from the POST data without verifying whether the user is allowed to comment on that specific issue [ref_id=1].

What the fix does

The advisory does not include a patch diff, but the remediation requires adding authorization checks on the `noteable_id` parameter when creating notes. The server must verify that the authenticated user has permission to comment on the specific issue identified by the provided `noteable_id`, rather than only checking permissions on the project or the target issue referenced in the URL [ref_id=1].

Preconditions

  • authAttacker must have an account that can comment on at least one public issue in the same project as the locked/confidential target issue.
  • inputAttacker must know the numeric noteable_id of the locked or confidential issue (obtainable by visiting the issue page or brute-forcing incremental IDs).
  • configThe target issue must be in a project where the attacker can otherwise interact (e.g., public project with guest access).

Reproduction

1. Visit a locked issue (e.g., `https://gitlab.com/gitlab-org/gitlab-ce/issues/46779`) and capture the background request to `https://gitlab.com/gitlab-org/gitlab-ce/noteable/issue/11023080/notes`; note the numeric ID `11023080`. 2. Pick a public issue in the same project where you can comment as a guest, and intercept the POST request to `/gitlab-org/gitlab-ce/notes?target_id=...&target_type=issue`. 3. Change the `note%5Bnoteable_id%5D` value from the public issue's ID to the locked issue's ID (`11023080`). 4. Forward the request; the comment will be posted on the locked issue [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

News mentions

0

No linked articles in our index yet.