CVE-2026-109615 in ERPNext
Summary
by MITRE • 10/13/2026
Frappe ERPNext before 15.121.0 and 16.x before 16.34.0 contains a missing authorization vulnerability in certain endpoints that fail to enforce proper permission checks during document creation. Authenticated low-privileged users can call these endpoints to create documents against records beyond their permitted role, bypassing role-based access controls.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/13/2026
The identified security flaw represents a critical failure in the implementation of Role-Based Access Control within Frappe ERPNext versions prior to 15.121.0 and 16.x prior to 16.34.0. This vulnerability stems from an insufficient authorization check mechanism embedded in specific API endpoints responsible for document creation operations. In a properly secured enterprise resource planning system, every action that modifies data must be validated against the requesting user's assigned roles and permissions before execution. However, in these affected versions, certain endpoints bypass this essential validation step during the initial phase of creating new records. This architectural oversight allows authenticated users with low-privilege accounts to interact directly with backend services without undergoing the standard permission verification process that would normally restrict their actions based on their role hierarchy.
From a technical perspective, the root cause lies in the application logic governing document creation endpoints where the authorization middleware or handler does not correctly inherit or enforce the permissions defined for the specific record type being created. Typically, ERP systems maintain complex permission matrices that dictate which users can create, read, update, or delete records of various types such as invoices, customer data, or inventory logs. When a user attempts to create a document through an affected endpoint, the system accepts the request payload and proceeds with database insertion without verifying whether the authenticated session possesses the requisite privileges for that specific entity type. This bypass effectively neutralizes the intended security boundaries established by the application's access control policies, allowing low-privileged users to perform actions reserved for administrators or higher-level roles.
The operational impact of this vulnerability is significant as it enables unauthorized data manipulation and potential privilege escalation within the ERP environment. An attacker with a standard user account can create records that should be restricted, such as generating financial transactions, altering inventory levels, or creating administrative configurations without proper oversight. This not only compromises the integrity of business-critical data but also undermines audit trails and compliance reporting mechanisms that rely on accurate role-based activity logging. Furthermore, this flaw facilitates lateral movement within the system by allowing attackers to establish footholds using unauthorized records which may be leveraged for further exploitation or social engineering attacks against other users with higher privileges.
This vulnerability is classified under CWE-269 Improper Privilege Management and aligns with MITRE ATT&CK technique T1078 Valid Accounts, specifically the aspect of utilizing legitimate credentials to bypass access controls. The lack of proper authorization checks during resource creation represents a fundamental deviation from secure coding practices recommended by industry standards such as OWASP API Security Top 10, particularly under category Broken Object Level Authorization where object-level permissions are not enforced consistently across all endpoints. To mitigate this risk, organizations running affected versions must immediately upgrade to Frappe ERPNext version 15.121.0 or later for the v15 branch and version 16.34.0 or later for the v16 branch where these authorization checks have been corrected. Until an upgrade is feasible, administrators should implement strict network-level access controls to limit exposure of API endpoints to trusted internal networks only and monitor logs closely for anomalous document creation activities originating from low-privilege accounts.