CVE-2026-109377 in ERPNext
Summary
by MITRE • 10/13/2026
ERPNext 9.0.0 through 16.50.0 contains a missing authorization vulnerability that allows authenticated users to view stock quantities via whitelisted batch methods. Attackers, including customer portal users, can call get_batch_qty, get_batches_by_oldest or get_pos_reserved_batch_qty to list every item batch with per-warehouse quantities.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The identified security flaw resides within the ERPNext enterprise resource planning software, specifically affecting versions ranging from 9.0.0 through 16.50.0. This vulnerability is classified as a missing authorization issue, which fundamentally represents an access control failure where the application fails to properly verify whether a user has the necessary permissions to perform a specific action or access certain data resources. In this context, the flaw allows authenticated users, including those with limited privileges such as customer portal users, to bypass intended restrictions and retrieve sensitive inventory information that should be restricted based on their role or organizational scope.
The technical mechanism of exploitation involves the abuse of whitelisted API methods designed for legitimate operational purposes. Specifically, attackers can invoke functions named get_batch_qty, get_batches_by_oldest, or get_pos_reserved_batch_qty. These endpoints are intended to provide batch quantity information for specific items within a defined context but lack sufficient validation checks on the input parameters regarding warehouse scope and user authorization levels. By manipulating these calls, an attacker can enumerate every item batch stored in the system along with their corresponding quantities per warehouse. This effectively transforms what should be a restricted operational query into a comprehensive data extraction tool that reveals granular inventory details across all warehouses managed by the instance.
The operational impact of this vulnerability is significant for organizations relying on ERPNext for supply chain and inventory management. The ability to view stock quantities via these methods exposes critical business intelligence, including total inventory levels, warehouse-specific holdings, and potentially reserved stock intended for specific orders or production runs. For customer portal users, who typically have limited visibility into internal operations, this breach of confidentiality undermines the principle of least privilege. Competitors could exploit this data to gauge market availability, while malicious insiders might use it to plan thefts or manipulate procurement processes by understanding exactly what resources are available and where they are located within the organization's logistics network.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as the system fails to enforce proper authorization policies for sensitive data retrieval operations. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials to access resources they are not authorized to view, and potentially T1530 Data from Cloud Storage Object if the inventory data is considered part of the organization's critical asset repository. The exploitation does not require complex injection techniques or privilege escalation beyond what was already granted through authentication, making it a straightforward yet impactful attack vector for any authenticated user within the system.
To mitigate this vulnerability, organizations running affected versions of ERPNext should immediately apply the latest security patches provided by the ERPNext development team, which address these authorization checks in the specified API methods. Administrators must ensure that their instances are updated to version 16.50.1 or later where applicable, as earlier versions remain exposed until patched. In environments where immediate patching is not feasible due to stability concerns, temporary mitigations should include restricting network access to the ERPNext instance from untrusted networks and auditing user roles to ensure that customer portal users have minimal necessary permissions. Additionally, implementing strict input validation on warehouse identifiers passed to these API endpoints can help limit the scope of data returned, although patching remains the only definitive solution to resolve the underlying authorization logic flaw.