Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-21T19:17:07.760Z",
  "pubdate": "2026-09-21T19:17:07.760Z",
  "executiveSummary": "The vulnerability is an Improper Access Control flaw within the InvenTree inventory management system, identified in versions prior to 1.4.0. It resides in the report and label printing endpoints, specifically POST /api/report/print/ and POST /api/report/label/print/.\nThe vulnerability allows authenticated users with minimal or no assigned role permissions to access, enumerate, and export highly sensitive business data—including purchase, sales, stock, pricing, and inventory information—that should be restricted by model-level access controls.\nThe core issue stems from the application's failure to invoke the 'users.permissions.check_user_permission' function prior to processing document generation requests. This lack of authorization validation enables attackers to bypass existing security boundaries, as the system treats these requests as authorized operations regardless of the caller's actual privileges.\nThe risk implication is significant unauthorized data exfiltration, potentially exposing proprietary business intelligence and inventory logistics to unauthorized internal actors. Exploitation is trivial, requiring only an authenticated session and the ability to interact with the API to perform enumeration of object identifiers.",
  "technicalDetails": "The vulnerability is rooted in an authorization bypass within the report generation workflow of InvenTree. Specifically, the endpoints POST /api/report/print/ and POST /api/report/label/print/ fail to perform server-side permission verification via 'users.permissions.check_user_permission' before retrieving requested objects from the database.\nIn a secure configuration, InvenTree should enforce role-based access control (RBAC) to ensure that users attempting to generate reports or labels for specific models (e.g., Parts, Stock, Purchase Orders) possess the necessary view permissions. However, the affected endpoints bypass this crucial gatekeeper. When a request is received, the system directly proceeds to object selection based on the provided primary key and proceeds to render the requested resource using default templates.\nThe attack flow proceeds as follows: An authenticated user with limited or zero privileges sends a POST request to the vulnerable API endpoints. Within the payload, the user specifies a primary key for a restricted object. Because the application logic does not validate the user's role against the target model, the backend retrieves the sensitive data associated with the primary key. The system then renders this data into a printable format (such as a PDF or label artifact).\nOnce generated, the system stores the resulting artifact via the 'DataOutput' component, associating it with the requesting user. This behavior facilitates a secondary impact where an attacker can systematically enumerate primary keys to scrape sensitive data across the entire inventory ecosystem. This includes, but is not limited to, bill-of-materials, build histories, supplier details, customer data, and internal financial pricing metrics.\nThe exposure is exacerbated by the availability of default templates for major business models, which ensures that an attacker can successfully render complex, high-value data without needing to supply custom malicious templates. The vulnerability is present in all versions prior to 1.4.0, where the check was not implemented for the printing sub-system. Because the API endpoints require authentication, this is not an unauthenticated vulnerability, but the lack of granular permission checks effectively collapses the intended security model, granting unauthorized access to the entire data set once a user is authenticated in the system."
}