CVE-2026-94497: jshERP Authentication Bypass Vulnerability

CVE-2026-94497 Overview

CVE-2026-94497 is an Insecure Direct Object Reference (IDOR) vulnerability affecting jshERP through version 3.6. The application fails to validate object ownership in by-id info, update, and delete endpoints across multiple resource types. Authenticated users can submit direct object identifiers to read, modify, or delete business objects belonging to other tenants without triggering authorization checks. The flaw is classified under CWE-639: Authorization Bypass Through User-Controlled Key and results in horizontal privilege escalation across the enterprise resource planning platform.

Critical Impact

Any authenticated jshERP user can enumerate identifiers and read, alter, or delete other users' materials, inventory, and business records without additional privileges.

Affected Products

• jshERP through version 3.6
• MaterialController and related by-id endpoints in jshERP-boot
• Deployments derived from the jshERP open-source project

Discovery Timeline

• 2026-09-21 - CVE-2026-94497 published to NVD
• 2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-94497

Vulnerability Analysis

jshERP exposes REST endpoints that operate on business objects using numeric identifiers supplied by the client. The controllers accept the identifier and act on the corresponding record without confirming that the authenticated caller owns or is otherwise entitled to the object. This omission converts every authenticated session into an implicit administrative session over any object whose identifier can be guessed or enumerated. The scope covers read, update, and delete operations across multiple resource types, meaning attackers can exfiltrate business data, tamper with master records, or destroy records outright. Because the platform is used to manage materials, inventory, and financial records, cross-tenant tampering can disrupt downstream workflows that depend on the integrity of ERP data.

Root Cause

The root cause is missing object-level authorization in service and controller layers. Reference implementation code in MaterialController.java illustrates the pattern: the handler resolves the requested record by id and returns or mutates it without evaluating an ownership predicate against the current principal. The same pattern is repeated across sibling controllers, which is why the disclosure describes the flaw as spanning multiple resource types rather than a single endpoint.

Attack Vector

Exploitation requires network reachability to the jshERP API and a low-privileged authenticated session. An attacker authenticates with any valid account, then iterates numeric identifiers against the vulnerable info, update, and delete routes. Successful requests return or modify records owned by other users. A public proof of concept is published at the LinYuanyi1 cve-request-poc repository, and additional analysis is available in the VulnCheck advisory for jshERP.

Detection Methods for CVE-2026-94497

Indicators of Compromise

• Sequential or high-volume requests to jshERP by-id endpoints such as /material/info, /material/updateBatch, or /material/deleteBatch from a single session.
• Successful HTTP 200 responses to by-id requests targeting object identifiers not associated with the caller's tenant or business unit.
• Unexpected mutations or deletions of business records in jshERP audit logs originating from non-owner accounts.

Detection Strategies

• Instrument the jshERP application or a reverse proxy to log the authenticated user, requested object id, and record owner for every by-id call, then alert on mismatches.
• Baseline normal request patterns per user and flag rapid enumeration of monotonic identifiers against info, update, or delete routes.
• Correlate WAF, application, and database logs to identify authenticated sessions reading or writing records outside their assigned scope.

Monitoring Recommendations

• Forward jshERP access and application logs into a centralized analytics platform for cross-session behavioral analysis.
• Enable database-level audit logging on ERP tables to capture the actual principal responsible for row modifications.
• Track spikes in delete and update operations tied to low-privileged accounts and route them to the SOC for review.

How to Mitigate CVE-2026-94497

Immediate Actions Required

• Restrict network exposure of the jshERP API to trusted internal networks or VPN users until a patched build is deployed.
• Rotate credentials for accounts that may have been used to enumerate identifiers and disable dormant or shared accounts.
• Review recent modifications and deletions in ERP data and restore affected records from backup where tampering is suspected.

Patch Information

No vendor fix is referenced in the NVD entry at the time of publication. Monitor the jshERP project repository and the VulnCheck advisory for a version beyond 3.6 that introduces object-level authorization in the affected controllers.

Workarounds

• Deploy a reverse proxy or API gateway rule that validates the requested object id against the authenticated user's ownership records before forwarding to jshERP.
• Implement server-side authorization interceptors around by-id info, update, and delete handlers that reject requests where the caller does not own the target record.
• Reduce the blast radius by limiting account permissions to the minimum resource types required for each business role.

# Example NGINX rule to block unauthenticated enumeration of by-id endpoints
location ~ ^/(material|depot|supplier|account)/(info|updateBatch|deleteBatch) {
    if ($http_authorization = "") { return 401; }
    limit_req zone=jsherp_byid burst=5 nodelay;
    proxy_pass http://jsherp_backend;
}