CVE-2026-7492: GitLab Unauthorized Project Existence Disclosure

Technical summary

The vulnerability stems from improper authorization controls on cross-project reference pages in GitLab. When a user navigates to or queries a cross-project reference page, the application fails to consistently enforce project visibility rules. A logged-in attacker can infer the existence of private projects by observing page responses, error messages, or reference resolution behavior that should be gated behind proper authorization checks. The issue is rooted in missing or insufficient access control validation (CWE-862: Missing Authorization) at the reference resolution layer. The vulnerability requires prior authentication but does not require elevated privileges.

Business impact

This is primarily an information disclosure risk. Attackers who gain valid GitLab credentials—whether through social engineering, credential reuse, or insider access—can systematically enumerate private projects they should not be aware of. In regulated environments, this could expose the existence of confidential or compliance-related projects. For organizations using GitLab to host sensitive intellectual property or customer data, the risk is heightened if enumeration enables downstream targeting. The impact is limited because actual project contents remain protected; only existence is disclosed.

Affected systems

GitLab CE/EE versions 9.1 through 18.11.6, 19.0.0 through 19.0.3, and 19.1.0 through 19.1.1 are vulnerable. GitLab 18.11.7, 19.0.4, and 19.1.2 and later contain the fix. Organizations running any of the affected versions should prioritize inventory and upgrade planning. Both the open-source Community Edition and commercial Enterprise Edition are affected equally by this flaw.

Exploitability

Exploitation requires valid GitLab credentials, which significantly lowers the practical attack surface compared to unauthenticated vulnerabilities. An attacker cannot leverage this to gain initial access; it is a post-authentication enumeration vector. The attack is straightforward once inside: query cross-project reference pages and observe responses. No complex interaction, multi-step exploitation, or user interaction is needed. The CVSS score of 4.3 (Medium) reflects the low confidentiality impact balanced against the requirement for prior authentication. This is not on the CISA Known Exploited Vulnerabilities list and has not been observed in active exploitation campaigns.

Remediation

Upgrade to GitLab 18.11.7, 19.0.4, 19.1.2, or later versions. Organizations on older branches (e.g., 17.x, 18.x) should first verify patch availability from the GitLab security advisory. For versions near end-of-life, consider planning a major version upgrade as part of routine maintenance. Apply patches to both GitLab servers and any self-hosted runners or linked instances. Test in a staging environment to confirm cross-project references and integrations function normally after patching.

Patch guidance

Review the official GitLab security advisory to confirm patch availability for your installed version. Patches are available for versions 18.11.7, 19.0.4, and 19.1.2. If your installation is on a version older than these (e.g., 17.x), check the advisory for backport guidance or plan an upgrade to the latest stable release. Apply patches during a maintenance window, as most GitLab upgrades require a brief restart. Verify that integrations relying on cross-project references (e.g., CI/CD pipelines, issue links) continue to work after patching.

Detection guidance

Monitor GitLab audit logs for unusual cross-project reference queries from low-privileged or recently created user accounts. Look for patterns of requests to reference pages for projects the user should not have visibility of. Enable GitLab's built-in audit logging if not already active. Consider alerting on rapid successive queries to cross-project reference endpoints. Review user access lists for credentials that may have been compromised and could be used for enumeration. No signature-based detection is necessary; focus on behavioral log analysis and access control reviews.

Why prioritize this

While the CVSS score is Medium (4.3), the ease of exploitation post-authentication and the breadth of affected versions warrant timely patching. The vulnerability is most critical for organizations with strict project confidentiality requirements or those where project metadata itself is sensitive. Prioritize this among other Medium-severity issues if your environment hosts multiple sensitive GitLab projects or if you have strict access control policies. The fact that it is not yet on the KEV list and has no active exploitation does not diminish the need to patch—it suggests a window of opportunity before threat actors weaponize it.

Risk score, explained

CVSS 4.3 reflects a confidentiality impact (C:L) with no integrity or availability impact, limited by the requirement for prior authentication (PR:L). The attack vector is network-based and the attack complexity is low, meaning any authenticated user can attempt enumeration. No special privileges are required beyond login. The score appropriately captures a low-to-medium risk: it is not a critical vulnerability that enables code execution or privilege escalation, but it is a real information disclosure that could enable further attacks if combined with other intelligence.

Frequently asked questions