Incorrect Authorization in GitLab
Description
Incorrect authorization checks in GitLab CE/EE from all versions starting from 8.13 before 16.5.6, all versions starting from 16.6 before 16.6.4, all versions starting from 16.7 before 16.7.2, allows a user to abuse slack/mattermost integrations to execute slash commands as another user.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Incorrect authorization in GitLab CE/EE allows an attacker to execute slash commands as another user via Slack/Mattermost integrations.
Vulnerability
An incorrect authorization check exists in GitLab CE/EE versions 8.13 through 16.5.5, 16.6.0 through 16.6.3, and 16.7.0 through 16.7.1. The flaw resides in the slash command integration for Slack and Mattermost. GitLab verifies the integration token but does not correlate that verification with the user identification step, which uses team_id and user_id parameters from the external workspace [1]. This allows a user to impersonate another user when they know the victim's team_id and user_id.
Exploitation
An attacker must know the victim's team_id and user_id within the same Slack or Mattermost workspace that is integrated with a GitLab project. No additional authentication is required beyond possessing these identifiers. The attacker can then craft a slash command request with the victim's team_id and user_id, bypassing the intended authorization. The integration token is still validated, but the user identity is not tied to that token, enabling impersonation [1].
Impact
Successful exploitation allows the attacker to execute any slash command as the victim, including ChatOps jobs. This can lead to unauthorized actions within the GitLab project, such as running CI/CD pipelines, modifying project settings, or accessing sensitive information, depending on the victim's permissions.
Mitigation
GitLab has addressed this vulnerability in versions 16.5.6, 16.6.4, and 16.7.2. Users should upgrade to these or later versions immediately. No workaround is available for unpatched instances [1].
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=8.13, <16.5.6; >=16.6, <16.6.4; >=16.7, <16.7.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing correlation between integration token verification and user identity lookup allows an attacker to impersonate another user by supplying their `team_id` and `user_id`."
Attack vector
An attacker who knows a victim's Slack (or Mattermost) `team_id` and `user_id` can impersonate that victim when triggering slash commands [ref_id=1]. The attacker first creates a project, configures a Mattermost slash command integration with a known token, and adds the victim as a Maintainer [ref_id=1]. The attacker then sends a POST request to the trigger endpoint with the known token, the victim's `team_id` and `user_id`, and arbitrary command text [ref_id=1]. Because GitLab does not correlate the token verification with the user identification, the slash command executes under the victim's identity [ref_id=1].
Affected code
The vulnerability lies in the slash command integration endpoint at `lib/api/integrations.rb` (line 208) and the user identification logic in `app/models/integrations/base_slash_commands.rb` (line 47) [ref_id=1]. GitLab verifies the integration token in one step but identifies the current user via `team_id` and `user_id` parameters in a separate, non-correlated step [ref_id=1].
What the fix does
The advisory does not include a published patch diff, but the issue was addressed in GitLab versions 16.5.6, 16.6.4, and 16.7.2 [ref_id=1]. The fix would need to ensure that the user identity derived from `team_id` and `user_id` is validated against the integration's token, preventing impersonation [ref_id=1]. No further remediation details are provided in the available references.
Preconditions
- inputAttacker must know the victim's Slack/Mattermost team_id and user_id
- configAttacker must create a project and configure a slash command integration with a known token
- configVictim must be added as a Maintainer to the attacker's project
- networkNetwork access to the GitLab API endpoint for triggering slash commands
Reproduction
1. As victim: create a project, integrate Slack, invite attacker to the Slack workspace. 2. As attacker: join the Slack workspace, view victim's profile URL to extract `team_id` (starts with `T`) and `user_id` (starts with `U`). 3. Create a new project, add `.gitlab-ci.yml` with a test job, add victim as Maintainer. 4. Configure Mattermost slash commands with token `abcdef`. 5. Send: `curl -X POST https://gitlab.com/api/v4/projects/<PROJECT_ID>/services/mattermost_slash_commands/trigger --data 'token=abcdef&user_id=<VICTIM_USER_ID>&team_id=<VICTIM_TEAM_ID>&text=run test date'`. 6. Observe pipeline triggered as victim [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/2188868mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/427154mitreissue-trackingpermissions-required
News mentions
1- GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6GitLab Security Releases · Jan 11, 2024