Exposure of Private Personal Information to an Unauthorized Actor in GitLab
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1, which allows an attacker to leak the email address of a user who created a service desk issue.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE allows guest users to leak service desk issue creator email via API endpoint.
Vulnerability
An information disclosure vulnerability exists in GitLab CE/EE affecting versions 13.7 through 15.11.10, 16.0 through 16.0.6, and 16.1 before 16.1.1. The GET /api/v4/projects/{project_id}/issues?iids[]={issue_id} endpoint exposes the service_desk_reply_to field, which contains the email address of the user who created a service desk issue, even to users with only Guest role on the project [1].
Exploitation
An attacker with Guest role on a project can access the API endpoint by providing the project ID and the issue ID. No additional authentication or special privileges are required beyond the Guest role. The attacker simply calls the endpoint and reads the service_desk_reply_to field in the JSON response [1].
Impact
Successful exploitation allows the attacker to leak the private email address of the user who created the service desk issue. This violates the intended privacy controls that restrict email visibility to users with Reporter role or higher. The compromise is limited to information disclosure (Confidentiality impact) and does not affect Integrity or Availability [1].
Mitigation
The vulnerability is fixed in GitLab versions 15.11.10, 16.0.6, and 16.1.1. Users should upgrade to one of these patched versions. There is no known workaround for unpatched versions. The fix ensures that the service_desk_reply_to field is not exposed to users without appropriate permissions [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
3- Range: >=13.7, <15.11.10; >=16.0, <16.0.6; >=16.1, <16.1.1
- Range: 13.7
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing access control check on the `service_desk_reply_to` field in the issues API endpoint allows users with only Guest role to see the private email address of a Service Desk issue creator."
Attack vector
An attacker with Guest-level access to a project that has Service Desk enabled can leak the private email address of a Service Desk issue creator. The attacker first ensures a Service Desk issue exists (by sending an email to the project's Service Desk address), then makes an authenticated API call to `GET /api/v4/projects/{project_id}/issues` using their own API token. The response includes the `service_desk_reply_to` field containing the sender's email address, which should have been redacted for users without at least the Reporter role [ref_id=1].
Affected code
The vulnerability is in the REST API endpoint `/api/v4/projects/{project_id}/issues` which returns the `service_desk_reply_to` field without checking the user's role. The advisory does not specify the exact file path, but the issue is that the API response includes the `service_desk_reply_to` field for all authenticated users regardless of their project role [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the fix would need to enforce the same access control check on the `service_desk_reply_to` field in the REST API that already exists for the web UI. GitLab had previously introduced redaction of Service Desk email addresses in the UI for users below the Reporter role (in version 15.9), but the API endpoint at `/api/v4/projects/{project_id}/issues` was not updated with the same restriction [ref_id=1]. The remediation ensures that the `service_desk_reply_to` field is only exposed to users with at least the Reporter role on the project.
Preconditions
- configThe target project must have Service Desk enabled
- authThe attacker must have at least Guest role on the project
- inputA Service Desk issue must exist (created by sending an email to the project's Service Desk address)
- authThe attacker must have a valid API token for the GitLab instance
Reproduction
1. As user A, create a project and enable Service Desk in Settings > General > Service Desk. Note the Service Desk email address (e.g., `project-issue@example.com`). 2. Invite user B to the project with the **Guest** role. 3. Send an email to the Service Desk email address from step 1 — this creates a new Service Desk issue. 4. As user B, generate a personal API access token. 5. Run: `curl -sk -H "PRIVATE-TOKEN: USER_B_TOKEN" http://your-instance.com/api/v4/projects/:ID/issues` 6. Observe that the response includes the `service_desk_reply_to` field containing the email address of the user who sent the email in step 3, which should have been redacted [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/1933829mitretechnical-descriptionexploit
- gitlab.com/gitlab-org/gitlab/-/issues/405150mitreissue-tracking
News mentions
1- GitLab Security Release: 16.1.1, 16.0.6, and 15.11.10GitLab Security Releases · Jun 29, 2023