CVE-2026-109182 in jshERP
Summary
by MITRE • 10/12/2026
jshERP through 3.6 contains an incorrect authorization vulnerability in GET /supplier/exportExcel that allows authenticated users to bypass role data scope restrictions enforced by /supplier/list. Attackers restricted to personal or department data can export every supplier, customer and member record, exposing contacts, phone numbers, tax numbers, bank accounts and balances.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
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-285: Improper Authorization. This flaw manifests within the application's supplier management module, where the endpoint GET /supplier/exportExcel fails to enforce the same data scope restrictions that are correctly applied to the listing interface at /supplier/list. In enterprise resource planning systems like jshERP, role-based access control is essential for maintaining data integrity and privacy. The system distinguishes between users with full administrative privileges and those restricted to viewing only their own records or those within their specific departmental unit. While the list endpoint correctly filters results based on these user roles, the export functionality operates independently of this logic, creating a significant security gap that allows authenticated but unauthorized users to access sensitive data beyond their permitted scope.
From an operational perspective, this vulnerability enables a direct bypass of role-based data isolation policies. An attacker who has valid credentials for a low-privilege account, such as a junior sales representative or departmental manager restricted to personal or team-level visibility, can manipulate the HTTP request directed at the export endpoint. By invoking GET /supplier/exportExcel without providing any specific filtering parameters that would limit the result set, the backend process retrieves and packages all supplier records into an Excel file rather than just those relevant to the user's role. This behavior indicates a lack of server-side validation for data scope during the generation of downloadable reports. The absence of checks ensuring that the exported dataset aligns with the authenticated user’s permissions constitutes a classic insecure direct object reference scenario where the application trusts client-supplied context or fails to re-evaluate authorization policies before performing high-impact actions like bulk data extraction.
The impact of this vulnerability is severe due to the nature and volume of data exposed. The export functionality aggregates comprehensive records for suppliers, customers, and members, which typically contain highly sensitive personally identifiable information and financial details. Successful exploitation results in the mass exfiltration of contact names, direct phone numbers, tax identification numbers, bank account coordinates, and current balance sheets. This exposure not only violates privacy regulations such as GDPR or CCPA but also facilitates further attacks including social engineering, corporate espionage, and financial fraud. The ability to download entire databases in a structured format significantly lowers the barrier for attackers compared to manual scraping of web pages, allowing them to quickly analyze patterns, identify high-value targets within the client base, and potentially use this information for targeted phishing campaigns or credential stuffing attempts against other systems where users may reuse passwords.
To mitigate this vulnerability, developers must implement strict server-side authorization checks on all data export endpoints that mirror the logic used in standard listing operations. The application should validate the current user’s role and associated data scope before initiating any bulk data retrieval process. Specifically, when generating Excel files via GET /supplier/exportExcel, the backend service must query the database using filters derived from the authenticated session's permissions, ensuring that only records accessible to that specific user are included in the export bundle. Additionally, implementing rate limiting on export endpoints can help prevent abuse and reduce the impact of potential data scraping attempts. Security testing should include automated checks for broken object level authorization by attempting to access resources belonging to other users or departments through various API methods, ensuring consistent enforcement of access controls across all application functions as recommended by OWASP guidelines for insecure direct object references.