CVE-2026-108873 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows low-privileged authenticated users to modify any department by calling PUT /sys/user/doUpdateDepartInfo. Attackers can supply a department id to rename or re-parent it and replace or remove its department heads without ownership or tenant checks.
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, specifically classified under CWE-284 Improper Access Control. This flaw resides within the API endpoint PUT /sys/user/doUpdateDepartInfo, which is designed to update departmental information such as names, parent structures, and leadership assignments. The core technical deficiency lies in the server-side validation logic, which fails to enforce proper authorization checks before processing requests from authenticated users with low privileges. Instead of verifying that the requesting user possesses administrative rights or ownership over the specific department being modified, the application blindly accepts parameters supplied by the client side. This allows any authenticated account, regardless of its role hierarchy, to manipulate organizational structures across the entire system if they can guess or discover valid department identifiers.
From an operational perspective, this vulnerability enables significant disruption and potential compromise of enterprise data integrity. An attacker with a standard user account can rename departments, effectively obscuring their purpose or causing confusion within the organization's workflow. More critically, the ability to re-parent departments allows for the restructuring of the organizational hierarchy without authorization, which can disrupt reporting lines and access control policies that rely on departmental boundaries. Furthermore, the capability to replace or remove department heads grants attackers the power to alter leadership structures, potentially locking out legitimate administrators or installing malicious actors into positions of authority within specific units. This lack of tenant isolation in multi-tenant deployments exacerbates the risk, as a user from one tenant might theoretically impact departments belonging to another if proper cross-tenant checks are also absent, although the primary issue is the horizontal privilege escalation within the same tenant context.
The exploitation vector for this vulnerability aligns with ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials to perform unauthorized actions. The attack does not require complex injection techniques or buffer overflows; it relies solely on crafting a malicious HTTP PUT request with specific JSON payloads containing the target department ID and new attributes. This simplicity makes automated exploitation straightforward using standard web scraping tools or custom scripts. The impact extends beyond mere configuration changes, as altering department structures can indirectly affect data visibility and permissions if those are tied to organizational units rather than explicit role-based access controls.
Mitigation strategies must focus on implementing robust server-side authorization checks. Developers should ensure that every administrative endpoint verifies the requesting user's privileges against a centralized policy engine before executing state-changing operations. Specifically, for department modification endpoints, the system must validate that the authenticated user holds an administrator role or has explicit ownership of the target resource. Additionally, enforcing strict tenant isolation is essential in multi-tenant environments to prevent cross-tenant data manipulation. Upgrading to versions of JeecgBoot beyond 3.9.5 where this issue has been patched is the primary remediation step. In the interim, network-level controls such as Web Application Firewalls can be configured to restrict access to administrative endpoints based on user roles or IP addresses, although server-side validation remains the definitive fix for authorization flaws.