CVE-2026-15423

This vulnerability exposes a structural flaw in how GitLab's permission model handles the gap between pipeline execution and code deployment. The authorization bypass succeeded because CI/CD runners occupy an ambiguous trust boundary that GitLab's architecture never properly defined. The core issue isn't a missing null check or a typo in a role comparison — it's a permission architecture vulnerability. GitLab's protected branch model enforces strict separation: some users can write code, some can trigger merges, some can push to protected branches. But CI/CD pipelines create a third category — execution context — that GitLab never fully integrated into this model. A Developer could run a pipeline against a protected branch's exact state without having protected branch push rights, which is not a missing check but a design question answered incorrectly. This matters because GitLab created an expectation that protected branches are safe, and security teams rely on this to enforce review requirements. But the CI/CD layer had a shadow path that respected the letter of the authorization model while violating its spirit. The vulnerability doesn't just let you execute against protected refs — it lets you do so repeatedly with observable side effects. A pipeline run produces build logs, artifact metadata, dependency resolution traces, and test outputs. An attacker can map what's actually in a protected commit's build environment — what libraries it resolves to, what compilation paths exist, what the test suite reveals about dead code — without pushing anything or leaving audit traces that look like unauthorized access. This is reconnaissance disguised as legitimate CI activity. The fix addresses the specific validation gap in 19.2.2, but the architectural question remains open. Whether pipeline execution against protected refs should require the same permissions as direct pushes, or whether execution-only access represents an acceptable risk tradeoff, is unresolved. Check your environments, deployment targets, and artifact references for similar authorization ambiguities between 'can trigger action' and 'can affect protected state'. The vulnerability class — execution context validation being separated from actor validation — recurs across CI/CD systems because the fix often patches the specific bypass without auditing whether other assumptions in that code path have similarly rotted.

Reviewed through automated stages and approved by a human before publication.