Incorrect User Management in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions starting from 13.12 before 16.0.8, all versions starting from 16.1 before 16.1.3, all versions starting from 16.2 before 16.2.2. It was possible for an attacker to run pipeline jobs as an arbitrary user via scheduled security scan policies.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE allowed attackers to run pipeline jobs as an arbitrary user via scheduled security scan policies by manipulating policy.yml commits.
Vulnerability
An issue in GitLab EE affects versions 13.12 through 16.0.7, 16.1.0 through 16.1.2, and 16.2.0 through 16.2.1. The vulnerability allows an attacker to run pipeline jobs as an arbitrary user via scheduled security scan policies. By pushing a commit to the policy.yml file with a modified Git user configuration (e.g., git config --global user.name "victim"), the attacker causes a pipeline to trigger under the victim's identity. This is possible because the pipeline author is determined by the last committer of the policy file.[1]
Exploitation
To exploit, the attacker needs a group where the victim is a member and must register a self-hosted runner with shell executor. The attacker creates a custom analyzer file at the root (/analyzer) containing arbitrary shell commands. After setting the Git user to the victim's username, the attacker pushes a change to policy.yml. The runner picks up the job and executes the analyzer script as the victim user, allowing the attacker to run arbitrary commands in the victim's pipeline context.[1]
Impact
Successful exploitation gives the attacker access to the victim's CI_JOB_TOKEN, enabling access to the victim's private repositories, member-only projects, container registry, and other resources accessible by the token. No user interaction from the victim is required; only the victim's GitLab username and the name of a private project are needed.[1]
Mitigation
The vulnerability is fixed in GitLab EE versions 16.0.8, 16.1.3, and 16.2.2. Users should upgrade to these versions or later. No workarounds are available; upgrading is the only mitigation.[1]
AI Insight generated on May 25, 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.0.8, >=16.1 <16.1.3, >=16.2 <16.2.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Scheduled scan execution policies attribute the triggered pipeline to the last committer of the policy.yml file, allowing an attacker to forge the Git author name to impersonate any user."
Attack vector
An attacker who has at least Developer access to a group's security policy project can modify the `policy.yml` file with a forged Git author name matching a victim's username. When a scheduled scan execution policy triggers a pipeline (e.g., every 16 minutes), GitLab uses the last committer of `policy.yml` as the pipeline author. The attacker can then run pipeline jobs as the victim, gaining access to the victim's `CI_JOB_TOKEN`, which can be used to clone the victim's private or members-only repositories. The attacker can execute arbitrary code by placing a custom `analyzer` script at `/analyzer` on a self-hosted runner, which the SAST scan job will invoke [ref_id=1].
Affected code
The vulnerability lies in the scan execution policy mechanism, specifically in how scheduled security scan pipelines determine the pipeline author. The issue is that the pipeline triggered by a scheduled scan execution policy uses the last committer of the `policy.yml` file (in the `-security-policy-project`) as the pipeline author, rather than the system or the policy owner. No specific function or file path is identified in the advisory beyond the policy.yml and the security policy project flow [ref_id=1].
What the fix does
The advisory does not include a published patch diff. However, the remediation guidance implied by the issue is that GitLab should not use the last committer of the `policy.yml` file as the pipeline author for scheduled scan execution policies. Instead, the pipeline should be attributed to the policy owner or a system user, preventing an attacker from impersonating arbitrary users by forging the Git author name in commits to the security policy project [ref_id=1].
Preconditions
- authAttacker must have at least Developer role in a group with an active Ultimate trial (to enable security policies)
- configAttacker must have a self-hosted runner registered at the group level with shell executor and untagged job support
- inputAttacker must know the victim's GitLab username and the name of a private/members-only project belonging to the victim
- authVictim must be added as an Owner of the attacker's group (to allow the attacker to later impersonate them)
- configThe target project must have a working .gitlab-ci.yml, disabled shared runners, and a package.json file (for SAST scan to run)
Reproduction
1. As attacker, create a group, add victim as Owner, register a group-level self-hosted runner (shell executor, untagged), and create a file `/analyzer` containing `#!/bin/bash\ngit clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/
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/2057633mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/417594mitreissue-tracking
News mentions
2- GitLab Critical Security Release: 16.3.4 and 16.2.7GitLab Security Releases · Sep 18, 2023
- GitLab Security Release: 16.2.2, 16.1.3, and 16.0.8GitLab Security Releases · Aug 1, 2023