Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain project-scoped fine-grained PAT
-
ExploitSend crafted label API request targeting group scope
-
ExecutionAuthorization check fails to enforce ownership
-
ImpactDelete or modify group-level labels
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V8 - Authorization Insufficient granularity of access control
|
| Exploitation Conditions | Exploitation requires an authenticated GitLab account that holds a project-scoped fine-grained Personal Access Token; the attacker leverages this token to reach group-level label operations it should not be authorized for. The flaw is further gated by 'under certain conditions' per GitLab's description, implying specific label ownership/scope states must be present. Limiting factors: a valid user session and a fine-grained PAT are needed (PR:L, not anonymous), impact is confined to group-level labels (integrity only, no data disclosure or service outage), and only instances running the affected versions (18.11 through <19.2.8, 19.3 through <19.3.5, 19.4 through <19.4.2) are vulnerable. |
| Impact | This is a low-to-moderate priority issue despite being a confirmed authorization flaw. The CVSS 3.1 base score is 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N - network-reachable and low-complexity, but requiring an authenticated principal (PR:L) and yielding only limited integrity impact (I:L) with no confidentiality or availability loss. The weakness (CWE-1220, insufficient granularity of access control) lets a project-scoped fine-grained PAT escalate laterally to modify or delete group-level labels, i.e. a scope-boundary bypass rather than a system compromise. Public exploit material exists (HackerOne #3741505), which raises practical risk, but there is no CISA KEV listing and no EPSS value supplied, so there is no evidence of active or widespread exploitation - the POC signal and the absence of KEV together point to a researcher-disclosed issue, not an in-the-wild campaign. Note the input tag 'Information Disclosure' conflicts with the CVSS vector (C:N, I:L), which describes an integrity/data-manipulation issue, not disclosure - treat the tag as unreliable. Net: a legitimate but low-severity integrity bug warranting routine patching, not emergency response. |
| Exploit ScenarioDerived | An authenticated GitLab user who has been issued a project-scoped fine-grained Personal Access Token uses that token to send API requests that act on group-level labels outside the token's intended project scope. Because label ownership-scope validation is incorrect, the server authorizes the operation, letting the attacker permanently delete or modify labels belonging to the parent group. Public exploit material is available via HackerOne report #3741505, lowering the effort required to reproduce the attack. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Incorrect authorization logic in GitLab CE/EE allows an authenticated user holding a project-scoped fine-grained Personal Access Token to permanently delete or modify group-level labels that the token should not be able to reach, affecting versions 18.11 through before 19.2.8, 19.3 through before 19.3.5, and 19.4 through before 19.4.2. The flaw is rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), meaning exploitation requires a low-privileged authenticated account and token, is confined to integrity impact on group labels, and does not expose data or cause a denial of service; GitLab states exploitation is further gated by unspecified 'certain conditions' around label ownership. Publicly available exploit code exists and the issue was reported through HackerOne, but the impact is limited to label tampering rather than broader project or repository compromise, making this a low-to-moderate priority authorization issue for affected self-managed and GitLab.com-style deployments.
RemediationAI
Vendor-released patch: GitLab 19.2.8, 19.3.5, and 19.4.2 - upgrade to the fixed build for your release branch (or any later version) as described in the patch release announcement at https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/, and follow GitLab's standard upgrade path with a backup taken beforehand. If immediate upgrade is not possible, compensating controls are constrained because the flaw is in GitLab's own authorization code rather than a configurable feature: you can reduce exposure by auditing and revoking unnecessary fine-grained Personal Access Tokens, particularly project-scoped tokens granted label-management or API-write permissions, since a token that cannot reach the labels API cannot exercise this flaw - the trade-off is that legitimate automation relying on those tokens will break. Administrators can also restrict token creation and enforce expiration under Admin Area > Settings > General > Account and limit, and monitor group label changes via audit events and the groups/projects API to detect tampering; these are detective-only and do not prevent exploitation. There is no documented server-side setting that disables group-level labels without significant disruption to inherited label workflows, so patching remains the primary remediation.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-1220, Insufficient Granularity of Access Control, realized here in GitLab's fine-grained Personal Access Token model. Fine-grained PATs are scoped down to a specific project and a subset of permissions, and label objects in GitLab have a separate ownership model: labels can be defined at the project level or at the group level (and inherited downward). The affected code validated the token's project scope when reaching label endpoints but did not correctly enforce ownership/scope checks when the label being mutated actually belonged to the parent group. As a result, a token that should only be able to touch project-scoped resources could satisfy authorization for group-level label deletion or modification. Because the check is an authorization-granularity defect rather than a memory-safety or injection flaw, the outcome is purely state manipulation of label metadata - no code execution, no credential exposure, and no lateral movement to repositories. The CPE string cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:* confirms this is the GitLab application itself rather than an external component; the exploit conditions require a valid authenticated session plus a fine-grained PAT (CVSS PR:L, so not anonymous), and the assessment vector explicitly scores C:N/I:L/A:N, i.e. integrity-only. Note that community tagging for this CVE labels it 'Information Disclosure', which the assessed vector does not support; the defensible impact is unauthorized modification or destruction of group-level label data.
Know when Gitlab gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Remote API-reachable (AV:N/AC:L) but requires an authenticated fine-grained PAT (PR:L); unauthorized label modification/deletion gives limited integrity impact only (I:L), no confidentiality or availability loss.
Primary rating from Vendor (GitLab).
CVSS VectorVendor: GitLab
Lifecycle Timeline
2DescriptionCVE.org
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with a project-scoped fine-grained Personal Access Token to permanently delete or modify group-level labels, due to incorrect authorization logic on label ownership scope validation.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Related Vulnerabilities in GitLab CE/EE Authorization and Access Control Flaws
View all 24An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.9. Rated critical severity (CVSS 10
An issue has been discovered in GitLab CE/EE affecting all versions from 16.1 prior to 16.1.6, 16.2 prior to 16.2.9, 16.
When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab af
Unauthenticated arbitrary file read in GitLab CE/EE lets remote attackers retrieve files from the GitLab server via the
The SSH key upload feature (lib/gitlab_keys.rb) in gitlab-shell before 1.7.3, as used in GitLab 5.0 before 5.4.1 and 6.x
A vulnerability in GitLab CE/EE affecting all versions from 11.10 prior to 15.1.6, 15.2 to 15.2.4, 15.3 to 15.3.2 allows
Sensitive credential and configuration disclosure in GitLab Enterprise Edition allows an authenticated user with Duo Cha
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Authenticated code execution on the GitLab server is possible in GitLab CE/EE 19.2 through 19.4.0, where an integer over
Authenticated users who can define or modify a CI/CD configuration can achieve remote code execution on GitLab CE/EE ser
Unauthenticated path traversal in the @zereight/mcp-gitlab Model Context Protocol server prior to version 2.1.27 allows
EUVD-2026-98226
GHSA-hx4m-w847-w5h9
NVD
CVE.org
EPSS
Exploit-DB