Description

jshERP through 3.6 contains an authorization bypass vulnerability that allows authenticated users to create pre-approved bills by setting status in POST /depotHead/addDepotHeadAndDetail requests. Attackers can supply a status of 1 to skip audit permission checks and multi-level approval workflows, creating audited bills that affect stock and report queries.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-10-12T13:17:31.497Z",
  "pubdate": "2026-10-12T13:17:31.497Z",
  "executiveSummary": "jshERP versions through 3.6 are susceptible to an authorization bypass vulnerability within the bill processing module. The vulnerability originates from improper server-side validation of input parameters during the creation of depot head records. By manipulating the 'status' field in a POST request, an authenticated attacker can bypass mandatory administrative audit permissions and multi-level approval workflows.\nThe vulnerability allows an attacker to inject pre-approved financial or inventory bills directly into the system's ledger. Consequently, these manipulated bills immediately impact stock levels and financial reporting queries without oversight. This flaw undermines the integrity of internal accounting controls and inventory management. Exploitation requires an authenticated user account, but the vulnerability effectively grants unauthorized administrative privilege to bypass institutional verification processes.\nGiven that this vulnerability allows for the silent modification of critical business records and stock data, it poses a significant risk to organizational data integrity and operational security. System administrators should treat this as a high-priority concern, as it permits unauthorized state changes that are typically guarded by role-based access control (RBAC) mechanisms.",
  "technicalDetails": "The vulnerability is situated within the request handling logic of the /depotHead/addDepotHeadAndDetail endpoint in jshERP versions through 3.6. The root cause is an insecure implementation of state management where the application trusts user-supplied input to determine the authorization status of a bill.\nSpecifically, when a user submits a POST request to add a depot head and its associated details, the application parses the 'status' parameter to determine the state of the transaction. The backend logic fails to verify if the requesting user possesses the necessary permissions to promote a bill to an 'audited' status. Instead, the application accepts the input as a definitive instruction for the database state.\nThe attack flow proceeds as follows: First, an authenticated attacker initiates a standard bill creation process by constructing a POST request directed at the /depotHead/addDepotHeadAndDetail URI. Within the JSON payload or form data, the attacker explicitly sets the 'status' field to '1'.\nUpon receiving the request, the application backend processes the creation of the record in the database using the provided status. Because the server-side logic lacks a secondary validation check to ensure that a non-privileged user has not submitted a status indicating pre-approval, the bill is written to the database with an 'audited' flag. This action effectively tricks the system into bypassing the internal approval workflows—including manual audits and multi-level verification processes—that are otherwise enforced for bills with a status indicating pending approval.\nThe impact of this exploitation is immediate and persistent. Once the record is inserted with the malicious status, it becomes visible in system reports and directly influences current stock levels. This allows an attacker to perform unauthorized inventory adjustments or financial record manipulation, potentially concealing illicit physical stock movements or inflating/deflating ledger balances. Since these records are pre-approved, they evade the scrutiny of the audit logs that would typically flag manual overrides, and the changes are treated as legitimate system operations by the database and front-end dashboard modules."
}