Incorrect Authorization in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions starting from 16.2 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for an attacker to abuse the policy bot to gain access to internal projects.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An external user can abuse the scan execution policy bot in GitLab EE to gain access to internal projects.
Vulnerability
An issue in GitLab EE affects all versions from 16.2 before 16.4.3, all versions from 16.5 before 16.5.3, and all versions from 16.6 before 16.6.1. The scan execution policy bot, introduced to run pipelines, is created as a regular user rather than an external user. This allows an external user to leverage the bot to access internal projects that would otherwise be restricted [1].
Exploitation
An attacker must be an external user with owner-level access to a project in a shared group. The attacker also needs access to a runner (e.g., a cloud VM). The steps involve creating an internal project in one group and a shared project in another group, adding the external user as owner of the shared project, then using the policy bot to clone the internal project via a pipeline [1].
Impact
Successful exploitation allows the external user to gain read access to internal projects, potentially exposing sensitive source code, configuration, or data. The attacker operates with the bot's privileges, which are not limited by the external user's restrictions [1].
Mitigation
GitLab has released fixed versions: 16.4.3, 16.5.3, and 16.6.1. Users should upgrade to these versions or later. No workaround is available for affected versions [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: >=16.2, <16.4.3 || >=16.5, <16.5.3 || >=16.6, <16.6.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Security policy bots are created as regular (non-external) users instead of external users, allowing external attackers to use the bot's CI job token to access internal projects."
Attack vector
An attacker with external user access who is an owner (or maintainer if a bot already exists) of a project can create a scan execution policy that triggers a CI pipeline using a policy bot. The policy bot is created as a regular (non-external) user, so its CI job token grants access to internal projects. The attacker sets up a runner that exfiltrates the `CI_JOB_TOKEN` to an attacker-controlled server, then uses that token to clone internal projects that the external user should not be able to access [ref_id=1].
Affected code
The vulnerability is in the policy bot user creation logic. The file `ee/app/services/security/orchestration/create_bot_service.rb` creates security policy bots without setting the `external` flag, and the `external?` method in `ee/app/models/ee/user.rb` does not account for security policy bots. The fix adds `external: true` to the bot user parameters and overrides `external?` to return `true` for security policy bots [ref_id=1].
What the fix does
The fix makes two changes. First, in `ee/app/services/security/orchestration/create_bot_service.rb`, the `bot_user_params` method now includes `external: true` so that newly created security policy bots are marked as external users. Second, in `ee/app/models/ee/user.rb`, the `external?` method is overridden to return `true` for security policy bots regardless of their stored attribute. This ensures that policy bots inherit the same access restrictions as external users, preventing them from being used to access internal projects [ref_id=1].
Preconditions
- authAttacker must have an external user account on a self-managed GitLab instance with at least Premium subscription
- authAttacker must be an owner (or maintainer if bot already exists) of a project where they can create scan execution policies
- configAttacker must have access to a CI runner they can control to exfiltrate the CI_JOB_TOKEN
- configA target internal project must exist on the same GitLab instance
Reproduction
1. As ADMIN, create an external user, two groups (`internal_group` and `shared_group`), an internal project in `internal_group`, a project in `shared_group`, and add the external user as owner of `shared_group/shared_project`. 2. As EXTERNAL, create a project runner with a shell executor and place a script at `/analyzer` that exfiltrates `CI_JOB_TOKEN` to a collaborator server and sleeps for 3600 seconds. 3. As EXTERNAL, create a file `package.json` in `shared_project`, create a branch `test`, navigate to Security Policies, create a scan execution policy with a schedule rule on the `test` branch and SAST action with empty tags, and merge it. 4. Wait for the scheduled pipeline to run; the CI_JOB_TOKEN will be sent to the collaborator server. 5. Use the stolen token to clone `internal_group/internal_project` via `git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/internal_group/internal_project` [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/2138880mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/425361mitreissue-tracking
News mentions
1- GitLab Security Release: 16.6.1, 16.5.3, 16.4.3GitLab Security Releases · Nov 30, 2023