GitLab EUVD-2026-98225

Exploitation requires an authenticated account with at least Guest-level access to the GitLab instance (PR:L), and the target data must be confidential epic content whose access is governed by external authorization controls - the flaw is the incorrect authorization check that fails to enforce those restrictions. Limiting factors: the attacker must already be a provisioned user (no anonymous/unauthenticated path), the impact is read-only disclosure of epic content (no write, no code execution), and the instance must be running an affected version (17.0-19.2.7, 19.3-19.3.4, or 19.4-19.4.1) with confidential epics protected by external authorization in use.

This is a low-to-moderate priority issue despite publicly available exploit code. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3 Medium) describes a network-reachable but authenticated (PR:L) flaw with only low confidentiality impact and no integrity or availability impact - consistent with the description of a Guest-level user reading confidential epic content they should not see. A public exploit exists (HackerOne report #3809364), which lowers the barrier to reproduction, but the vulnerability is NOT in CISA KEV and no active exploitation is indicated, so POC availability should not be conflated with in-the-wild use. No EPSS score or SSVC decision data was provided in the input, so exploitation-probability and automatability signals cannot be weighed here. The requirement for authenticated Guest access and the confidentiality-only, information-disclosure nature of the bug (no RCE, no privilege escalation to write) make this a targeted data-exposure risk rather than a mass-exploitation threat - meaningful for organizations storing sensitive data in confidential epics, but not an emergency for most deployments.

An attacker who already holds a legitimate low-privilege Guest account on a GitLab instance (for example an external contractor or a user added to a public-facing project) crafts requests to access confidential epic content that external authorization controls were supposed to restrict. Because of the incorrect authorization check, the server returns the restricted epic data, disclosing sensitive planning information. A public proof-of-concept exists via the HackerOne report, lowering the effort required to reproduce the access.