GitLab CE/EE EUVD-2026-36224

The GitLab Service Desk feature must be enabled on the target project - this is a non-default, opt-in feature requiring project maintainer or administrator configuration. The attacker must be able to send email to the project's Service Desk address (which may be discoverable via the project's issue tracker UI or email headers). The attack additionally requires 'certain conditions' to be met, per the vendor description, which aligns with the AC:H CVSS rating; these specific conditions are not further enumerated in available public data and should be referenced in GitLab's internal issue (work item 601330). User interaction is required (UI:R) - a legitimate user must view the affected issue thread for the injected content to have social-engineering impact. There is an unresolved conflict between the description's 'unauthenticated user' language and the CVSS vector's PR:L designation; if PR:L is accurate, the attacker must possess at least Reporter-level access to the GitLab instance, which further limits exposure. No exploitation occurs on instances where Service Desk is not configured.

Real-world risk is constrained by multiple compounding factors. The official CVSS base score of 2.6 reflects AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N - high attack complexity, low privileges required, and user interaction needed for impact materialization, with only a low integrity effect and no confidentiality or availability impact. IMPORTANT CONFLICT: The official CVSS vector designates PR:L (some privileges required), yet the CVE description explicitly states the vulnerability can be triggered by 'an unauthenticated user.' This discrepancy is not resolved by available data and should be verified with the vendor - if PR:N is accurate, the practical attack surface broadens. EPSS data is not provided in this intelligence set. No KEV listing exists, indicating no confirmed widespread active exploitation, though a publicly available exploit on HackerOne elevates the realistic threat posture above theoretical. The AC:H rating aligns with the description's qualifier 'under certain conditions,' suggesting the attack is not reliably reproducible in all deployments. The impact is limited to content integrity - an attacker forging Support Bot messages could enable social engineering or phishing within the platform but cannot directly exfiltrate data or deny service.

An attacker obtains or enumerates the Service Desk email address for a GitLab project, then crafts a reply email whose body contains template substitution sequences targeting GitLab's internal email renderer. When GitLab processes the inbound email reply under the conditions required to trigger the vulnerability, the template engine evaluates the injected tokens and renders forged content attributed to the GitLab Support Bot identity within the issue thread. A victim user viewing the issue subsequently sees a seemingly authoritative Support Bot message containing attacker-controlled content, which could be used for phishing, credential harvesting, or directing users to malicious links. A publicly available exploit exists on HackerOne (report 3685720), confirming the attack is technically reproducible.