EUVD-2026-96600
GHSA-hh6j-j8mj-f737
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as any low-privileged JeecgBoot user
-
ExploitPOST to /sys/tenant/changeOwenUserTenant with target tenantId and attacker userId
-
ExecutionServer skips authorization check (CWE-862)
-
ImpactSeize tenant ownership and strip legitimate owner
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
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 (1) a valid authenticated JeecgBoot account of any privilege level - the PR:L metric confirms authentication is mandatory, so this cannot be exploited by an anonymous remote attacker; (2) the multi-tenant feature in use so that the /sys/tenant/changeOwenUserTenant endpoint and tenant records exist; and (3) a target tenantId and a userId to install as owner, both of which are typically low-entropy/enumerable. The specific limiting factor is the authenticated-account prerequisite; there is no user-interaction requirement (UI:N) and no non-default configuration beyond having tenancy enabled, so for any multi-tenant instance any logged-in member can trigger it. |
| Impact | This is a genuine but access-control-bounded risk, not a drive-by remote compromise. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) scores 7.1 (High) and is internally consistent with the description: network-reachable HTTP endpoint, low attack complexity, and crucially PR:L - exploitation REQUIRES an authenticated low-privileged account, so this is not an unauthenticated internet-facing bug. Impact is purely integrity (VI:H) via unauthorized tenant-ownership reassignment; there is no direct confidentiality or availability metric in the vendor vector, though in practice stripping the legitimate owner has an availability-like effect for that victim. A public POC exists (GitHub exploit script plus a VulnCheck advisory), which raises practical exploitability, but there is NO CISA KEV listing and NO EPSS score in the provided data, so there is no evidence of active or widespread exploitation - POC availability and active exploitation are distinct signals. Net: prioritize for multi-tenant JeecgBoot deployments because the barrier is merely any valid low-privilege login and a working exploit is published, but de-prioritize relative to unauthenticated RCE-class issues given the PR:L precondition. MISSING DATA to note explicitly: no EPSS, no KEV, and no SSVC decision data were supplied, so automatability and real-world exploitation volume cannot be confirmed from input. |
| Exploit ScenarioDerived | A low-privileged user who already holds a valid account on a multi-tenant JeecgBoot instance sends a crafted POST to /sys/tenant/changeOwenUserTenant supplying a target tenantId and their own userId. Because the endpoint performs no authorization check (CWE-862), the server reassigns that tenant's owner to the attacker and removes the legitimate owner, granting the attacker administrative control of the tenant. A public Python POC (poc_tenant_change_owner.py) demonstrates the request. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 10, 2026
Tenant ownership takeover in JeecgBoot through 3.9.5 lets any authenticated user - regardless of privilege level - reassign a tenant's owner by sending userId and tenantId to POST /sys/tenant/changeOwenUserTenant, stripping the legitimate owner and potentially installing the attacker or an accomplice as the new owner. The root cause is a missing authorization check (CWE-862) on the multi-tenant owner-change handler, rated CVSS 7.1 (CVSS:4.0 PR:L, UI:N, integrity-only impact), and publicly available exploit code exists. Exploitation is not drive-by: it requires a valid account on the target and a deployment where the multi-tenant feature is enabled, making this an access-control-bounded integrity risk rather than anonymous remote compromise.
RemediationAI
No vendor-released patched version is identified in the available data for CVE-2026-108661, so the most reliable immediate action is to add the missing authorization check at the code level: annotate the changeOwenUserTenant handler in SysTenantController.java (lines ~726-731) with the appropriate Shiro permission requirement (for example a tenant-administration permission string) and add an explicit per-object check that the caller is the current owner or a platform super-administrator for the target tenantId - the trade-off is a custom build that must be re-applied after every upstream upgrade. If tenant ownership changes are not a required workflow, disabling the multi-tenant feature removes the attack surface entirely, at the cost of tenant isolation and any functionality that depends on it. As an interim compensating control, restrict /sys/tenant/** (and particularly /sys/tenant/changeOwenUserTenant) to trusted administrative networks or IP allowlists at the reverse proxy, accepting that legitimate self-service tenant administration from other networks will break, and consider short-lived or tightly scoped accounts plus alerting on POSTs to that endpoint or on changes to tenant owner records so that any abuse is detected immediately; because publicly available exploit code exists (https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/JeecgBoot/poc_tenant_change_owner.py), review tenant ownership records for unauthorized reassignment and restore legitimate owners if compromise is suspected. Track the VulnCheck advisory (https://www.vulncheck.com/advisories/jeecgboot-through-3.9.5-missing-authorization-via-sys-tenant-changeowenusertenant) and upstream JeecgBoot releases for an official fix, since upgrade validation cannot be completed without a confirmed patched version.
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
JeecgBoot is a Spring Boot / MyBatis-Plus low-code development platform whose jeecg-system-biz module exposes REST controllers under /sys/** for platform administration, including multi-tenant management. The vulnerable handler is SysTenantController.java (lines ~726-731 in the referenced upstream revision), which implements the changeOwenUserTenant operation accepting attacker-controlled userId and tenantId parameters and rewriting the tenant's owner record. JeecgBoot normally gates privileged endpoints with Apache Shiro permission annotations (permission strings checked against the caller's role/session); this handler apparently enforces only authentication, not per-object authorization, which is the classic CWE-862 (Missing Authorization) pattern: the framework confirms the caller is logged in but never verifies that the caller has authority over the specific tenant being modified. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:N/VI:H/VA:N, SC:N/SI:N/SA:N) confirms network reachability with low attack complexity, a required authenticated session, no user interaction, and high integrity impact confined to the vulnerable component with no subsequent-system or availability impact. The CPE cpe:2.3:a:jeecgboot:jeecgboot:*:*:*:*:*:*:*:* applies as a wildcard covering all releases up to and including 3.9.5; the practical precondition is that tenancy is enabled and tenant records and candidate userId values exist and are enumerable.
Know when Jeecgboot 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
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Network HTTP endpoint (AV:N) with low complexity, but exploitation needs a valid low-privilege account (PR:L); impact is unauthorized ownership change so I:H, with no confidentiality or availability metric claimed.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows any authenticated user to transfer tenant ownership via POST /sys/tenant/changeOwenUserTenant. Low-privileged attackers can supply userId and tenantId parameters to reassign any tenant's owner to a member, including themselves, and strip the legitimate owner.
Technical POC Analysis
CWE-862 (Missing Authorization) on the tenant owner-change handler.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
1 public PoC link from github
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
JeecgBoot installations running version 3.9.5 or earlier with the multi-tenant feature enabled are exposed to a tenant ownership takeover flaw that allows any authenticated user, regardless of privilege level, to seize ownership of another tenant through a single API request. Because ownership reassignment can install the attacker or an accomplice as the legitimate owner, the exposure threatens the integrity of tenant isolation and the accuracy of access rights for every customer, department, or business unit sharing the instance, rather than exposing data directly. Leadership should care because it undermines the separation guarantees customers and regulators expect, publicly available exploit code exists, and no vendor-released patch has been identified, so risk reduction depends on configuration hardening and monitoring in the near term.
No vendor-released patch identified at time of analysis. Interim mitigations: disable the multi-tenant feature where it is not operationally required; block or IP-restrict POST /sys/tenant/changeOwenUserTenant at the reverse proxy or WAF; enforce strict least privilege and promptly deactivate dormant or unnecessary accounts, since exploitation requires a valid authenticated account; audit and reconcile tenant ownership mappings and application logs for unauthorized owner changes; add custom authorization validation to the owner-change handler if in-house development resources allow; and monitor for suspicious ownership-change activity until a vendor patch is available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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.
Unauthenticated report data exfiltration in JimuReport (JeecgBoot) through version 2.5.0 lets remote attackers export th
Broken access control in JeecgBoot through 3.9.2 lets authenticated low-privilege users reach the OpenApiAuthController
Privilege escalation in JeecgBoot through 3.9.5 lets any authenticated user approve their own pending tenant administrat
Missing authorization in the saveDeptRolePermission endpoint of JeecgBoot's SysDepartPermissionController lets any authe
SQL injection vulnerability in Beijing Guoju Information Technology Co., Ltd JeecgBoot v.3.7.2 allows a remote attacker
JeecgBoot up to v 3.5.1 was discovered to contain a SQL injection vulnerability via the component queryFilterTableDictIn
JeecgBoot up to v 3.5.1 was discovered to contain a SQL injection vulnerability via the component queryTableDictItemsByC
JeecgBoot through 3.9.5 ships a system log controller whose batch-delete handler performs no authorization check, so any
Database credential disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to retrieve JDBC
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user enumerate record IDs through the unguarded
Authenticated low-privileged users of JeecgBoot through 3.9.5 can retrieve any other user's stored password ciphertext t
Authenticated users of any privilege level on JeecgBoot through 3.9.5 can rewrite DingTalk, WeCom, or Feishu third-party
Exploit-DB