GitLab CVE-2026-100104

Exploitation requires an authenticated GitLab CE/EE user who has access to repository import functionality (PR:L), and the attacker must successfully win a time-of-check to time-of-use race condition in the URL validation path during a repository import operation - the core limiting factor reflected in AC:H. The description notes it is only exploitable 'under certain conditions,' indicating it is not reliably triggerable; the attacker must repeatedly race the validation/fetch window, which is timing-dependent and generally not automatable. No special non-default feature beyond the standard import capability is named, but a valid account with import rights and the ability to reach the instance over the network are prerequisites. Affected deployments are those running versions from 10.3 up to the fixed releases (19.2.8, 19.3.5, 19.4.2).

This is a genuinely low-priority issue despite being a server-side request forgery flaw, and the signals are internally consistent rather than conflicting. The CVSS 3.1 base score is only 3.5 (LOW), driven by a demanding combination: AV:N (network reachable) but AC:H (high complexity) because exploitation hinges on winning a time-of-check to time-of-use race condition in URL validation, PR:L (an authenticated user is required), and limited impact of C:L/I:N/A:N with S:C reflecting that the SSRF can pivot to internal network resources outside the vulnerable component's authorization scope. No EPSS score, KEV listing, or POC was provided in the input, so there is no evidence of exploitation probability or active abuse - no public exploit identified at time of analysis. The AC:H race condition is the dominant mitigating factor: reliably timing the check/use window is non-trivial and typically not automatable, which aligns with the low CVSS. No SSVC decision data was supplied. Overall this reads as a real-but-low-risk hardening fix rather than an urgent threat; defenders should patch on a normal cycle. No conflicting signals were detected between the CVSS vector and the description - both agree on an authenticated, network-reachable, low-impact SSRF.

An authenticated GitLab user with permission to import a repository supplies a crafted import URL and repeatedly triggers the import, racing the gap between URL validation and the actual fetch so that a blocked internal address is substituted after passing validation. Winning this race lets the server issue requests to internal-only resources (e.g., metadata services or internal hosts), returning limited information to the attacker. No public exploit is known, and the high attack complexity (race condition) makes reliable exploitation difficult.