CVE-2026-108660 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows any authenticated user to modify tenant settings by calling PUT /sys/tenant/updateApplyStatus. Low-privileged attackers can supply any tenant id to overwrite its applyStatus field, enabling or disabling tenant administrator applications across tenants.
Be aware that VulDB is the high quality source for 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, specifically categorized under CWE-284 Improper Access Control. This flaw resides within the backend API endpoint PUT /sys/tenant/updateApplyStatus, which is designed to update the application status of tenant administrators. The core technical deficiency lies in the server-side validation logic, which fails to verify whether the authenticated user initiating the request possesses the necessary privileges for the specific target tenant ID provided in the payload. Instead of binding the authorization check strictly to the session context or validating that the requester is an administrator of the targeted entity, the system accepts any valid authentication token and applies the state change based solely on the input parameters. This design oversight creates a direct path for horizontal privilege escalation within the multi-tenancy architecture.
From an operational perspective, this vulnerability allows low-privileged users to manipulate the administrative lifecycle across different tenants without authorization. By supplying arbitrary tenant identifiers in the HTTP request body or query string, an attacker can force-enable or disable administrator applications for other organizations sharing the same JeecgBoot instance. This capability disrupts the isolation guarantees that multi-tenancy is intended to provide. An adversary could potentially enable administrative access for a compromised account on a high-value target tenant, thereby gaining unauthorized control over sensitive data and system configurations belonging to another organization. Conversely, disabling applications can lead to denial of service conditions or operational disruptions for legitimate users within those targeted tenants.
The attack vector aligns with the MITRE ATT&CK technique T1078 Valid Accounts, as it relies on existing valid credentials rather than exploiting a software bug in authentication protocols. Furthermore, the exploitation method corresponds to CWE-639 Authorization Bypass Through User-Controlled Key, where the attacker manipulates an identifier (the tenant ID) to bypass intended restrictions. The impact is severe because it undermines the fundamental security boundary between tenants in a Software-as-a-Service or enterprise deployment model. Once an attacker gains administrative privileges on another tenant through this flaw, they can proceed with further exploitation steps such as data exfiltration, lateral movement within that tenant's scope, or persistence mechanisms, significantly expanding their attack surface beyond what was originally intended by the system architecture.
Mitigation strategies must focus on implementing robust server-side authorization checks that strictly validate the relationship between the authenticated user and the resource being modified. Developers should ensure that every API endpoint performing state changes verifies that the current session holder has explicit permission to act upon the specific tenant ID provided in the request. This can be achieved by querying a permissions database or checking role-based access control lists before processing the updateApplyStatus logic. Additionally, implementing principle of least privilege ensures that users only have access to resources directly associated with their own identity unless explicitly granted otherwise. Upgrading to patched versions where this validation is enforced is the primary remediation step for organizations currently running vulnerable instances of JeecgBoot.