EUVD-2026-98222
GHSA-4jhf-7f73-gc68
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as Developer-role user
-
DeliveryCraft unauthorized downstream pipeline request
-
ExploitBypass protected-branch authorization check
-
ExecutionExecute CI/CD pipeline on protected branch
-
ImpactAccess protected variables and alter builds
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated account with at least Developer role on a target GitLab project (PR:L); it is not exploitable by anonymous/unauthenticated users. The flaw lies specifically in the downstream (multi-project/child) pipeline creation service and only manifests 'under certain conditions,' so it depends on projects that use downstream pipelines together with protected-branch restrictions rather than any default single-pipeline setup. Limiting factors: valid Developer credentials needed, affected version window (18.7 before 19.2.8, 19.3 before 19.3.5, 19.4 before 19.4.2), and the non-universal conditional nature of the downstream-pipeline code path; patched instances (19.2.8/19.3.5/19.4.2+) are not affected. |
| Impact | This is a genuine prioritization candidate but not a top-tier internet-wide emergency. The vendor CVSS of 8.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N) reflects a network-reachable, low-complexity authorization bypass that requires only Developer-role privileges (PR:L) and no user interaction, with a scope change (S:C) because a Developer can affect protected-branch CI/CD resources outside their authorized boundary. Impact is high integrity (I:H - unauthorized pipeline execution on protected branches can alter builds/deployments), low confidentiality (C:L - exposure of protected CI/CD variables/secrets), and no availability impact (A:N). A public exploit reference exists (HackerOne #3853866), raising practical risk above a theoretical finding. However, exploitation is gated by two real limiters that temper the raw score: an attacker must already hold a legitimate authenticated Developer account on a target project, and the description explicitly says the flaw only triggers 'under certain conditions' in downstream (multi-project/child) pipeline creation - so it is not a universal default-config bypass. No EPSS score was provided and the issue is NOT listed in CISA KEV, so there is no evidence of active exploitation - the signal is 'public exploit code exists,' which is distinct from in-the-wild use. Note a mild conflict worth verifying: vendor sets AC:L, yet the 'under certain conditions' language suggests non-trivial preconditions that could justify higher complexity. |
| Exploit ScenarioDerived | A user granted only Developer role on a GitLab project (or an attacker who has compromised such an account) crafts a downstream/child pipeline request that the downstream pipeline creation service fails to authorize correctly, letting them run a CI/CD pipeline against a protected branch they should not be able to execute. This lets them run pipeline jobs in the protected-branch context - accessing protected CI/CD variables and influencing build/deploy integrity. A public exploit writeup exists (HackerOne report #3853866), lowering the effort required to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
An authenticated user holding only the Developer role can run CI/CD pipelines on protected branches in GitLab CE/EE without authorization, because the downstream (multi-project/child) pipeline creation service failed to enforce proper permission checks (CWE-863). All versions from 18.7 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 are affected, and exploitation is conditional: it requires a valid Developer account plus projects that combine downstream pipelines with protected-branch restrictions, which is why the independent assessment raises attack complexity to High even though the vendor rates the issue 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N). Publicly available exploit code exists in the form of a HackerOne report, but the provided data contains no confirmation of active exploitation and no KEV listing. Integrity impact is the dominant risk: unauthorized pipeline execution on a protected branch can inject or alter build, test, and deployment artifacts that the branch protection model was designed to shield.
RemediationAI
Vendor-released patch: upgrade GitLab CE/EE to 19.2.8, 19.3.5, or 19.4.2 (or the corresponding later release in your version line); these are the fixed versions named in the advisory at https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/, with the underlying issue tracked at https://gitlab.com/gitlab-org/gitlab/-/work_items/606501. Until the upgrade can be scheduled, the most targeted compensating control is to tighten protected-branch permissions in projects that use downstream or multi-project pipelines - set 'Allowed to merge' and 'Allowed to push' on protected branches to Maintainer-only - which blocks the Developer-role path this flaw abuses, at the cost of removing Developers' ability to merge or push to those branches and forcing every change through a Maintainer. A second option is to audit and temporarily disable downstream pipeline triggers (bridge/trigger:project jobs) in projects with protected branches, understanding that this breaks existing multi-project CI automation until the upgrade is applied. Because the flaw lives in downstream pipeline creation, review project access levels and restrict the Developer role where downstream pipelines are not operationally required, and monitor audit events for pipeline creation on protected branches originating from downstream triggers to detect abuse attempts; note that the public HackerOne report (https://hackerone.com/reports/3853866) makes the technique reproducible, so the exposure window should be kept short. No evidence of confirmed active exploitation appears in the provided data, but the availability of exploit code argues for treating exposed, unpatched instances as urgent.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-863, incorrect authorization, localized in the downstream pipeline creation service that GitLab uses for multi-project and child pipelines (the trigger:project / bridge-job mechanism). Protected branches in GitLab restrict which roles may push or merge, and by extension which roles may trigger pipelines against those refs; Developer is the typical minimum role for pipeline execution, while protected-branch enforcement is meant to elevate that bar. In the affected code path, the service that creates the downstream pipeline re-used or failed to re-evaluate the caller's authorization context, so a Developer could cause a pipeline to run against a protected branch in a downstream project without holding the privileges that branch protection normally demands. The vendor CVSS vector marks S:C (scope change), which reflects that the authorization failure crosses a trust boundary between the triggering project/context and the downstream project rather than staying inside one security scope, and I:H underscores that this is an integrity problem above all - the attacker cannot read much (C:L) and cannot cause denial of service (A:N). The affected CPE (cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:*) is a wildcard covering the GitLab CE/EE product line rather than a specific build, so version scoping must come from the advisory: 18.7 up to but not including 19.2.8, 19.3.x up to 19.3.5, and 19.4.x up to 19.4.2. The independent assessment's AC:H (versus the vendor's AC:L) is the key analytical divergence: the vulnerable path is not reachable in a default single-pipeline project and only manifests 'under certain conditions' where downstream pipelines and protected-branch rules coexist, so real-world exploitation depends on a specific, non-universal configuration.
Know when Gitlab gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N
Developer role needed (PR:L) and 'under certain conditions' downstream-pipeline path justifies AC:H; scope change (S:C) as protected-branch resources exceed the attacker's authorization, with high integrity and low confidentiality impact.
Primary rating from Vendor (GitLab).
CVSS VectorVendor: GitLab
Lifecycle Timeline
2DescriptionCVE.org
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with Developer role to execute CI/CD pipelines on protected branches without authorization due to improper authorization checks in the downstream pipeline creation service.
Executive ViewAI
GitLab CE/EE deployments running versions 18.7 through 19.4.x contain a HIGH-severity authorization flaw (CVE-2026-16301) that allows anyone holding only the low-privilege Developer role to run CI/CD pipelines on protected branches, bypassing the controls that are supposed to gate those branches. Since protected branches typically back production releases, an attacker using a legitimate, low-privilege developer account - an insider, a contractor, or a compromised credential - could inject or alter build, test, and deployment artifacts, making this primarily an integrity and software supply-chain risk to what the organization ships. Leadership should care because publicly available exploit code exists, no vendor-released patch has been identified at time of analysis, and exposure therefore depends on configuration and account hygiene rather than on a fix being available.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict or remove Developer-role assignments to the minimum necessary; disable downstream/multi-project/child-pipeline triggering on protected branches where not required; audit and harden projects that combine downstream pipelines with protected-branch restrictions; alert on and review pipeline execution against protected branches by Developer-role accounts; enforce MFA and monitor sessions for accounts with pipeline permissions.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Related Vulnerabilities in GitLab CE/EE Authorization and Access Control Flaws
View all 24An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.9. Rated critical severity (CVSS 10
An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.
When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab af
Unauthenticated arbitrary file read in GitLab CE/EE lets remote attackers retrieve files from the GitLab server via the
The SSH key upload feature (lib/gitlab_keys.rb) in gitlab-shell before 1.7.3, as used in GitLab 5.0 before 5.4.1 and 6.x
A vulnerability in GitLab CE/EE affecting all versions from 11.10 prior to 15.1.6, 15.2 to 15.2.4, 15.3 to 15.3.2 allows
Sensitive credential and configuration disclosure in GitLab Enterprise Edition allows an authenticated user with Duo Cha
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Authenticated code execution on the GitLab server is possible in GitLab CE/EE 19.2 through 19.4.0, where an integer over
Authenticated users who can define or modify a CI/CD configuration can achieve remote code execution on GitLab CE/EE ser
Unauthenticated path traversal in the @zereight/mcp-gitlab Model Context Protocol server prior to version 2.1.27 allows
Exploit-DB