CVE-2026-94414 in jshERP
Summary
by MITRE • 09/21/2026
jshERP through 3.6 is missing an authorization check on the POST /userBusiness/updateBtnStr endpoint that allows authenticated users to modify role button-permission definitions. Attackers can supply arbitrary roleId and btnStr parameters to overwrite button-permission configurations for any role in the tenant without privilege validation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in jshERP versions up to 3.6 represents a critical failure in access control mechanisms, specifically categorized under CWE-284 Improper Access Control. This flaw resides within the POST /userBusiness/updateBtnStr endpoint, which is designed to update button permission strings for user roles. The core technical deficiency lies in the absence of an authorization check that validates whether the authenticated user initiating the request possesses the necessary privileges to modify role definitions. In a properly secured system, such administrative operations should be restricted to users with specific high-level roles, such as administrators or security managers, and must verify that the target roleId belongs to a context where the requester has modification rights. However, in this implementation, the server processes the request based solely on the presence of valid authentication credentials, ignoring any role-based permissions associated with the user account making the call.
From an operational perspective, this vulnerability allows authenticated attackers to perform unauthorized privilege escalation and configuration tampering within a multi-tenant environment. By supplying arbitrary roleId parameters alongside manipulated btnStr values, an attacker can overwrite button-permission configurations for any role existing in the tenant database. This capability effectively grants the attacker control over what actions specific roles are permitted to execute within the application interface. Since these permissions dictate access to various features and data views, compromising them allows the attacker to elevate their own privileges by assigning themselves or other compromised accounts to roles with elevated capabilities, or conversely, degrade security by stripping critical users of necessary permissions. This aligns closely with MITRE ATT&CK technique T1078 Valid Accounts, as it leverages existing credentials, and potentially T1098 Account Manipulation if the attacker modifies role definitions to persist their access.
The impact extends beyond simple privilege escalation; it compromises the integrity of the application's security model. An adversary can systematically enumerate roles within a tenant by attempting updates on various roleId values, thereby mapping out the organizational structure and permission hierarchy without direct authorization checks. Furthermore, because the vulnerability affects button-permission definitions, which often gatekeep access to sensitive modules such as financial reporting, customer data management, or system configuration panels, an attacker could gain unauthorized read or write access to confidential business information. This undermines the principle of least privilege and exposes the organization to significant risks including data breaches, regulatory non-compliance, and operational disruption due to altered workflow permissions.
Mitigation strategies must prioritize immediate patching to version 3.7 or later where this issue has been addressed by implementing robust server-side authorization checks. Developers should ensure that every endpoint performing state-changing operations validates the requester's role against a centralized access control list before processing any input parameters, particularly those affecting other users' permissions like roleId and btnStr. Input validation alone is insufficient; strict enforcement of business logic rules is required to prevent cross-role permission modifications. Additionally, implementing comprehensive logging for all administrative actions related to user roles and button configurations can aid in detecting exploitation attempts post-deployment. Security teams should also conduct regular audits of role assignments and monitor for anomalous patterns in API usage that might indicate automated enumeration or privilege escalation attacks targeting this specific endpoint.