CVE-2026-61747 in InvenTree
Summary
by MITRE • 09/21/2026
InvenTree is an Open Source Inventory Management System. Prior to 1.4.0, the /api/importer/row/ and /api/importer/mapping/ endpoints do not scope DataImportRow and DataImportColumnMap querysets to the owner of the associated DataImportSession. Any authenticated user, including an account with no assigned roles, can supply another user's import session identifier and retrieve that session's row_data and data fields together with its column mappings. This exposes the full contents of data staged for import across users, although the InvenTree threat model treats authenticated instance users as trusted. This issue is fixed in version 1.4.0.
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
InvenTree serves as a widely adopted open-source inventory management system designed to help organizations track stock levels and manage supply chain operations. The vulnerability identified within versions prior to 1.4.0 represents a critical failure in access control logic, specifically affecting the API endpoints responsible for handling data import processes. These endpoints, namely /api/importer/row/ and /api/importer/mapping/, are intended to retrieve specific rows of data or column mappings associated with an ongoing import session. However, the underlying implementation fails to enforce proper ownership verification when querying the DataImportRow and DataImportColumnMap database models. This architectural flaw means that the system does not scope these querysets based on the identity of the user initiating the request relative to the owner of the target data import session.
The technical consequence of this oversight is a severe insecure direct object reference vulnerability, categorized under CWE-639 in industry standards for software security weaknesses. Because the API endpoints do not validate that the authenticated user making the request has permission to access the specific DataImportSession identified by the provided identifier, any authenticated account can manipulate the session ID parameter to target sessions belonging to other users. This includes accounts with no assigned roles or minimal privileges, indicating a complete breakdown of authorization checks at the application logic layer rather than just in high-privilege contexts. An attacker simply needs valid credentials for any user on the instance and knowledge of another user's import session identifier to execute this attack vector effectively.
The operational impact of this vulnerability is significant data exposure across the organization. By exploiting this flaw, an authenticated user can retrieve both the row_data and column mappings from other users' import sessions. This action exposes the full contents of data that are currently staged for import into the inventory system. While InvenTree's threat model generally treats all authenticated instance users as trusted entities to facilitate collaborative workflows, this vulnerability allows even low-privilege or untrusted internal actors to access sensitive business information such as supplier details, pricing structures, stock quantities, and product specifications belonging to colleagues or other departments. This breach of confidentiality undermines the integrity of data privacy within the organization and could lead to competitive intelligence leaks or targeted attacks if combined with other vulnerabilities.
To mitigate this risk, organizations running InvenTree must upgrade immediately to version 1.4.0 or later, where the developers have implemented proper scoping for DataImportRow and DataImportColumnMap querysets to ensure they are restricted to the owner of the associated DataImportSession. For environments that cannot update immediately due to compatibility constraints, temporary mitigations should focus on restricting API access through network-level controls such as firewalls or reverse proxies if possible, although this is less effective against authenticated attacks. Additionally, implementing strict role-based access control policies and monitoring for unusual patterns in import session ID usage can help detect potential exploitation attempts. Regular security audits of custom API endpoints are recommended to ensure that future development adheres to the principle of least privilege and validates ownership before granting data access.