GitLab CE/EE CVE-2026-15423

Exploitation requires an authenticated GitLab session with at least developer-role permissions on the target project - unauthenticated attackers cannot exploit this. The target project must have one or more protected branches configured (the bypass is irrelevant on projects without branch protections). The attacker must be able to trigger CI/CD pipelines (a standard developer capability) but must specifically lack the push permissions that would normally be required to run pipelines against the protected ref. Running versions must fall within 19.0.0-19.0.5, 19.1.0-19.1.3, or 19.2.0-19.2.1. The limiting factors are: (1) valid developer-level credentials are required - no anonymous exploitation path; (2) the vulnerability only manifests when branch protection rules are in place; (3) the disclosure notes 'certain conditions,' implying edge cases in project configuration may affect reproducibility.

The CVSS 8.5 score with a Scope:Changed vector (S:C) reflects that successful exploitation allows a developer to influence resources beyond their authorized access boundary - specifically protected branch environments and their associated CI/CD secrets. AV:N/AC:L/PR:L presents a low barrier: any authenticated developer-role user can attempt this over the network without special complexity. The I:H rating is significant because pipeline execution on a protected branch may trigger deployments, access protected environment variables, or circumvent mandatory code review gates. A publicly available exploit lowers the effective attack complexity in practice. No EPSS score was provided in the input, and CISA KEV status is absent - exploitation appears opportunistic or targeted rather than broad at this stage. The most meaningful risk amplifier is that GitLab's branch protection model is often used as a security control in regulated environments (SOC 2, PCI-DSS); this bypass directly undermines that control.

A developer-role user on a GitLab instance - such as a malicious insider, compromised contractor account, or attacker who obtained valid credentials - crafts a pipeline trigger API request that abuses the flawed reference validation logic to target a protected branch (e.g., main or release) without holding push permissions. The pipeline executes in the protected branch context, granting the attacker access to protected environment variables, deployment secrets, or the ability to deploy untested or malicious code to a production environment. A publicly available exploit is documented in HackerOne report #3832069, lowering the technical skill required to reproduce the bypass.