CVE-2026-109181 in jshERP
Summary
by MITRE • 10/12/2026
jshERP through 3.6 contains an authorization bypass vulnerability that allows authenticated users restricted to personal or department data to list other users' bills by adding a purchaseStatus value. Attackers can include purchaseStatus=0 in the search JSON on GET /depotHead/list, causing DepotHeadService.select to drop the creator filter and expose all tenant purchase, sales and inventory bills.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in jshERP versions up to 3.6 represents a critical authorization bypass flaw that undermines the fundamental principle of least privilege within the application's data access layer. This security defect specifically affects authenticated users who are intended to operate under restricted scopes, such as viewing only their own personal records or those belonging to their specific department. The core technical issue stems from improper input validation and logic handling in the search functionality for depot head information. When a user initiates a request to list bills via the GET /depotHead/list endpoint, the application processes a JSON payload containing various filter parameters. Among these parameters is purchaseStatus, which dictates how results are filtered based on their current state or type.
The technical flaw arises because the backend service method DepotHeadService.select fails to properly enforce data isolation constraints when specific parameter values are provided. Specifically, if an attacker includes the value purchaseStatus=0 in the search JSON object, the application logic erroneously drops the creator filter that is normally applied to restrict results to the requesting user or their department. This bypass allows the database query to return all records associated with the tenant rather than just those authorized for the current session. Consequently, this leads to a severe information disclosure vulnerability where sensitive business data becomes accessible to unauthorized individuals within the same organizational unit.
The operational impact of this vulnerability is significant due to the nature of enterprise resource planning systems like jshERP. The exposed data includes purchase orders, sales invoices, and inventory records for all users in the tenant environment. This exposure can lead to competitive intelligence leakage, as attackers may gain insights into pricing strategies, supplier relationships, customer lists, and stock levels. Furthermore, access to such detailed financial and operational data violates regulatory compliance requirements related to data privacy and confidentiality, potentially resulting in legal liabilities and reputational damage for the affected organization. The ability to enumerate all bills also facilitates further attacks by providing attackers with a comprehensive map of the system's business logic and potential targets for more sophisticated exploits.
From an industry standard perspective, this vulnerability aligns closely with CWE-285 Improper Authorization, as it involves failing to enforce proper access controls on resources based on user identity or role. Additionally, it can be mapped to ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials but exploit logic flaws to escalate their effective privileges and access data beyond their intended scope. The specific mechanism of manipulating input parameters to alter query behavior also reflects characteristics often seen in CWE-915 Improper Control of Dynamically-Managed Code Resources or general injection vulnerabilities depending on how the JSON is parsed, though the primary issue here is logical authorization failure rather than code execution.
To mitigate this vulnerability, immediate remediation should focus on enforcing strict server-side validation and access control checks for all data retrieval endpoints. Developers must ensure that user identity and role-based permissions are re-evaluated after any parameter manipulation to guarantee that results remain within the authorized scope of the requesting user. Implementing robust input sanitization is essential, but more importantly, the application logic should explicitly apply creator or department filters regardless of other search parameters like purchaseStatus. Security testing procedures should include automated checks for broken object level permissions (BOLA) by attempting to access resources belonging to different users through parameter tampering. Regular code reviews focusing on data access layers and continuous monitoring for anomalous query patterns can further help in detecting and preventing such exploitation attempts before they lead to significant data breaches.