VYPR
Unrated severityNVD Advisory· Published Nov 4, 2021· Updated Aug 4, 2024

CVE-2021-39895

CVE-2021-39895

Description

In all versions of GitLab CE/EE since version 8.0, an attacker can set the pipeline schedules to be active in a project export so when an unsuspecting owner imports that project, pipelines are active by default on that project. Under specialized conditions, this may lead to information disclosure if the project is imported from an untrusted source.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

In GitLab CE/EE 8.0+, imported projects can have pipeline schedules automatically active, potentially exposing CI/CD variables.

Vulnerability

In all versions of GitLab CE/EE since version 8.0, an attacker can craft a project export where the pipeline schedules are set to be active. When an unsuspecting owner imports this project, the pipeline schedules become active by default without the importer's explicit consent [1]. This affects all GitLab versions from 8.0 up to and including the latest at the time of disclosure.

Exploitation

An attacker with the ability to create a project export can set the pipeline schedules to be active in the export. The attacker then shares this crafted project with a group maintainer or owner (for example, by sending the export file or through a project transfer). When the victim imports the project into their group, the predefined pipeline schedule becomes active. The attacker can set the schedule to run shortly after import, or the victim may inadvertently trigger it by clicking the "Play" button. The scheduled pipeline executes a CI job that can exfiltrate sensitive data via a curl request [1]. The attacker does not need any special privileges beyond the ability to create and export a project; the victim must import the malicious project.

Impact

If the pipeline schedule runs successfully, the CI job executed in the context of the importing group can access group CI/CD variables. These variables may contain personal access tokens, passwords, and other secrets. An attacker can then steal these variables, potentially gaining access to other projects or resources managed by the victim group. This leads to information disclosure and possible privilege escalation within the GitLab instance [1].

Mitigation

GitLab addressed this issue in versions 14.1.3, 14.0.6, and 13.12.10, released on November 4, 2021. Users should upgrade to one of these patched versions or later. As a workaround, after importing a project from an untrusted source, administrators should immediately review and disable any active pipeline schedules. There is no indication that this CVE is listed in CISA's Known Exploited Vulnerabilities catalog.

AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

3

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"Imported pipeline schedules retain their "Active" flag from the project export instead of being forced to inactive, allowing an attacker to pre-configure active scheduled pipelines that execute on import."

Attack vector

An attacker crafts a malicious project export containing an active scheduled pipeline configured with a `.gitlab-ci.yml` that exfiltrates CI/CD variables (e.g., via a `curl` request to an attacker-controlled server) [ref_id=1]. The attacker then tricks a group maintainer or owner into importing this project into their group. Because the pipeline schedule remains active after import, it runs automatically (or can be triggered manually via the "Play" button) and executes the attacker's script, which sends the group's CI/CD variables—including personal access tokens and other secrets—to the attacker [ref_id=1].

Affected code

The issue lies in the project import/export mechanism, specifically in `GitLab::ImportExport::Project::RelationFactory` within the `setup_models` method [ref_id=1]. When a project is imported, pipeline schedules (`Ci::PipelineSchedule`) are restored with their "Active" flag preserved from the export file (`pipeline_schedules.ndjson`), rather than being forced to an inactive state [ref_id=1].

What the fix does

The fix updates `GitLab::ImportExport::Project::RelationFactory` to add a case for `Ci::PipelineSchedule` under `setup_models`, ensuring that imported pipeline schedules are always set to inactive [ref_id=1]. Additionally, the implementation plan includes updating the list of excluded attributes so that the "active" flag from the export file is not preserved during import [ref_id=1]. This prevents an attacker from pre-configuring a schedule to be active in the exported project.

Preconditions

  • authThe victim must be a maintainer or owner of a GitLab group and must import the attacker's crafted project export into that group.
  • inputThe attacker must create a project export with an active scheduled pipeline and a .gitlab-ci.yml that exfiltrates CI/CD variables.
  • configThe victim's group must have CI/CD variables defined (e.g., personal access tokens, passwords) that the attacker aims to steal.

Reproduction

1. Download the crafted project export from the HackerOne attachment (or create your own: create a public project, add a `.gitlab-ci.yml` with a `curl` command referencing a CI/CD variable like `$TEST_VAR`, add an active scheduled pipeline with interval `*/5 * * * *`, and export the project). 2. Create a new GitLab group and add a custom CI/CD variable named `TEST_VAR`. 3. Import the crafted project into the group. 4. Navigate to **CI/CD** → **Schedules** in the imported project; the pipeline schedule will be active. 5. Either wait for the schedule to trigger automatically (within ~5–30 minutes) or click the "Play" button to run it immediately. 6. The pipeline executes the `curl` command, sending the group's CI/CD variable value to the attacker-controlled endpoint [ref_id=1].

Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

3

News mentions

0

No linked articles in our index yet.