Summary
JeecgBoot through version 3.9.5 contains a missing authorization flaw in the saveDeptRolePermission endpoint. An authenticated, low-privileged user may modify department role permissions, potentially granting unauthorized menu or button access or revoking permissions assigned to others.
JeecgBoot through version 3.9.5 contains a missing authorization flaw in the saveDeptRolePermission endpoint. An authenticated, low-privileged user may modify department role permissions, potentially granting unauthorized menu or button access or revoking permissions assigned to others.
Affected context
The vulnerability occurs in JeecgBoot deployments that expose the SysDepartPermissionController saveDeptRolePermission endpoint and rely on endpoint-level authentication without sufficiently verifying whether the requesting user may administer the targeted department role. The risk is greatest where ordinary authenticated users can reach this operation and supply roleId or permissionIds values.
The vulnerability occurs in JeecgBoot deployments that expose the SysDepartPermissionController saveDeptRolePermission endpoint and rely on endpoint-level authentication without sufficiently verifying whether the requesting user may administer the targeted department role. The risk is greatest where ordinary authenticated users can reach this operation and supply roleId or permissionIds values.
Exploit preconditions
- Attack surface: The authenticated web or API endpoint
saveDeptRolePermission
- Required access: A valid authenticated account; elevated administrative
privileges may not be required
- Trigger point: Submission of department role and permission identifiers
to SysDepartPermissionController
- Why exploitation is possible: The endpoint does not adequately enforce
authorization for the requested role and permission changes
- Attack surface: The authenticated web or API endpoint
saveDeptRolePermission
- Required access: A valid authenticated account; elevated administrative
privileges may not be required
- Trigger point: Submission of department role and permission identifiers
to SysDepartPermissionController
- Why exploitation is possible: The endpoint does not adequately enforce
authorization for the requested role and permission changes
Why this happens
The underlying bug is an authorization design failure in which authentication is treated as sufficient permission to perform a sensitive administrative action. The endpoint accepts role and permission references without reliably checking whether the caller is authorized to modify the targeted department or role. This behavior maps to CWE-862, Missing Authorization, because access control enforcement is absent or incomplete for a protected operation.
The underlying bug is an authorization design failure in which authentication is treated as sufficient permission to perform a sensitive administrative action. The endpoint accepts role and permission references without reliably checking whether the caller is authorized to modify the targeted department or role. This behavior maps to CWE-862, Missing Authorization, because access control enforcement is absent or incomplete for a protected operation.
Potential impact
- An attacker may grant unauthorized menu or button permissions
- An attacker could escalate access within the application
- Existing permissions may be revoked or altered for other users
- Department-level access controls may be bypassed
- Unauthorized changes could affect confidentiality, integrity, or availability
of business functions
- An attacker may grant unauthorized menu or button permissions
- An attacker could escalate access within the application
- Existing permissions may be revoked or altered for other users
- Department-level access controls may be bypassed
- Unauthorized changes could affect confidentiality, integrity, or availability
of business functions
General mitigation guidance
Mitigation generally centers on enforcing authorization at the server-side
operation boundary rather than relying on authentication or client-side
controls.
Common defensive patterns include:
- Applying deny-by-default authorization to permission-management endpoints
- Verifying that the caller may administer the targeted department and role
- Checking both the requested role scope and each requested permission
- Treating roleId and permissionIds as untrusted references
- Using centralized, consistently applied authorization policies
- Restricting administrative capabilities according to least privilege
- Recording and reviewing permission changes for accountability
- Returning uniform responses that do not disclose unauthorized resource
details
Mitigation generally centers on enforcing authorization at the server-side
operation boundary rather than relying on authentication or client-side
controls.
Common defensive patterns include:
- Applying deny-by-default authorization to permission-management endpoints
- Verifying that the caller may administer the targeted department and role
- Checking both the requested role scope and each requested permission
- Treating roleId and permissionIds as untrusted references
- Using centralized, consistently applied authorization policies
- Restricting administrative capabilities according to least privilege
- Recording and reviewing permission changes for accountability
- Returning uniform responses that do not disclose unauthorized resource
details
How teams detect issues like this
Organizations commonly look for this issue through:
- Static analysis of controller methods that mutate roles or permissions
- Code review checks for authentication checks without resource authorization
- Tests using ordinary accounts against administrative endpoints
- Policy checks requiring authorization before role or permission updates
- Audit monitoring for unusual permission changes or cross-department updates
- Automated API security testing that evaluates horizontal and vertical access
control boundaries
Organizations commonly look for this issue through:
- Static analysis of controller methods that mutate roles or permissions
- Code review checks for authentication checks without resource authorization
- Tests using ordinary accounts against administrative endpoints
- Policy checks requiring authorization before role or permission updates
- Audit monitoring for unusual permission changes or cross-department updates
- Automated API security testing that evaluates horizontal and vertical access
control boundaries
