CVE-2026-108633 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 create department permission bindings via POST /sys/sysDepartPermission/add. Attackers can submit arbitrary departId, permissionId and dataRuleIds fields to attach menu, button and data rule grants to any department for delegation to its roles.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
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 application's administrative module. Specifically, this is an insecure direct object reference combined with missing function-level authorization on the endpoint responsible for managing department permissions. The affected API route POST /sys/sysDepartPermission/add is designed to associate specific menu items, button actions, and data rules with particular departments so that roles assigned to those departments inherit these privileges. However, the implementation fails to verify whether the authenticated user initiating the request possesses the necessary administrative rights or ownership of the target department identifier being modified. This oversight allows any low-privileged authenticated user who can access this endpoint to bypass intended security boundaries and manipulate permission structures across the system.
From a technical perspective, the flaw lies in the server-side logic that processes incoming requests for adding permissions. When a request is received containing parameters such as departId, permissionId, and dataRuleIds, the application directly binds these values without performing an authorization check against the current user's role hierarchy or administrative privileges. In secure implementations of role-based access control systems, operations affecting global configuration objects like department-permission mappings should be restricted to users with explicit admin roles. By omitting this verification step, the system treats all authenticated sessions as equally capable of modifying high-impact security configurations. This allows an attacker to craft a malicious HTTP POST request that assigns sensitive menu items or data access rules to any arbitrary department ID known to exist within the database.
The operational impact of this vulnerability is severe because it effectively grants attackers the ability to escalate their privileges and expand their attack surface arbitrarily. By binding high-level permissions to departments under which they might have indirect influence, or by creating new permission structures that facilitate further exploitation, an attacker can gain access to restricted administrative functions, view sensitive data belonging to other organizational units, or execute actions reserved for system administrators. This undermines the principle of least privilege and compromises the integrity of the entire authorization model. Since JeecgBoot is often used as a foundational framework for enterprise applications, this flaw could lead to widespread unauthorized access across multiple integrated systems if they rely on similar permission structures derived from this core module.
This vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization in the Common Weakness Enumeration taxonomy. It also maps closely to MITRE ATT&CK technique T1078 Valid Accounts, as it involves leveraging legitimate credentials to perform unauthorized actions, potentially leading to privilege escalation which falls under techniques such as T1078.003 Cloud Accounts or general account manipulation depending on the deployment context. The ability to modify permission bindings remotely via a web API highlights the risks associated with exposing administrative endpoints without robust server-side validation of user intent and authority levels.
To mitigate this vulnerability, developers must implement strict access control checks at the service layer before processing any requests to add department permissions. This involves verifying that the authenticated principal holds an administrator role or has explicit permission to manage the specific departId referenced in the request. Input validation should also be enforced to ensure that only valid and expected data structures are processed, although this alone does not resolve the authorization flaw. Upgrading to a patched version of JeecgBoot where these checks have been implemented is the primary remediation strategy. Additionally, organizations should review their API gateway configurations to restrict access to administrative endpoints based on IP whitelisting or additional authentication factors if possible, and conduct regular security audits focusing on role-based access control implementations in similar frameworks.