CVE-2026-109180 in jshERP
Summary
by MITRE • 10/12/2026
jshERP through 3.6 contains an authorization bypass vulnerability that allows authenticated users to read data from unassigned warehouses by supplying depotId or depotIds request parameters. When depot_flag warehouse restriction is enabled, attackers can name arbitrary warehouse ids in endpoints like /depotItem/getMaterialDepotStockByParam to read stock levels, batch numbers, sales figures and priced bill lines within the tenant.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
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 security principle of least privilege by allowing authenticated users to access data belonging to unassigned warehouses. This issue specifically arises when the system employs depot_flag warehouse restrictions, a feature designed to isolate inventory and financial data between different operational units or tenants within a multi-tenant architecture. Despite this restriction being enabled, the application fails to properly validate whether the requesting user has legitimate ownership or permission for the specific warehouse identifiers provided in the request parameters. By manipulating input fields such as depotId or depotIds, an attacker can bypass these logical access controls and retrieve sensitive information from warehouses that should remain inaccessible to them.
From a technical perspective, this vulnerability is classified under CWE-284 Improper Access Control, specifically reflecting issues with authorization logic where the server does not enforce proper checks on resource ownership before returning data. The exploitation vector involves sending crafted HTTP requests to endpoints like /depotItem/getMaterialDepotStockByParam, which are intended to return stock levels and related inventory details based on a specified warehouse identifier. Because the backend processing of these parameters lacks sufficient validation against the user's assigned permissions or tenant boundaries, the application returns data for any depotId supplied by the client, regardless of whether that ID corresponds to a resource authorized for the current session. This behavior effectively neutralizes the intended isolation mechanisms provided by the depot_flag configuration.
The operational impact of this vulnerability is severe due to the sensitivity of the exposed data types. Attackers can extract comprehensive inventory details including stock levels and batch numbers, which are critical for supply chain integrity and quality control processes. Furthermore, the ability to access sales figures and priced bill lines exposes high-value financial information that could be used for competitive intelligence or further fraudulent activities within the organization. In a multi-tenant environment, this breach of isolation means that one tenant's confidential business metrics can be exfiltrated by another tenant who has valid authentication credentials but no legitimate reason to view such data. This compromises both confidentiality and potentially integrity if attackers use this information to manipulate market perceptions or internal decision-making processes based on stolen financial insights.
This type of vulnerability aligns with the MITRE ATT&CK technique T1078 Valid Accounts, as it relies on existing authentication credentials to gain unauthorized access to resources. It also relates to T1530 Data from Cloud Storage Object if the underlying data storage is accessed via cloud-based object identifiers that are not properly scoped. To mitigate this risk, developers must implement strict server-side authorization checks for all endpoints handling warehouse-specific data. This involves verifying that the depotId or depotIds parameter corresponds directly to a resource explicitly assigned to the authenticated user's tenant and role profile before processing the request. Additionally, implementing automated security testing focused on horizontal privilege escalation can help identify similar flaws in other parts of the application logic where object-level permissions are not rigorously enforced.