CVE-2022-1406
Description
Improper input validation in GitLab CE/EE affecting all versions from 8.12 prior to 14.8.6, all versions from 14.9.0 prior to 14.9.4, and 14.10.0 allows a Developer to read protected Group or Project CI/CD variables by importing a malicious project
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An improper input validation in GitLab CE/EE allows a Developer to read protected CI/CD variables by importing a malicious project.
Vulnerability
An improper input validation vulnerability in GitLab CE/EE affects all versions from 8.12 prior to 14.8.6, all versions from 14.9.0 prior to 14.9.4, and 14.10.0. A user with Developer role in a group can read protected Group or Project CI/CD variables by importing a maliciously crafted project that modifies the merge access level setting in the protected branches import file (tree/project/protected_branches.ndjson). [1]
Exploitation
An attacker must be a Developer (or higher) in a GitLab group that has at least one masked CI/CD variable defined. The attacker first exports any personal project, then modifies the exported archive by editing the tree/project/protected_branches.ndjson file to change the merge_access_levels access level value from 40 (maintainer) to 30 (developer). The attacker then imports this modified project into the target group. This lowers the bar for merging into protected branches, allowing the Developer to merge a merge request that contains a .gitlab-ci.yml job that exfiltrates environment variables (including the masked CI/CD variables) via an HTTP POST to an attacker-controlled server. [1]
Impact
A successful exploit allows the attacker to read masked CI/CD variables belonging to the group or project. These variables may contain secrets such as API tokens, database credentials, or other sensitive data, leading to a compromise of confidentiality and potential lateral movement within the organization. [1]
Mitigation
The vulnerability is fixed in GitLab CE/EE versions 14.8.6, 14.9.4, and 14.10.0. All users are advised to upgrade to one of the fixed versions. No workarounds are documented in the available references. [1]
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- Range: >=8.12, <14.8.6, >=14.9.0, <14.9.4, =14.10.0
- Range: >=14.10.0, <14.10.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing input validation on the `merge_access_levels` field during project import allows a developer to elevate their own merge permissions on protected branches."
Attack vector
An attacker with a developer role in a group can steal masked CI/CD variables by importing a maliciously modified project into that group. The attacker first exports a personal project, then modifies the `tree/project/protected_branches.ndjson` file inside the export archive to change `merge_access_levels` from 40 (maintainer) to 30 (developer) [ref_id=1]. After importing the tampered project, the attacker creates a new branch with a `.gitlab-ci.yml` file that exfiltrates environment variables via curl, creates a merge request, and merges it into the protected branch — now possible because the attacker set themselves as allowed to merge [ref_id=1]. The pipeline run against the protected branch then exposes the masked CI/CD variables to the attacker-controlled endpoint [ref_id=1].
Affected code
The vulnerability lies in the project import functionality, specifically in the handling of the `tree/project/protected_branches.ndjson` file. The `merge_access_levels` value in this file is not validated or reset during import, allowing a maliciously crafted import file to set an access level of 30 (developer) instead of the default 40 (maintainer) [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the expected correct behavior is that the `merge_access_levels` value should always be reset to the default of 40 (maintainer) during project import [ref_id=1]. The fix would involve validating or overriding the imported `merge_access_levels` setting so that a developer-level user cannot elevate their own merge permissions on protected branches through a tampered import file [ref_id=1]. No patch is published in the provided bundle.
Preconditions
- authAttacker must have a Developer role in the target group
- inputAttacker must be able to create and import a project into the target group
- configThe target group must have masked CI/CD variables defined
Reproduction
1. Create two accounts (A and B). Account A creates a group with masked CI/CD group variables. Account B creates a personal project and exports it. 2. Invite account B (developer) to account A's group. 3. Modify the project export archive: edit `tree/project/protected_branches.ndjson` and change `"merge_access_levels":[{"access_level":40}]` to `"merge_access_levels":[{"access_level":30}]`. 4. Account B imports the modified project into account A's group. 5. Account B creates a new branch with a `.gitlab-ci.yml` that runs `export > test.txt` and `curl -X POST --data "$(cat test.txt)"
Generated on May 24, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1406.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/353958mitrex_refsource_MISC
- hackerone.com/reports/1485381mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.