Summary
jshERP through version 3.6 does not properly validate user privileges when updating tenant system configuration. An authenticated user who can reach the systemConfig endpoint may modify or delete tenant-wide settings, affecting company identity, inventory rules, approval behavior, and printing configuration.
Affected context
The vulnerability occurs in deployments of jshERP through 3.6 where the
SystemConfigService.updateSystemConfig operation is accessible to
authenticated users without sufficiently specific authorization checks.
Risk depends on whether ordinary tenant users can invoke the systemConfig
endpoint and whether tenant configuration changes are enforced by server-side
privilege and scope controls.
Exploit preconditions
- Attack surface: The authenticated system configuration endpoint
- Required access: A valid user account with access to the affected application
- Trigger point: An update or delete operation handled by
updateSystemConfig - Why exploitation is possible: The application does not adequately verify
that the requesting user is authorized to change the targeted tenant-wide
configuration
Why this happens
The underlying flaw is an authorization gap in a state-changing service
operation. The application appears to authenticate the requester but does not
reliably enforce the required privilege and tenant-scope checks before applying
configuration changes. This maps to CWE-862: Missing Authorization, in
which access to a protected function is not adequately restricted after
authentication.
Potential impact
- An authenticated user could alter tenant-wide company identity settings
- Inventory or stock-control behavior could be changed unexpectedly
- Approval workflows could be weakened, disrupted, or redirected
- Printing configuration could be modified or removed
- Business operations and configuration integrity could be affected
- Other users could receive misleading or inconsistent application behavior
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the service layer
for every configuration update and deletion.
Common defensive patterns include:
- Applying deny-by-default permissions to administrative configuration actions
- Checking both the caller's role and the target tenant before changing state
- Enforcing authorization independently of client-supplied role or tenant values
- Separating read, update, and delete privileges where appropriate
- Validating configuration changes against an explicit server-side allowlist
- Using least-privilege roles and minimizing access to tenant-wide settings
- Recording and reviewing configuration changes with actor, tenant, and outcome details
How teams detect issues like this
Detection approaches can include:
- Static analysis for state-changing service methods lacking authorization
annotations, guards, or explicit permission checks
- Code review of every controller-to-service path that updates or deletes
tenant-wide data
- Tests that exercise administrative endpoints with ordinary authenticated
accounts and cross-tenant identifiers
- Runtime monitoring for unusual configuration changes or delete operations
- Policy enforcement requiring authorization checks for privileged API routes
- Neutral automated security review tools to identify missing access-control
checks and inconsistent tenant-boundary enforcement
