Incorrect Authorization in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions starting from 13.12 before 16.2.7, all versions starting from 16.3 before 16.3.4. It was possible for an attacker to run pipeline jobs as an arbitrary user via scheduled security scan policies. This was a bypass of CVE-2023-3932 showing additional impact.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE allowed attackers to run pipeline jobs as arbitrary users via scheduled security scan policies, bypassing a previous fix.
Vulnerability
An issue in GitLab EE affecting versions 13.12 before 16.2.7 and 16.3 before 16.3.4 allowed an attacker to run pipeline jobs as an arbitrary user via scheduled security scan policies. This was a bypass of the fix for CVE-2023-3932. The vulnerability stems from two bypass methods: an external user with maintainer access to a project that already has a SAST scan policy configured can add a malicious runner and remove the security bot member, causing future policy pipelines to run as the victim user; and using direct transfer to import a policy project and spoof the merge request that configures the policy [1].
Exploitation
An attacker must be a maintainer in a project where a SAST scan policy already exists (either configured by another user or inherited from a parent group). The attacker can then add a malicious runner to the project and remove the security bot member from the project. This causes subsequent scheduled policy pipelines to execute as the victim user. Alternatively, the attacker can use direct transfer to import a policy project and spoof the merge request that configures the policy, achieving the same effect [1].
Impact
Successful exploitation allows an attacker to run pipeline jobs as an arbitrary user, potentially gaining access to sensitive data, escalating privileges, or performing actions under the victim's identity. The impact is higher than originally assessed for the related CVE-2023-3932 [1].
Mitigation
GitLab has released fixed versions 16.2.7 and 16.3.4, which address this bypass. Users should upgrade to these versions or later. No workaround is available. The fix ensures that policy pipelines are run by a bot user with limited access and that merge history is used instead of spoofable git history [1].
AI Insight generated on May 23, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.12 <16.2.7, >=16.3 <16.3.4
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The security policy pipeline creator falls back to the merge request author when the bot user is removed, allowing an attacker to spoof the MR author via direct transfer and run pipelines as an arbitrary user."
Attack vector
An attacker imports a victim's policy project via direct transfer (group migration) to a separate GitLab instance, spoofing the merge request author to impersonate the victim [ref_id=1]. After importing, the attacker removes the security bot user from the project and registers a malicious runner. When the scheduled scan execution policy triggers, the pipeline runs as the spoofed MR author (the victim), and the attacker's runner exfiltrates the victim's CI_JOB_TOKEN [ref_id=1]. The attacker can then use that token to access the victim's private projects and trigger pipelines on those projects [ref_id=1].
Affected code
The issue affects the security scan policy pipeline execution logic in GitLab EE versions 13.12 through 16.2.7 and 16.3 through 16.3.4 [ref_id=1]. The vulnerable mechanism is the fallback behavior that assigns pipeline creator identity based on the merge request author when the security bot user is absent from the project [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the issue [ref_id=1] describes that the previous fix (CVE-2023-3932) switched from checking git history to merge history and introduced a bot user for policy pipelines. The bypass shows that when the bot user is removed from the project, the system falls back to using the MR author as the pipeline creator, which can be spoofed via direct transfer [ref_id=1]. The expected correct behavior is that policy pipelines should never allow running as other users, regardless of bot user presence or MR author spoofing [ref_id=1].
Preconditions
- authAttacker must be a maintainer on a project with an existing SAST scan policy configured by another user or inherited from a parent group [ref_id=1]
- networkAttacker needs access to a self-hosted GitLab instance with HTTPS configured for direct transfer [ref_id=1]
- configAttacker must have a runner registered with shell executor and the ability to create a malicious /analyzer script [ref_id=1]
- inputAttacker must import the victim's group via direct transfer, spoofing the MR author identity [ref_id=1]
Reproduction
1. Set up a self-hosted GitLab instance with HTTPS and create attacker/victim accounts on GitLab.com. 2. On the attacker instance, create a fake victim user using the victim's email, create a group `spoof` with project `project1`, and configure a scheduled scan execution policy via MR. 3. On GitLab.com as attacker, import the `spoof` group via direct transfer. 4. In the imported project, remove the bot user from project members and add the attacker's malicious runner. 5. Wait for the scheduled policy to trigger; the runner's `/analyzer` script exfiltrates the victim's CI_JOB_TOKEN [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/2147126mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/425304mitreissue-trackingpermissions-required
News mentions
1- GitLab Critical Security Release: 16.3.4 and 16.2.7GitLab Security Releases · Sep 18, 2023