Description

jshERP through 3.6 fails to validate object ownership in by-id info, update, and delete endpoints across multiple resource types. Authenticated users can read, modify, and delete other users' business objects by submitting direct object identifiers without authorization checks.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.3",
  "pubDate": "2026-09-21T19:17:21.743Z",
  "pubdate": "2026-09-21T19:17:21.743Z",
  "executiveSummary": "jshERP versions up to and including 3.6 contain a critical Insecure Direct Object Reference (IDOR) vulnerability.\nThe vulnerability originates from a failure to perform server-side authorization checks when processing requests to access, modify, or delete business objects via ID-based endpoints.\nAuthenticated users can manipulate object identifiers within API requests to perform unauthorized operations on data belonging to other users.\nThe impact includes full unauthorized read, update, and delete access to sensitive business records, posing a severe risk to data confidentiality, integrity, and availability.\nSuccessful exploitation requires the attacker to be an authenticated user of the system; no further administrative privileges are necessary to bypass access controls.\nThe vulnerability allows for horizontal privilege escalation, enabling malicious actors to interact with arbitrary business objects across the platform.",
  "technicalDetails": "The vulnerability is classified as an Insecure Direct Object Reference (IDOR), occurring because the application relies on client-provided object identifiers without verifying if the requesting user possesses the necessary permissions to access or modify the specified resource.\nThe affected components are the info, update, and delete endpoints across multiple resource types within the jshERP application. These endpoints accept direct identifiers (e.g., primary keys or database record IDs) as parameters for object interaction.\nIn a standard secure implementation, the application should validate that the authenticated user ID is associated with the requested business object ID in the backend database or authorization service. In jshERP, this verification step is omitted entirely.\nThe attack flow proceeds as follows: 1. An authenticated attacker identifies a valid object ID of a target resource through legitimate application usage or reconnaissance. 2. The attacker constructs an HTTP request (GET, POST, or DELETE) targeting an object-specific endpoint, substituting the intended target's ID into the parameter list. 3. The server receives the request, identifies the authenticated session, but fails to cross-reference the user's authority over the target ID. 4. The server executes the operation (fetching sensitive data, updating parameters, or deleting records) against the resource belonging to another user.\nBecause the application assumes that the possession of an ID constitutes legitimate access, the backend logic proceeds to perform database queries or updates without enforcing scope restrictions. This allows an attacker to iterate through sequential or discoverable IDs to harvest large amounts of data, alter business transactions, or cause data loss through unauthorized deletions.\nThe vulnerability affects all versions of jshERP through 3.6 and is present across the API surface where ID-based parameters are used for resource management. There is no specific network restriction required, as the vulnerability is inherent to the application's business logic layer regardless of the network entry point, provided the attacker has valid authentication credentials.\nPost-exploitation, an attacker can maintain persistent access to sensitive business records, manipulate financial or inventory data, or disrupt business operations by purging critical database objects."
}