Arbitrary Pipeline Execution as Another User in GitLab CE/EE
A critical vulnerability in GitLab Community Edition and Enterprise Edition allows an attacker, under certain circumstances, to trigger a CI/CD pipeline as an arbitrary user. The issue affects all versions starting from 8.14 prior to 17.1.7, starting from 17.2 prior to 17.2.5, and starting from 17.3 prior to 17.3.2. The flaw results in pipeline execution occurring with the identity and effective permissions of a different user than the attacker, creating a privilege boundary failure in pipeline initiation and execution context. Available reporting does not provide sufficient verified detail about the exact vulnerable component or function to state a precise root-cause classification beyond the arbitrary-user pipeline trigger behavior.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation can allow an attacker to execute pipeline actions with the privileges of another user, potentially including higher-privileged project or administrative contexts depending on the targeted account and project configuration. Because pipelines can access repository contents, CI/CD variables, runners, deployment workflows, and other automation capabilities, exploitation may result in unauthorized code execution within CI environments, access to sensitive data available to the pipeline, modification or interruption of build and deployment processes, and broader compromise of confidentiality, integrity, and availability. Some reporting also notes the ability to perform a pipeline stop action as the impersonated user.
If you can’t patch tonight, do this now.
If immediate patching is not possible, reduce exposure by disabling affected importers where operationally feasible, especially Direct Transfer, GitHub, Bitbucket Server, and Gitea importers in self-managed environments. Restrict account creation and public registration to reduce attacker access, minimize the number of users able to initiate imports or pipelines, and closely monitor pipeline creation, execution, and stop events for anomalous activity or actions attributed to unexpected users. Review CI/CD permissions, runner trust boundaries, and secrets exposure to limit blast radius until upgrades are completed.
Patch, then assume compromise.
Upgrade GitLab CE/EE to a fixed release: 17.1.7 or later in the 17.1 branch, 17.2.5 or later in the 17.2 branch, or 17.3.2 or later in the 17.3 branch. Self-managed deployments running affected versions should prioritize patching immediately. If importer-related exposure is relevant in the environment, adopt the vendor’s updated importer behavior introduced in later releases that uses placeholder mapping and explicit user acceptance for contribution reassignment.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.