GitLab CVE-2026-13319

Exploitation requires an authenticated GitLab account on the target instance (PR:L) - on instances permitting open self-registration this bar is effectively minimal, but on locked-down instances it requires valid credentials. The specific trigger is supplying a user-controlled project filter parameter to the group milestones API, which lacks an authorization check; no project membership in the targeted private projects is needed. No user interaction and no special non-default configuration is required beyond having the group milestones API reachable. Limiting factors: impact is confined to read-only disclosure of milestone metadata (titles, descriptions, full project paths) - no data modification, no code access, and only Medium confidentiality exposure. Affected versions are 15.10 up to the fixed releases (19.3.6, 19.4.3, 19.5.1); patched instances are not exploitable.

This is a genuine but low-to-moderate priority information-disclosure flaw, not a high-impact issue. The CVSS 3.1 score of 4.3 (Medium) is consistent with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N: network-reachable, low complexity, but requiring an authenticated account (PR:L) and yielding only limited confidentiality impact (C:L) with no integrity or availability effect. Publicly available exploit code exists (referenced HackerOne report #3792168), which raises practical risk, but there is no CISA KEV listing - so this should be treated as 'publicly available exploit code exists', NOT active exploitation. No EPSS score was provided in the input, so the statistical exploitation probability cannot be weighed here and should be checked separately. No SSVC decision data was supplied. The realistic risk is unauthorized enumeration/reconnaissance: any authenticated user (including low-privilege or, on instances allowing self-registration, near-anonymous accounts) can read milestone titles, descriptions, and full project paths from arbitrary private projects, leaking project structure and potentially sensitive planning information. The weakness is an IDOR (CWE-639), i.e. an authorization bypass, so the 'Authentication Bypass' tag in the input is imprecise - the user is authenticated; it is authorization that fails.

An authenticated GitLab user (no membership in the target projects) sends a request to the group milestones API supplying a crafted project filter parameter referencing private projects they should not see. Because the authorization check on that user-supplied parameter is missing, the API returns milestone metadata - titles, descriptions, and full project paths - for those private projects. Public exploit code is referenced via a HackerOne report, lowering the barrier to reproduction.