GitLab CVE-2026-103549

Exploitation requires an authenticated user holding maintainer-role permissions (PR:H) on a project or group that has GitLab package protection rules configured to restrict certain package registry metadata removal to higher roles (e.g., owner). The flaw only manifests 'under certain conditions' per the vendor, meaning package protection rules must be in active use and a maintainer must attempt the restricted metadata-removal action. Limiting factors: the attacker must already possess a trusted maintainer account (no anonymous or low-role access), the impact is confined to integrity of package registry metadata (no data disclosure or service disruption), and instances that do not use package protection rules are not exposed.

This is a genuinely low-priority issue, and the signals that are present all agree on that. The CVSS 3.1 base score of 2.7 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N) reflects a network-reachable but high-privilege flaw: exploitation requires an already-authenticated user holding maintainer-role permissions (PR:H), and the only impact is a low integrity hit (I:L) - removal of certain package registry metadata - with no confidentiality (C:N) or availability (A:N) consequence. There is no EPSS score, no CISA KEV listing, and no public exploit code in the provided intelligence, so there is no evidence of exploitation probability or active abuse; the status is best described as no public exploit identified at time of analysis. The underlying weakness is CWE-863 (Incorrect Authorization), consistent with the description's 'improper authorization checks.' No signals conflict here - every available indicator points the same direction: a legitimately-trusted insider (maintainer) can bypass package protection rules that are supposed to reserve certain metadata actions for higher roles. Note that the provided 'Authentication Bypass' tag is imprecise - this is an authorization/privilege-boundary flaw within authenticated sessions, not an authentication bypass. Real-world priority is low: patch in the normal maintenance cycle rather than as an emergency.

An organization configures GitLab package protection rules so that only owners (or higher roles) may remove specific package registry metadata. A user who holds only maintainer-role permissions on the affected project or group leverages the broken authorization check to delete that protected metadata anyway, overriding the intended role restriction. No public proof-of-concept is identified, and exploitation requires the attacker to already possess a valid maintainer account.