GitLab EE EUVD-2026-50477

Exploitation requires a valid authenticated session with at minimum low-privilege access to a GitLab EE instance (CVSS PR:L confirmed). The bypass is specifically tied to the token generation process and occurs only 'under certain conditions' per the advisory - the exact triggering configuration or API invocation path is not publicly disclosed, and the issue work item at https://gitlab.com/gitlab-org/gitlab/-/work_items/605484 may be restricted. Limiting factors include: authentication is mandatory (unauthenticated exploitation is excluded by PR:L), the vulnerability is scoped to GitLab EE only (not Community Edition), the 'certain conditions' qualifier implies the bypass does not fire universally for all token generation requests, and the impact is restricted to integrity (policy circumvention) with no confidentiality or availability consequence.

The CVSS 4.3 base score reflects a moderate-priority finding: network-accessible (AV:N), low complexity (AC:L), low privileges required (PR:L), no user interaction (UI:N), unchanged scope, and low integrity impact (I:L) with no confidentiality or availability impact. The practical risk is bounded by the requirement for a valid authenticated session, the EE-only scope, and the undisclosed 'certain conditions' trigger, which introduces uncertainty about how reliably the bypass can be achieved. No EPSS data was present in the source intelligence, and the vulnerability is not in CISA KEV, with no public POC referenced. Real-world priority is highest for organizations that depend on GitLab EE tool governance to enforce compliance or insider-threat controls - in those environments the integrity impact, though scored low, could represent a meaningful policy failure. For organizations not using EE governance features, exploitability is effectively nil.

An authenticated GitLab EE user with a standard low-privilege account initiates a token generation request under specific conditions that trigger the authorization defect, causing the system to issue a token that is not bound by the administrator's tool governance policy. The user then employs that token to access a tool or capability that policy should have blocked. No public exploit code has been identified at time of analysis, and the 'certain conditions' qualifier suggests the bypass may require non-obvious setup or a specific API flow.