GitLab EE CVE-2026-16494

Exploitation requires a valid GitLab EE account with at least reporter or developer membership in the target project - no higher privilege is needed. The vulnerability is triggered by sending a request to the project update API endpoint with parameters that should be restricted to maintainer or owner roles; no special server-side configuration or non-default feature flag is required. Exploitation is bounded to GitLab EE versions 19.1.0-19.1.3 and 19.2.0-19.2.1; patched versions (19.1.4+, 19.2.2+) and CE installations are outside the affected scope. No victim interaction is required (UI:N). Scope is confined to the vulnerable GitLab instance (S:U), so cross-instance lateral movement is not directly enabled by this flaw alone. The primary limiting factor is the requirement for an existing authenticated account with project membership - unauthenticated or non-member exploitation is not indicated by the CVSS vector (PR:L).

The NVD CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L) accurately captures the core threat: network-reachable, no special configuration required, low-privilege authentication sufficient, high integrity impact. The I:H rating is well-justified - overwriting branch protection or approval rules is a governance-level integrity failure that can enable unauthorized code merges into production. The C:N rating is consistent with the description, which mentions no data disclosure. The A:L component reflects that misconfigured project settings could disrupt development workflows. The most significant risk amplifier here is the publicly available exploit on HackerOne: this collapses the exploitation barrier for any authenticated GitLab EE user. No EPSS score was provided in the input data, so probabilistic exploitation frequency cannot be independently quantified. KEV absence means broad, indiscriminate exploitation is not confirmed, but targeted abuse by malicious insiders or compromised low-privilege accounts is a realistic near-term threat. Organizations where GitLab EE pipelines gate production deployments should treat this as high urgency regardless of user count.

An attacker with developer-level access to a GitLab EE project - obtained via a compromised account, a malicious insider, or a newly invited contractor - sends a crafted API request to the project update endpoint referencing the publicly available exploit details on HackerOne (https://hackerone.com/reports/3775445). The authorization check is skipped, allowing the attacker to disable required merge-request approvals on the main branch. The attacker then merges a pull request containing malicious CI/CD pipeline code, which executes with production deployment credentials on the next pipeline run.