GitLab EE EUVD-2026-80221

Exploitation requires (1) a GitLab EE instance at an affected version, (2) an authenticated account with the Developer role in a group whose project has security policies that can be exercised through a policy test pipeline, and (3) protected CI/CD variables configured in that project and scoped to a higher-privileged role (Maintainer/Owner) or to an environment the policy pipeline resolves into. The attacker does not need Maintainer rights, user interaction, or a non-default network position - AV:N/AC:L/UI:N/PR:L applies directly. What limits exploitation: the Developer membership itself is the gatekeeper, so purely anonymous or self-registered users on instances with restricted sign-up are not exposed; the target group must actually define security/policy pipelines and role-scoped protected variables, which many smaller groups never configure; and Community Edition is not named in the advisory, so CE-only deployments may be unaffected pending verification.

CVSS 3.1 rates this 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N), with the score driven by the scope change and integrity impact rather than any unauthenticated exposure - the attacker must still hold a valid Developer account, so this is privilege escalation inside a group rather than an open door. That PR:L precondition is the main brake on real-world risk: an outside attacker would first need to obtain or be granted developer-level access, which typically means a compromised low-privilege account or a malicious insider. Public exploit details are available through the cited HackerOne report, which raises the likelihood of rapid weaponization against unpatched instances, but there is no CISA KEV entry and no EPSS score was supplied with this record, so widespread automated exploitation is not confirmed; even a mid-sized municipal IT team running an internal GitLab instance in leszno should treat it as urgent, yet can fold the upgrade into its normal maintenance window rather than declaring a live emergency. Note the tension in the data: the vendor vector assigns only C:L for confidentiality even though the disclosed objects are protected CI/CD variables that often hold deployment keys and tokens - if those secrets are broadly scoped, real confidentiality impact may exceed the scored value, and vice versa if protected variables contain only non-sensitive values. Under SSVC this reads as Exploitation: PoC, Automatable: yes, Technical Impact: partial, which for most organizations justifies out-of-cycle remediation; the EPSS/KEV gap is the single biggest uncertainty in this assessment.

An attacker who holds a Developer role in a group project - a compromised contractor account, a low-privilege insider, or an account granted via a weak onboarding process - creates or reuses a security policy test pipeline in a project within their group. Because the scope check is missing, the resulting job inherits protected CI/CD variables normally reserved for Maintainer or Owner roles, and a trivial script step echoing the environment dumps those secrets into the job log or to an external endpoint. With AC:L, PR:L and UI:N on a network-reachable instance, the whole chain can be scripted end-to-end, and a public PoC is already referenced.