CVE-2026-109184 in jshERP
Summary
by MITRE • 10/12/2026
jshERP through 3.6 contains an improper authorization vulnerability that allows low-privilege authenticated users to read any settlement account ledger by supplying an arbitrary accountId. Attackers restricted to personal or department data scope can query GET /account/findAccountInOutList to view other users' bill numbers, counterparties, amounts and remarks within the tenant.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in jshERP versions through 3.6 represents a critical failure in server-side access control mechanisms, specifically categorized under CWE-284 Improper Access Control. This flaw manifests as an Insecure Direct Object Reference (IDOR) issue within the application's financial module. The core technical deficiency lies in the endpoint GET /account/findAccountInOutList, which processes requests containing an accountId parameter without performing adequate authorization checks against the requesting user’s assigned permissions or data scope. While the system correctly restricts users from viewing sensitive administrative configurations based on their role, it fails to validate whether the specific financial record being requested belongs to a resource that the authenticated user is permitted to access. This allows low-privilege authenticated users, who are typically restricted by business logic to view only personal or department-specific data, to bypass these restrictions entirely by manipulating input parameters.
From an operational perspective, this vulnerability enables unauthorized disclosure of sensitive financial information within a multi-tenant environment. An attacker with valid credentials but limited privileges can iterate through arbitrary account identifiers to retrieve detailed ledger entries for other users or departments within the same tenant instance. The exposed data includes bill numbers, counterparty details, transaction amounts, and internal remarks, all of which constitute highly confidential business intelligence. This breach compromises not only individual privacy but also organizational integrity by exposing financial workflows and potential fraud indicators to unauthorized parties. In a SaaS context where multiple organizations share infrastructure, this flaw could potentially be leveraged for cross-tenant data leakage if tenant isolation is weakly enforced at the database level, although the primary impact described is intra-tenant data exfiltration.
The exploitation of this vulnerability aligns with MITRE ATT&CK technique T1078 Valid Accounts and specifically relates to lateral movement or information gathering phases where an attacker uses legitimate credentials to access resources outside their intended scope. The lack of object-level authorization checks means that the application relies solely on client-side restrictions or implicit trust in user input, which is a fundamental security anti-pattern. Attackers can automate this process using simple scripts to enumerate valid account IDs and harvest financial data systematically. This poses significant risks including competitive espionage, regulatory non-compliance with standards such as GDPR or SOX due to unauthorized access of personal and financial records, and potential reputational damage for the affected organizations.
To mitigate this vulnerability, developers must implement strict server-side authorization checks that validate the relationship between the authenticated user’s identity and the requested resource identifier before processing any data retrieval requests. The application logic should ensure that a user can only query ledger entries associated with their own profile or explicitly authorized departments. Implementing role-based access control (RBAC) at the object level is essential, ensuring that every API endpoint verifies permissions against the specific entity being accessed rather than just general module access. Additionally, employing indirect reference maps where internal database IDs are replaced with opaque, randomized identifiers can reduce the risk of enumeration attacks by making it difficult for attackers to guess valid account IDs. Regular security audits and static code analysis focused on authorization logic should be integrated into the development lifecycle to prevent similar flaws in other modules.