Summary
jshERP contains a missing authorization vulnerability in the user status management endpoint, allowing authenticated low-privilege users to change the account status of other users. Under tenant-level access, an attacker may disable non-owner accounts, including administrators, or re-enable accounts that were intentionally disabled.
jshERP contains a missing authorization vulnerability in the user status management endpoint, allowing authenticated low-privilege users to change the account status of other users. Under tenant-level access, an attacker may disable non-owner accounts, including administrators, or re-enable accounts that were intentionally disabled.
Affected context
The issue occurs in jshERP deployments where the POST /user/batchSetStatus endpoint is accessible to authenticated users but does not sufficiently verify whether the caller is authorized to modify each submitted account identifier. Risk is increased when tenant user-management operations rely on client-supplied identifiers without enforcing server-side ownership, role, or administrative-scope checks.
The issue occurs in jshERP deployments where the POST /user/batchSetStatus endpoint is accessible to authenticated users but does not sufficiently verify whether the caller is authorized to modify each submitted account identifier. Risk is increased when tenant user-management operations rely on client-supplied identifiers without enforcing server-side ownership, role, or administrative-scope checks.
Exploit preconditions
- Attack surface: The authenticated user-management API endpoint
- Required access: A valid account with sufficient access to reach the endpoint; administrative privileges may not be required
- Trigger point: Submission of a request containing target user identifiers and an account-status value
- Why exploitation is possible: The endpoint does not adequately enforce authorization for each targeted account before applying the requested status change
- Attack surface: The authenticated user-management API endpoint
- Required access: A valid account with sufficient access to reach the endpoint; administrative privileges may not be required
- Trigger point: Submission of a request containing target user identifiers and an account-status value
- Why exploitation is possible: The endpoint does not adequately enforce authorization for each targeted account before applying the requested status change
Why this happens
The underlying bug is an authorization check that is missing, incomplete, or applied only to the request as a whole rather than to every targeted user. When server-side logic trusts client-supplied identifiers and status changes without validating tenant scope, role permissions, and target ownership, a low-privilege principal can perform an administrative operation. This behavior maps to CWE-862, Missing Authorization.
The underlying bug is an authorization check that is missing, incomplete, or applied only to the request as a whole rather than to every targeted user. When server-side logic trusts client-supplied identifiers and status changes without validating tenant scope, role permissions, and target ownership, a low-privilege principal can perform an administrative operation. This behavior maps to CWE-862, Missing Authorization.
Potential impact
- Attackers may disable administrator or other privileged accounts
- A tenant may experience denial of service because legitimate users are locked out
- Attackers may re-enable accounts that were intentionally disabled
- Account-management auditability and administrative control may be undermined
- Repeated abuse could disrupt tenant operations and incident response
- Attackers may disable administrator or other privileged accounts
- A tenant may experience denial of service because legitimate users are locked out
- Attackers may re-enable accounts that were intentionally disabled
- Account-management auditability and administrative control may be undermined
- Repeated abuse could disrupt tenant operations and incident response
General mitigation guidance
Mitigation generally focuses on enforcing authorization on the server for
every target account and every requested status transition.
Common defensive patterns include:
- Applying deny-by-default authorization to user-management operations
- Verifying the caller's role, tenant scope, and permitted target set server-side
- Rejecting bulk requests that include unauthorized or cross-tenant identifiers
- Separating ordinary user actions from administrator-only account-status changes
- Enforcing safe state-transition rules, especially for privileged and owner accounts
- Avoiding reliance on client-provided role, tenant, or permission values
- Using least privilege and preserving tamper-resistant audit records for status changes
Mitigation generally focuses on enforcing authorization on the server for
every target account and every requested status transition.
Common defensive patterns include:
- Applying deny-by-default authorization to user-management operations
- Verifying the caller's role, tenant scope, and permitted target set server-side
- Rejecting bulk requests that include unauthorized or cross-tenant identifiers
- Separating ordinary user actions from administrator-only account-status changes
- Enforcing safe state-transition rules, especially for privileged and owner accounts
- Avoiding reliance on client-provided role, tenant, or permission values
- Using least privilege and preserving tamper-resistant audit records for status changes
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis and policy checks for endpoints that update user records without nearby authorization enforcement
- Code review of bulk-update handlers, identifier-based object access, and tenant-boundary checks
- Authorization tests using low-privilege accounts against administrator, cross-tenant, and disabled-user targets
- API monitoring for unusual bursts of account-status changes or requests containing many user identifiers
- Automated security testing that verifies deny-by-default behavior for every object in a bulk request
Organizations commonly detect this class of issue through:
- Static analysis and policy checks for endpoints that update user records without nearby authorization enforcement
- Code review of bulk-update handlers, identifier-based object access, and tenant-boundary checks
- Authorization tests using low-privilege accounts against administrator, cross-tenant, and disabled-user targets
- API monitoring for unusual bursts of account-status changes or requests containing many user identifiers
- Automated security testing that verifies deny-by-default behavior for every object in a bulk request
