Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-10-12T13:17:31.327Z",
  "pubdate": "2026-10-12T13:17:31.327Z",
  "executiveSummary": "jshERP versions up to 3.6 contain an incorrect authorization vulnerability within the supplier data export functionality.\nThe vulnerability resides in the GET /supplier/exportExcel endpoint, which fails to enforce role-based data scope restrictions that are correctly applied in the /supplier/list interface.\nThis flaw allows an authenticated user, even one with restricted permissions (e.g., restricted to personal or departmental data), to bypass authorization logic and retrieve the entire database of suppliers, customers, and members.\nThe impact is significant, leading to the unauthorized disclosure of sensitive business information, including contact names, phone numbers, tax identification numbers, bank account details, and financial balances.\nThe attack requires valid authentication but does not necessitate elevated administrative privileges, posing a high risk for data privacy and corporate espionage.\nThe vulnerability highlights a critical inconsistency in access control policy enforcement between different functional modules of the application.",
  "technicalDetails": "The vulnerability is rooted in an inconsistent authorization implementation between the API endpoints responsible for data visualization and data export.\nIn the jshERP application, the /supplier/list endpoint correctly implements a data scope filter, restricting query results to records permitted by the authenticated user's assigned role (e.g., personal or department-level visibility).\nHowever, the GET /supplier/exportExcel endpoint lacks equivalent backend authorization checks. When a request is made to this endpoint, the application fails to validate the user's data access boundaries before initiating the database query for the Excel export generation.\nThis allows an authenticated user to perform an Insecure Direct Object Reference (IDOR) or a broader authorization bypass by requesting the export of the entire supplier set regardless of their assigned scope.\nThe attack flow proceeds as follows: 1) An attacker authenticates to the application using valid credentials with standard or restricted user privileges. 2) The attacker identifies that the application supports Excel exports via the GET /supplier/exportExcel endpoint. 3) The attacker submits an unauthenticated or minimally constrained request to this endpoint. 4) The server-side component fails to verify if the requester's user ID or role is authorized to view the requested data scope. 5) The server processes the query and generates an Excel file containing global recordsets, effectively bypassing the business logic that governs access control in other parts of the system.\nThe exploitation does not require advanced technical skill or complex payloads, as the vulnerability is a failure of server-side state enforcement rather than a injection-based flaw.\nThe post-exploitation impact includes the full exposure of personally identifiable information (PII) and highly sensitive financial records. By downloading the exported spreadsheet, an attacker gains unauthorized access to corporate tax data, private communication details, and institutional financial health indicators, which can be leveraged for further target reconnaissance, spear-phishing, or financial fraud."
}