What is the CVSS score of CVE-2026-7492?

CVE-2026-7492 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2026-7492?

Yes, a patch is available for CVE-2026-7492. Update the affected software to the latest version immediately.

GitLab CE/EE CVE-2026-7492

EUVD-2026-42406 MEDIUM

Missing Authorization (CWE-862)

2026-07-08 cve@gitlab.com

GHSA-pggx-2v9r-j6gm

Authentication Bypass Gitlab Red Hat

5.3

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

vuln.today AI

4.3 MEDIUM

Network-exploitable information disclosure requiring a valid account (PR:L per CVSS vector); PR:N not adopted due to unresolved description-versus-vector conflict; no integrity or availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Red Hat

5.3 MEDIUM

qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

CVSS changed

Jul 09, 2026 - 20:52 NVD

4.3 (MEDIUM) 5.3 (MEDIUM)

Analysis Generated

Jul 08, 2026 - 22:28 vuln.today

Patch available

Jul 08, 2026 - 22:04 EUVD

DescriptionNVD

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 9.1 before 18.11.7, 19.0 before 19.0.4, and 19.1 before 19.1.2 that under certain conditions could have allowed an unauthenticated user to determine the existence of a private project due to improper authorization controls on cross-project reference pages.

AnalysisAI

Private project existence disclosure in GitLab CE/EE (versions 9.1 through 18.11.x, 19.0.x, and 19.1.x) enables low-privilege GitLab account holders to confirm whether a private project exists via improperly authorized cross-project reference pages. The flaw stems from missing authorization controls (CWE-862) on reference resolution endpoints, leaking project existence metadata to users who have no authorized access to the targeted private project. No public exploit exists and this vulnerability is not listed in CISA KEV; GitLab has released patches across all three affected version branches.

Technical ContextAI

GitLab's cross-project reference system allows one project to reference issues, merge requests, or commits in another (e.g., 'namespace/project#123'). When these references are resolved or rendered, GitLab failed to enforce adequate authorization checks (CWE-862: Missing Authorization) on the underlying reference page endpoints, permitting the resolution logic to implicitly confirm a private project's existence to users who lack access to it. The affected CPE spans GitLab CE and EE from version 9.1 onward across all three currently supported major branches, indicating this authorization gap has been present in the reference resolution subsystem for an extended period. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) confirms this is a network-accessible, confidentiality-only flaw with no integrity or availability impact and no scope change.

RemediationAI

Upgrade to one of the patched releases per your current major version: GitLab CE/EE 18.11.7, 19.0.4, or 19.1.2. Full patch release details and upgrade instructions are available at https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-1-2-released/. If immediate patching is not feasible, restrict access to the GitLab instance at the network layer (firewall rules or VPN requirement) so that only known, authorized users can reach the instance at all - this reduces the exploitable population to those already holding valid accounts, though it does not eliminate the vulnerability for open-registration or multi-tenant deployments. No documented configuration-level workaround exists to selectively disable cross-project reference resolution without broader functional impact. On open-registration instances, disabling public sign-up (Admin > Settings > General > Sign-up restrictions) limits the attacker pool at the cost of requiring manual user provisioning.