GitLab CVE-2026-10053

Exploitation requires a valid authenticated GitLab account with at least low-privilege access to the target instance (PR:L per CVSS vector) - anonymous or unauthenticated access is insufficient. The package registry feature must be accessible to the attacker, meaning either globally enabled or enabled for a specific project to which the attacker has access. The description explicitly notes 'under certain conditions' without disclosing the exact triggering server-side state - the precise configuration or application state required is not available in public sources, which maps to AC:H in the CVSS vector and indicates exploitation is not trivially replicable across all targets. GitLab instances where the package registry is fully disabled, or where the attacker's account lacks project-level registry permissions, would not be exploitable. The scope change (S:C) indicates that when conditions are met, the exploit breaks out of the GitLab application sandbox to affect the underlying host OS, meaning the GitLab process's OS-level permissions bound the attacker's ultimate reach.

The CVSS 8.5 base score reflects a serious network-accessible RCE with full C/I/A impact and scope change, tempered by High complexity (AC:H) and Low-privilege authentication requirement (PR:L). The AC:H rating directly corresponds to the 'under certain conditions' qualifier in the description - the precise triggering conditions are not publicly disclosed, which limits trivial mass-exploitation potential but does not prevent targeted attacks. Critically, a publicly available exploit exists on HackerOne (report 3754194), confirming that at least one researcher has successfully reproduced the attack chain; this significantly elevates urgency beyond what AC:H alone would suggest. EPSS data was not provided in the source intelligence, so probabilistic exploitation likelihood cannot be quantified precisely. The vulnerability is NOT in the CISA KEV catalog at time of analysis, meaning confirmed in-the-wild exploitation is unverified. GitLab instances are exceptionally high-value targets due to their access to source code, CI/CD pipeline secrets, deployment credentials, and internal infrastructure - a successful exploit delivers asymmetric attacker value beyond the server itself. The 'certain conditions' language should prompt defenders to verify with the vendor advisory whether default configurations are exploitable before treating AC:H as a reliable risk reduction.

An authenticated GitLab user - such as a Reporter on any project with package registry access - submits a crafted package upload request containing path traversal sequences to the GitLab package registry API endpoint. Under the specific server-side conditions that trigger the flaw, GitLab's path validation fails to sanitize the input, allowing the attacker to write a malicious file (such as a web shell, cron entry, or SSH authorized key) outside the intended package storage directory to a location writable by the GitLab process. A publicly available exploit on HackerOne (report 3754194) confirms technical feasibility; an attacker who can trigger the right conditions achieves persistent code execution on the host.