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

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

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

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

GitLab EE CVE-2026-11827

EUVD-2026-42404 MEDIUM

Insufficiently Protected Credentials (CWE-522)

2026-07-08 cve@gitlab.com

GHSA-mhr8-wccg-2q8g

Gitlab Information Disclosure Red Hat

4.9

CVSS 3.1 · Vendor: gitlab

Severity by source

Vendor (gitlab) PRIMARY

4.9 MEDIUM

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

vuln.today AI

4.4 MEDIUM

AC:H reflects 'under certain conditions' qualifier indicating non-trivial trigger state; PR:H for mandatory maintainer role; C:H for full credential disclosure; no integrity or availability impact.

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

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

Red Hat

4.9 MEDIUM

qualitative

Primary rating from Vendor (gitlab).

CVSS VectorVendor: gitlab

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 08, 2026 - 22:06 vuln.today

Patch available

Jul 08, 2026 - 22:04 EUVD

DescriptionCVE.org

GitLab has remediated an issue in GitLab EE affecting all versions from 9.5 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 authenticated user with maintainer-role permissions to obtain another user's stored credentials due to improper authorization controls.

AnalysisAI

Credential disclosure in GitLab Enterprise Edition allows an authenticated maintainer-role user to retrieve another user's stored credentials through insufficient authorization controls. All GitLab EE versions from 9.5 through the patched releases (18.11.7, 19.0.4, and 19.1.2) are affected, representing a broad historical exposure window spanning multiple major releases. No public exploit identified at time of analysis; the vulnerability was disclosed via HackerOne responsible disclosure (report 3720483), and GitLab has issued patched versions.

Technical ContextAI

GitLab EE stores user credentials - likely CI/CD integration tokens, external service credentials, or stored OAuth secrets associated with user accounts - within its platform database. CWE-522 (Insufficiently Protected Credentials) identifies the root cause class: credentials are not adequately protected against unauthorized read access through the application's authorization layer. The flaw manifests in GitLab's role-based access control (RBAC) system, which failed to properly gate read access to another user's credential objects at the maintainer privilege tier. GitLab's role hierarchy - Guest < Reporter < Developer < Maintainer < Owner - means maintainers hold elevated but non-administrative access. The improper authorization controls suggest that a privilege boundary between maintainer and account-owner context was either absent or bypassable under specific application states.

RemediationAI

The primary fix is to upgrade GitLab EE to one of the patched releases: 18.11.7 (for users on the 18.x line), 19.0.4 (for users on 19.0.x), or 19.1.2 (for users on 19.1.x). Full patch release notes are available at https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-1-2-released/. GitLab.com SaaS customers should verify with GitLab that the fix has been applied to their hosted instance. If immediate upgrade is not feasible, organizations should audit and minimize maintainer-role assignments - removing maintainer access from users who do not strictly require it reduces the pool of potential exploiters. Additionally, administrators should consider rotating sensitive stored credentials (CI/CD integration tokens, external service secrets) as a precaution, particularly for high-value accounts. The 'certain conditions' qualifier in the advisory suggests reviewing which EE features involving stored user credentials are active in your deployment, as disabling unused credential-storage integrations may limit exposure.