Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as contributing user
-
ExploitExploit improper identity resolution
-
ImpactSelf-approve own contributed merge request
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated GitLab EE account (PR:L) that has itself contributed commits to the target merge request, plus the specific 'certain conditions' under which improper identity resolution occurs - implying the environment must rely on merge-request approval rules that forbid contributors from approving their own changes (the four-eyes/separation-of-duties control being bypassed). Limiting factors: only GitLab Enterprise Edition is affected (not pure CE deployments), valid authenticated access is needed, high attack complexity (AC:H) indicates the identity-resolution edge case is not trivially triggerable, and the impact is confined to the review-governance process rather than direct data or system compromise. |
| Impact | This is a low-severity authorization flaw (vendor CVSS 3.1 base 4.2, CWE-863 Incorrect Authorization) and the combined signals point to a genuinely low real-world priority rather than an urgent one. The CVSS vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) shows network reach but requires an already-authenticated user (PR:L) and high attack complexity (AC:H), consistent with the description's qualifier that the bypass only occurs 'under certain conditions' via improper identity resolution. There is no CISA KEV listing, no public exploit code identified, and no EPSS score supplied in the input, so there is no evidence of active or probable exploitation. The primary impact is to the integrity of merge-request approval controls (separation-of-duties / four-eyes review), not system compromise; note the vendor assigned C:L but the described behavior - self-approving a merge request you contributed to - maps more naturally to an integrity-of-process issue than to confidentiality, a point worth verifying with GitLab. Net assessment: a defense-in-depth governance weakness for organizations that rely on GitLab approval rules for compliance, not a high-urgency remotely-exploitable vulnerability. |
| Exploit ScenarioDerived | An authenticated GitLab EE user who has pushed commits to a merge request leverages an identity-resolution flaw to satisfy the approval requirement themselves, bypassing the rule that prevents contributors from approving their own changes. This lets a single insider merge code without the intended independent review, undermining separation-of-duties controls. No public proof-of-concept exploit has been identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Authenticated users of GitLab Enterprise Edition can approve a merge request even when they themselves contributed commits to it, defeating the separation-of-duties control that approval rules are meant to enforce. The flaw stems from improper identity resolution and affects all EE versions from 16.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2, and it requires a valid authenticated account that has already pushed commits to the target merge request, with high attack complexity because the identity-resolution edge case is not trivially triggered. Impact is confined to review governance (integrity of the approval workflow) with no confidentiality or availability impact; this is a low-severity issue (vendor CVSS 3.1 base 4.2, CWE-863), and no public exploit identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to GitLab EE 19.2.8, 19.3.5, or 19.4.2 depending on your release track, as documented in the patch release advisory at https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/ (upstream work item: https://gitlab.com/gitlab-org/gitlab/-/work_items/606772). If immediate upgrade is not possible, compensating controls should target the approval-rules bypass rather than the feature set as a whole: require approvals from a dedicated reviewer group whose members are restricted from pushing commits to the protected branches in scope (this preserves four-eyes integrity but adds review latency and staffs a separate approval roster); enable protected branch settings and push rules so that only designated maintainers can author changes routed through those approval rules, which narrows the set of accounts that can be both contributor and approver; and monitor GitLab audit events and the merge request approvals API for cases where the approver and an author resolve to the same account, using that as a detection control while unpatched - with the trade-off that this only detects rather than prevents the bypass and generates review overhead. There is no public exploit identified at time of analysis, so patching on a normal maintenance cadence is reasonable.
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 defect is an incorrect authorization (CWE-863) in GitLab Enterprise Edition's merge request approval logic, specifically in the identity resolution used to decide whether a given user counts as a contributor to the merge request and therefore must be blocked from approving it. Merge approval rules implement a four-eyes / separation-of-duties control, so an approver who authored part of the change should be excluded; here the contributor-to-account matching fails under certain conditions, letting the same authenticated principal act as both author and approver. Attack complexity is rated high (AC:H) because the bypass depends on a non-obvious edge case in that matching rather than a simple request, and the vector (AV:N/AC:H/PR:L/UI:N/S:U) confirms a network-reachable, authenticated-only, low-privilege path with no user interaction. Only the Enterprise Edition is affected, since the merged-result and multiple-approval-rule features involved are EE functionality; public CPE data (cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:*) covers GitLab as a whole rather than separating CE from EE.
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:H/PR:L/UI:N/S:U/C:L/I:L/A:N
Web-reachable (AV:N) but needs an authenticated contributing user (PR:L) and a non-trivial identity-resolution edge case (AC:H); impact is integrity of approval controls (I:L), no confidentiality or availability effect.
Primary rating from Vendor (GitLab).
CVSS VectorVendor: GitLab
Lifecycle Timeline
2DescriptionCVE.org
GitLab has remediated an issue in GitLab EE affecting all versions from 16.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 to approve a merge request despite having contributed commits to it, due to improper identity resolution.
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
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
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-98216
GHSA-3wqg-xrf4-q3m8
NVD
CVE.org
EPSS
Exploit-DB