CVE-2026-108634 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 delete department permission bindings via the DELETE /sys/sysDepartPermission/deleteBatch endpoint. Attackers can obtain row ids from the unguarded list endpoint and submit them in the ids parameter to remove menus and buttons departments can grant to their roles.
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 within JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms, specifically classified as an insecure direct object reference or broken access control issue. This flaw resides in the backend API endpoint responsible for managing departmental permissions, namely DELETE /sys/sysDepartPermission/deleteBatch. The core technical deficiency lies in the absence of proper authorization checks on this specific HTTP method and path combination. While the application correctly implements authentication to verify user identity, it fails to validate whether the authenticated user possesses sufficient privileges to execute administrative actions related to system configuration. This architectural oversight allows any low-privileged authenticated user to interact with endpoints that should be restricted exclusively to high-level administrators or security managers who are responsible for maintaining the integrity of role-based access control structures.
The operational impact of this vulnerability is significant, as it enables attackers to dismantle the foundational permissions that govern how departments grant access to their respective roles. By exploiting the unguarded list endpoint, an attacker can first enumerate valid row identifiers associated with department permission bindings. These identifiers are typically exposed in plain text or easily predictable formats within standard API responses used for administrative dashboards. Once these unique identifiers are obtained, they can be submitted via the ids parameter of the deleteBatch endpoint to systematically remove critical menu items and button-level permissions. This action effectively strips departments of their ability to assign specific functionalities to roles, potentially leading to a denial of service for legitimate users who rely on those features or creating confusion in access management workflows that could mask further malicious activities.
From a threat modeling perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, and specifically relates to the concept where an actor is able to read or modify data belonging to another user due to insufficient enforcement of authorization policies. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior maps directly to T1078 Valid Accounts, as it requires valid credentials, and more precisely to techniques involving privilege escalation or defense evasion through the manipulation of access control lists. The ability to modify permission bindings allows an attacker to potentially escalate privileges by removing restrictions that prevent lower-level users from accessing sensitive modules, thereby expanding their foothold within the application environment without needing additional exploits for credential theft or injection attacks.
Mitigation strategies must focus on implementing robust server-side authorization checks at every level of the request processing pipeline. Developers should ensure that all administrative endpoints, particularly those modifying system configuration data like permission bindings, enforce strict role-based access control policies. It is essential to verify not only that a user is authenticated but also that their assigned role explicitly permits modification of departmental permissions. Additionally, implementing principle of least privilege ensures that low-privileged users are denied access to management interfaces entirely rather than relying on client-side restrictions which can be easily bypassed. Input validation should also include checking if the requested resource belongs to a domain or organization for which the user has administrative rights, preventing unauthorized cross-departmental manipulation. Regular security audits and static code analysis tools configured to detect missing authorization checks in RESTful API endpoints are recommended to prevent similar vulnerabilities from being introduced during future development cycles.