CVE-2026-108658 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the SysTenantController queryTenantAuthInfo handler that allows any authenticated user to read other tenants' records. Low-privileged attackers can iterate small integer tenant ids to retrieve full sys_tenant records, including house numbers used as tenant join codes and company profile fields.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms within the SysTenantController component. Specifically, the queryTenantAuthInfo handler lacks proper authorization checks that validate whether the requesting user has permission to access data belonging to other tenants. In multi-tenant SaaS architectures, strict isolation of tenant data is paramount for maintaining confidentiality and integrity across different organizations sharing the same infrastructure. The absence of these checks allows any authenticated user, regardless of their privilege level or assigned tenant context, to query information associated with arbitrary tenant identifiers. This flaw fundamentally undermines the core security principle that users should only access resources explicitly authorized for their specific identity and role within a given tenant boundary.
From a technical perspective, this vulnerability is classified as an Insecure Direct Object Reference (IDOR), which corresponds to CWE-639 in the Common Weakness Enumeration standard. The attacker exploits the predictable nature of integer-based primary keys or identifiers used by the application's database layer for tenant records. By iterating through small sequential integers representing potential tenant IDs, a malicious actor can systematically probe the system and retrieve sensitive data associated with each valid identifier. This process does not require complex exploitation techniques but relies on simple enumeration combined with the lack of server-side validation to ensure that the requested resource belongs to the authenticated user's organization. The application fails to bind the session or token context to the specific tenant ID being queried, allowing for horizontal privilege escalation where a low-privileged user effectively gains access to data belonging to peers or other entities within the same system instance.
The operational impact of this vulnerability is severe due to the sensitivity of the exposed information. Successful exploitation allows attackers to retrieve full sys_tenant records, which often contain highly sensitive organizational details. Among these fields are house numbers that serve as tenant join codes, effectively acting as shared secrets or invitation keys for new users to enter a specific tenant environment. Compromising these codes enables further unauthorized access and lateral movement within the target organization's instance. Additionally, company profile fields may be exposed, revealing business intelligence such as organizational structure, contact information, and internal operational details that could facilitate targeted phishing attacks or social engineering campaigns against employees of the affected tenants. This exposure compromises not only data confidentiality but also potentially disrupts business operations by leaking proprietary information to competitors or malicious actors.
To mitigate this vulnerability, immediate patching to a version of JeecgBoot later than 3.9.5 is required if available from the vendor. In cases where upgrading is not immediately feasible, developers must implement robust authorization checks within the queryTenantAuthInfo handler and similar endpoints in the SysTenantController. This involves ensuring that every request for tenant-specific data includes a validation step that compares the requested tenant ID against the tenant ID associated with the authenticated user's session or token claims. If they do not match, the server should return an access denied error rather than processing the query. Furthermore, implementing rate limiting on endpoints handling enumeration-prone parameters can help detect and block automated scanning attempts. Security teams should also conduct a thorough audit of other controllers to ensure consistent enforcement of multi-tenant isolation policies across all data access points.
This incident aligns with several tactics in the MITRE ATT&CK framework, particularly those related to Collection and Discovery. The enumeration of tenant IDs falls under T1046 Network Service Scanning or more specifically T1213 Data from Information Repositories if viewed as querying internal databases for structured data. The subsequent use of join codes relates to T1598 Phishing: Spearphishing Attachment or Link, as the leaked information can be leveraged for targeted social engineering. Addressing this issue requires a comprehensive review of identity and access management policies within the application architecture to ensure that multi-tenancy is enforced at both the logical data layer and the API presentation layer without exception.