GitLab EE CVE-2026-14288

Exploitation requires an authenticated GitLab EE user (PR:L) with sufficient access to interact with a project whose protected branch is governed by a required merge-request approval policy - the vulnerability only manifests during approval rule synchronization and only 'under certain conditions,' consistent with the high attack complexity (AC:H). This is Enterprise Edition specific (approval policies are an EE feature), so Community Edition deployments are unaffected. Limiting factors: no path exists without prior authentication, the targeted project must actually enforce a required approval policy on a protected branch, and the unspecified triggering conditions plus AC:H mean exploitation is not reliable or trivial. Impact is confined to integrity of the merge-approval control; there is no confidentiality or availability consequence.

This is a genuinely low-priority issue despite the attention GitLab vulnerabilities typically attract. The CVSS 3.1 base score of 3.1 is consistent with its vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N): network-reachable but requiring high attack complexity ('under certain conditions'), an already-authenticated user with low privileges, and yielding only limited integrity impact (I:L) with no confidentiality or availability loss. Exploitation status is 'publicly available exploit code exists' - a HackerOne report (#3797008) is referenced - but this is NOT CISA KEV and there is no evidence of active exploitation; POC availability and active exploitation are distinct signals and should not be conflated. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be assessed here. An SSVC decision was not supplied either. The realistic risk is a trusted insider or low-privileged project member bypassing a required merge-request approval policy on a protected branch - a governance/integrity-control weakness, not a path to code execution, data theft, or outage. The high attack complexity and the requirement for pre-existing authenticated access substantially limit real-world exploitability, so this is a low-severity integrity issue rather than a high-impact priority.

A low-privileged but authenticated GitLab EE user with push access to a project targets a protected branch guarded by a required merge-request approval policy. By exploiting improper access control during approval rule synchronization under specific conditions, they merge changes that should have required mandatory reviewer approval, undermining the branch protection control. Public exploit detail exists in the referenced HackerOne report (#3797008).