GitLab fork merge request pipelines and secret safety

A merge request from a fork normally runs a pipeline in the fork, using the fork's resources and variables. A parent project member can choose to run it in the parent instead, which uses the parent's runners, variables and the member's permissions. Review the changes before you do, because the code may try to steal secrets.

The two modes

GitLab's documentation explains:

• Fork pipelines run in the fork project and use its CI/CD configuration, resources and variables.
• Parent pipelines can be started by a parent project member. They use the parent's settings, runners and variables, and the permissions of whoever triggers them.

The second mode is useful, since contributors cannot test against your real runners otherwise. It is also where risk sits.

What the docs warn about

Fork merge requests can contain malicious code that tries to steal secrets in the parent project. So reviewers should read the changes first. The variables documentation adds that reviewers should never trigger a pipeline containing malicious code, because it can compromise masked and protected variables.

GitLab shows a warning that must be accepted before the pipeline runs. It does not appear if the pipeline is triggered through the API or the /rebase quick action. So an innocent looking rebase command can start a run without the prompt. Treat it with the same caution.

What helps

• Protected variables and runners. Merge request pipelines from forks cannot access protected variables or protected runners, per the docs. That is a strong reason to mark secrets protected. See masked versus protected.
• Admin switch. Administrators can block the parent project mode with the ci_allow_fork_pipelines_to_run_in_parent_project setting in the projects API.
• Review the CI file. A change to .gitlab-ci.yml is the highest risk item.

A review routine

Before running a fork pipeline in the parent:

1. Read changes to .gitlab-ci.yml and any file it includes.
2. Read scripts that CI calls.
3. Check dependency manifests for new or odd packages, and lifecycle scripts.
4. Look for anything that prints environment variables, or sends data to an external host.
5. Only then run it.

If you cannot review it in a few minutes, ask the contributor to split it up.

A note on merge request pipelines

GitLab says merge request pipelines run on the contents of the source branch only and ignore the target branch. To test the result of combining them, use merged results pipelines. This matters for security checks, since a scan of the source branch alone says little about what the target will look like after the merge.

You can run a job only in merge request pipelines with a rule on CI_PIPELINE_SOURCE equal to merge_request_event. Rules inside included files do not satisfy this, so define it directly in .gitlab-ci.yml.

Safeguard policies and gates can be one of the checks on a merge request. The free scan at gold.safeguard.sh/scan can review a dependency change before you run it.

Quick check

Sources

• Merge request pipelines
• GitLab CI/CD variables

Last reviewed: 19 October 2026.