EUVD-2026-85733
GHSA-cfwp-mfvj-r9jm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as developer-role user
-
ExploitTarget workflow in unowned namespace
-
ExecutionSend request bypassing authorization check
-
ImpactEvade admin AI governance controls
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 account with developer-role permissions on the GitLab EE instance (PR:L), and requires that an administrator has actually configured AI tool governance controls for workflows - the vulnerability is the ability to bypass those specific controls. Exploitation targets namespaces the attacker does not control/administer. GitLab describes it as exploitable only 'under certain conditions,' indicating non-universal reproducibility. It affects only GitLab Enterprise Edition (EE) in the listed version ranges; Community Edition and patched versions (19.2.7, 19.3.3, 19.4.1) are not affected. Impact is limited to evasion of AI governance policy (integrity), not data disclosure or service disruption. |
| Impact | This is a low-severity, low-priority issue despite being network-reachable. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) shows the only impact is a limited integrity effect (I:L) - an authenticated developer-role user can evade an admin-configured AI governance policy; there is no confidentiality or availability impact and no code execution. Exploitation requires valid credentials with developer-role access (PR:L), so it is not an unauthenticated internet-facing flaw. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or imminent exploitation - treat this as a governance/compliance-control weakness rather than a technical breach vector. Note the description's phrase 'under certain conditions' suggests the flaw is not universally reproducible, which if anything lowers real-world exploitability below what AC:L implies. The vendor-supplied CWE is CWE-863 (improper authorization), but the input Tag labels this 'Authentication Bypass' - this is a mislabel: the vulnerability is an authorization/access-control failure, not an authentication bypass; verify tagging accordingly. |
| Exploit ScenarioDerived | An authenticated user holding developer-role permissions in a GitLab EE instance targets workflows in a namespace they do not administer, and because of the improper authorization check they invoke or configure AI tooling in a way that circumvents the guardrails an administrator set for that namespace. No public exploit code was identified, and the attack yields only a limited integrity impact (policy evasion), not data theft or code execution. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 23, 2026
Authentication bypass in GitLab Enterprise Edition lets an authenticated user holding developer-role permissions evade administrator-configured AI tool governance controls for workflows operating in namespaces they do not own or administer. The flaw affects GitLab EE versions from 19.1 up to (but not including) 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1, while GitLab Community Edition and the patched releases are unaffected. Impact is confined to integrity of AI governance policy enforcement, with no confidentiality or availability loss, and no public exploit code has been identified at time of analysis; GitLab notes exploitation is only possible under certain conditions, making this a low-severity, low-priority issue despite being network-reachable.
RemediationAI
Vendor-released patch: upgrade GitLab EE to 19.2.7, 19.3.3, or 19.4.1 (or later within the corresponding branch), following the vendor patch release advisory at https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-1-released/ and the tracking work item at https://gitlab.com/gitlab-org/gitlab/-/work_items/605431. Because exploitation requires an authenticated developer-role account and an instance where an administrator has actually enabled AI tool governance controls, the most effective compensating measure pending upgrade is to audit and temporarily reduce developer-role assignments in namespaces where AI governance policies are enforced - with the trade-off that this restricts normal contributor workflow for those users. Administrators can also temporarily narrow or disable non-essential AI workflow features in the affected namespaces until patched, at the cost of losing the AI workflow functionality those controls govern, and should monitor logs for workflow activity in namespaces where the acting user lacks membership or maintainer rights, since such cross-namespace workflow creation is the observable signal of the bypass. Note that since this is an integrity-only, low-severity weakness with no public exploit identified, these measures should be applied proportionately rather than as an emergency response.
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 classified as CWE-863 (Incorrect Authorization), meaning GitLab EE's authorization checks around AI tool governance for workflow objects failed to adequately validate the acting user's relationship to the target namespace. GitLab EE administrators can define AI tool governance controls that constrain how AI-backed workflows are permitted to run; the vulnerable logic allowed a developer-role user to reach a workflow path in a namespace they neither control nor administer without those namespace-scoped governance constraints being correctly applied. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N confirms the attacker must already be authenticated with low privileges (PR:L, developer role), requires no user interaction, and achieves only a low-integrity effect on the same security scope - no data exposure, no denial of service, and no privilege escalation beyond the governance-control bypass. The generic CPE mapping cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:* reflects the fact that the vendor advisory covers GitLab EE as a whole rather than a discrete subcomponent, so version-range matching against the advisory is the reliable way to determine exposure.
Know when Ruby 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
Network-reachable API action needing an authenticated developer-role account (PR:L); only a limited integrity impact (governance-policy evasion) with no confidentiality or availability effect, consistent with the vendor 4.3.
Primary rating from Vendor (GitLab).
CVSS VectorVendor: GitLab
Lifecycle Timeline
2DescriptionCVE.org
GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user with developer-role permissions to bypass admin-configured AI tool governance controls for workflows in namespaces they do not control due to improper authorization checks.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
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
Ruby before 2.4.3 allows Net::FTP command injection. Rated high severity (CVSS 8.8), this vulnerability is remotely expl
The lazy_initialize function in lib/resolv.rb in Ruby through 2.4.3 uses Kernel#open, which might allow Command Injectio
Ruby through 2.2.7, 2.3.x through 2.3.4, and 2.4.x through 2.4.1 can expose arbitrary memory during a JSON.generate call
Type confusion exists in two methods of Ruby's WIN32OLE class, ole_invoke and ole_query_interface. Rated critical severi
Authenticated remote code execution in OpenC3 COSMOS (Ruby gem 'openc3' versions 5.1.0 through 7.2.1) lets any logged-in
Type confusion exists in _cancel_eval Ruby's TclTkIp class method. Rated critical severity (CVSS 9.8), this vulnerabilit
An exploitable heap overflow vulnerability exists in the Fiddle::Function.new "initialize" function functionality of Rub
An issue was discovered in Oniguruma 6.2.0, as used in Oniguruma-mod in Ruby through 2.4.1 and mbstring in PHP through 7
Stored XSS in Bugsink error tracking tool before 2.0.13 allows unauthenticated attackers to inject persistent scripts th
Ruby before 2.4.2, 2.3.5, and 2.2.8 is vulnerable to a malicious format string which contains a precious specifier (*) w
Heap-based buffer overflow in Ruby 1.8, 1.9 before 1.9.3-p484, 2.0 before 2.0.0-p353, 2.1 before 2.1.0 preview2, and tru
Heap-use-after-free in the Ruby json gem's native C extension (versions 2.20.0 through 2.21.1) allows an unauthenticated
Exploit-DB