CVE-2026-61748 in InvenTree
Summary
by MITRE • 09/21/2026
InvenTree is an Open Source Inventory Management System. Prior to 1.4.0, ReportPrint at POST /api/report/print/ and LabelPrint at POST /api/report/label/print/ require authentication but do not call users.permissions.check_user_permission for the caller's per-model view role before selecting objects by primary key and rendering them with a chosen template. Because default templates exist for major business models and DataOutput stores the generated artifact for the requesting user, a role-less or unrelated-role account can enumerate object identifiers and download reports containing purchase, sales, part, bill-of-materials, stock, build, supplier, customer, pricing, and inventory data that the corresponding detail APIs would deny. This issue is fixed in version 1.4.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/21/2026
InvenTree serves as a comprehensive open-source inventory management system designed to handle complex supply chain operations including purchase orders, sales, stock levels, bills of materials, and supplier relationships. The software architecture relies heavily on role-based access control mechanisms to ensure that users can only interact with data appropriate for their assigned permissions within the organization. A critical security flaw was identified in versions prior to 1.4.0 regarding the handling of report generation requests through specific API endpoints. Specifically, the ReportPrint endpoint at POST /api/report/print/ and the LabelPrint endpoint at POST /api/report/label/print/ were found to have insufficient authorization checks despite requiring initial authentication for user login.
The technical root cause of this vulnerability lies in the sequence of operations performed by these endpoints when processing a request. Upon receiving an authenticated request, the system proceeds directly to select specific objects based on their primary keys and renders them using predefined templates without first verifying whether the requesting user possesses the necessary per-model view permissions for those particular models. This omission bypasses the standard permission checking logic typically enforced via users.permissions.check_user_permission. Consequently, any authenticated account, regardless of its role or lack thereof, can request reports containing sensitive business data associated with specific object identifiers.
The operational impact of this flaw is significant as it allows unauthorized enumeration and exfiltration of critical inventory and financial data. Because default templates exist for major business models such as purchase orders, sales records, parts, bills of materials, stock levels, build plans, suppliers, customers, pricing information, and general inventory details, an attacker can systematically iterate through primary key values to discover valid objects. The DataOutput component stores the generated artifacts for the requesting user, facilitating the easy retrieval of these reports. This behavior effectively bypasses the restrictions imposed by detail APIs which would normally deny access to such data if the user lacked appropriate permissions. As a result, role-less accounts or those with unrelated roles can enumerate object identifiers and download comprehensive reports containing confidential business intelligence that should remain restricted.
This vulnerability aligns with CWE-862 Missing Authorization, as the application fails to enforce proper authorization checks before granting access to sensitive resources. Furthermore, it relates to CWE-200 Information Exposure through an Error or Unintended Data Leak, where internal data structures and identifiers are exposed via API responses that should be restricted. From a tactical perspective, this flaw supports ATT&CK techniques such as T1078 Valid Accounts for initial access validation and potentially T1530 Data from Cloud Storage if the artifacts were stored in accessible cloud buckets, though primarily it represents an unauthorized data retrieval scenario within the application layer.
To mitigate this vulnerability, organizations running InvenTree must upgrade to version 1.4.0 or later where the permission checks have been properly integrated into the report generation workflow. Until upgrading is possible, administrators should consider restricting API access through network-level controls such as firewalls or reverse proxy configurations that limit exposure of these specific endpoints to trusted internal networks only. Additionally, implementing strict monitoring and alerting for unusual patterns in report download requests can help detect potential exploitation attempts by identifying systematic enumeration of primary keys across different business models. Regular security audits focusing on API endpoint authorization logic are recommended to prevent similar oversights in future development cycles.