jshERP CVE-2026-109183

Requires a valid authenticated jshERP session with permission to reach the POST /depotHead/addDepotHeadAndDetail endpoint (any low-privilege user per PR:L); no admin or auditor role is needed. The specific abuse is supplying status=1 in the request body, which the server trusts instead of enforcing the audit/approval permission check, so the bill is created in an already-approved state. Exploitation is limited to accounts that can authenticate to the application and submit depot-head (inventory bill) creation requests; it does not work pre-authentication, requires no user interaction from a victim, and affects jshERP deployments through version 3.6.

This is a medium-severity authorization bypass (CWE-862) with a modest real-world priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 and is internally consistent with the description: network-reachable, low complexity, but requiring an already-authenticated low-privilege account (PR:L), with impact limited to integrity (VI:L) - no confidentiality or availability loss. Publicly available exploit code exists (POC referenced), which raises operational concern, but there is no CISA KEV listing and no EPSS score was provided, so there is no evidence of widespread or active exploitation - the absence of these signals, combined with the authenticated prerequisite, points to opportunistic/insider misuse rather than mass exploitation. No conflicting signals are present: the CVSS vector, the description, and the CWE all agree this is a logic/authorization flaw abusable by a legitimate but under-privileged user. The main caveat is that the impact (silently creating pre-approved bills that affect stock levels and report queries) is a business-integrity/financial-control problem that a raw 5.3 may understate for organizations relying on jshERP's approval workflow for inventory governance.

A low-privileged but authenticated jshERP user (e.g., a basic warehouse or data-entry account) sends a crafted POST to /depotHead/addDepotHeadAndDetail with status set to 1, causing the bill to be recorded as already audited/approved. This bypasses the multi-level approval workflow and audit permission checks, so the attacker-created bill immediately affects stock quantities and downstream report queries. A public proof-of-concept script (poc_depothead_write_and_derived_read.py) demonstrates both the privileged write and the resulting derived-data read.