Summary
jshERP through version 3.6 does not consistently verify that an authenticated user owns or is authorized to access a business object referenced by its identifier. An authenticated user who can submit another object's identifier may be able to read, modify, or delete that object through affected endpoints.
Affected context
The vulnerability occurs in jshERP endpoints that retrieve, update, or delete resources by direct object identifier. It becomes risky when endpoint logic authenticates the requester but does not also enforce ownership, tenant boundaries, or an equivalent authorization relationship for the referenced object.
Exploit preconditions
- Attack surface: By-ID information, update, and delete endpoints across affected resource types
- Required access: An authenticated jshERP account able to reach the endpoints
- Trigger point: A request that references a business object by identifier
- Why exploitation is possible: The server processes the identifier without reliably checking whether the requester owns or is authorized to access the referenced object
Why this happens
The underlying bug is a failure of object-level authorization. Endpoint handlers use a client-supplied object identifier to locate a resource, but authorization decisions are not consistently bound to the authenticated user's identity, role, organization, or ownership relationship. This pattern maps to CWE-639, Authorization Bypass Through User-Controlled Key, commonly called insecure direct object reference.
Potential impact
- Unauthorized users may read other users' business data
- Attackers may modify records belonging to other users
- Attackers may delete business objects without proper authorization
- Data integrity, confidentiality, and operational continuity could be affected
- Cross-tenant or cross-account access may occur where isolation controls are absent
General mitigation guidance
Mitigation generally centers on enforcing object-level authorization on every read, update, and delete operation. Secure-by-default patterns include resolving resources through the authenticated user's authorized scope, applying server-side ownership or tenant predicates, denying access unless an explicit permission relationship exists, and avoiding reliance on client-supplied identifiers alone. Authorization checks should occur before returning or mutating data, and service accounts and user roles should receive only the privileges required for their business functions.
How teams detect issues like this
Detection can include static analysis and code review searches for endpoints that accept object identifiers and perform database access without nearby authorization or ownership predicates. Review signals include generic by-id handlers, direct repository lookups based only on request parameters, and authorization checks performed only at login or route level. Automated tests and policy checks can verify that users from different accounts or tenants cannot access, modify, or delete one another's resources.
