CVE-2026-108881 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the getTenantPackInfo handler that allows any authenticated user to read other tenants' product pack membership. Low-privileged attackers can supply a tenantId and fixed packCode values such as superAdmin, accountAdmin or appAdmin to disclose administrator usernames, real names, phones and departments.
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 multi-tenant access control mechanisms, specifically within the getTenantPackInfo handler. This flaw stems from an improper implementation of authorization checks that fail to validate whether the authenticated user possesses sufficient privileges or belongs to the specific tenant context associated with the requested resource. In a properly secured multi-tenancy architecture, data isolation is paramount; each tenant's data must remain strictly segregated and inaccessible to users belonging to other tenants unless explicitly permitted by administrative policies. However, in this instance, the application logic relies on insufficient verification of the relationship between the authenticated session’s tenant identifier and the target resource’s identifiers. This oversight allows any user who has successfully authenticated to the system to bypass these isolation boundaries entirely.
From a technical perspective, the exploitation vector involves manipulating input parameters sent to the getTenantPackInfo endpoint. An attacker with low-privileged access can supply arbitrary values for the tenantId parameter while using fixed packCode values such as superAdmin, accountAdmin, or appAdmin. The backend processing logic fails to cross-reference these inputs against the current user’s actual permissions and tenant affiliation. Consequently, the system returns sensitive membership information associated with those administrative roles across different tenants. This behavior indicates a classic Broken Access Control issue where the server trusts client-supplied identifiers without performing adequate server-side validation of ownership or permission levels. The absence of robust checks allows for horizontal privilege escalation within the multi-tenant environment, enabling lateral movement between isolated data silos that should remain strictly separate.
The operational impact of this vulnerability is severe due to the nature of the disclosed information. By exploiting this flaw, attackers can enumerate administrator usernames, real names, phone numbers, and departmental structures from other tenants. This constitutes a significant privacy breach and provides valuable intelligence for further attacks. The exposure of administrative credentials facilitates targeted phishing campaigns or credential stuffing attempts against high-privilege accounts within those organizations. Furthermore, the disclosure of organizational hierarchies aids in social engineering efforts and can assist attackers in mapping out target infrastructure to plan more sophisticated intrusion scenarios. This level of information leakage undermines trust in the platform’s security model and may violate data protection regulations such as GDPR or CCPA depending on the jurisdiction and nature of the affected entities.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures where access control decisions are not enforced properly during resource requests. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, as it allows low-privileged users to leverage valid credentials to access unauthorized resources and gather intelligence for subsequent exploitation phases like T1596, Search Open Technical Databases or T1046, Network Service Discovery within the context of multi-cloud environments. To mitigate this risk, developers must enforce strict server-side authorization checks that verify both the user’s role permissions and their tenant affiliation against every requested resource ID. Implementing robust input validation to ensure that tenantId values match the authenticated session’s context is essential. Additionally, adopting a principle of least privilege for API endpoints and conducting regular security audits focused on multi-tenancy isolation will help prevent similar access control failures in future releases.