GitLab Enterprise Edition EUVD-2026-107675

Two concrete prerequisites must both hold: (1) the attacker must be an authenticated user with group Owner permissions on the target group, and (2) an instance administrator must have previously locked that group's GitLab Duo availability - the flaw only manifests as a bypass of that specific admin lock. Exploitation is further limited to GitLab Enterprise Edition (EE) running affected versions (19.2 up to 19.3.6, 19.4 up to 19.4.3, 19.5 up to 19.5.1); it does not apply to Community Edition or to instances where no Duo admin lock was configured. The high privilege requirement (group Owner) is the primary limiting factor, confining this to trusted insiders rather than arbitrary authenticated users.

This is a genuinely low-priority issue, and the signals are consistent in saying so. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N, base 2.7) correctly reflects that exploitation requires an already-trusted, highly-privileged actor - an authenticated user holding group Owner permissions (PR:H) - and yields only a low integrity impact with no confidentiality or availability loss. This is an authorization-enforcement weakness (CWE-863) where the admin-lock on group Duo availability was insufficiently granular, letting a group Owner re-enable AI-backed data egress the administrator had intended to prohibit. Publicly available exploit code exists (via a HackerOne report), but there is NO CISA KEV listing and no EPSS score was provided in the input, so there is no evidence of active or widespread exploitation - POC availability and active exploitation are distinct signals and only the former is present here. The practical risk is a governance/policy-bypass by an insider rather than a path to data breach or code execution; the 'damage' is that an administrator's org-wide AI data-governance control can be overridden by a group Owner, causing group and descendant-project data to egress to a third-party AI service. No conflicting signals were found between the CVSS vector and the description - both agree on network vector, high privilege, and limited impact.

In a GitLab EE instance where the administrator has deliberately locked GitLab Duo off for data-governance or compliance reasons, a user who holds Owner on a group navigates to that group's AI/Duo settings and re-enables Duo for the group and its descendant projects, defeating the admin lock. Public exploit code for this bypass exists (HackerOne report #3871692). Because the flaw is network-reachable (AV:N) and low-complexity (AC:L) but requires group Owner privileges (PR:H), it is realistically an insider/privilege-abuse scenario rather than remote unauthenticated compromise.