Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-21T19:17:07.607Z",
  "pubdate": "2026-09-21T19:17:07.607Z",
  "executiveSummary": "InvenTree versions prior to 1.4.0 contain an Insecure Direct Object Reference (IDOR) vulnerability within the data import API endpoints. The flaw resides in the improper scoping of database querysets for DataImportRow and DataImportColumnMap objects, which fail to validate that the requesting user is the owner of the associated DataImportSession.\nThis vulnerability allows any authenticated user—regardless of their assigned roles or permissions—to access, view, and retrieve sensitive data staged for import by other users. By supplying an arbitrary identifier for an existing import session, an attacker can exfiltrate raw data and mapping configurations belonging to other accounts.\nThe risk implication is significant as it facilitates unauthorized information disclosure of potentially sensitive inventory or operational data. While the InvenTree threat model generally assumes authenticated instance users are trusted, this vulnerability bypasses application-level access controls, enabling unauthorized data access across the platform's multi-user environment. Exploitation requires only basic authenticated access to the instance.",
  "technicalDetails": "The root cause of this vulnerability is a failure in the application's authorization logic within the Django-based API layer. Specifically, the endpoints located at /api/importer/row/ and /api/importer/mapping/ perform database queries to fetch DataImportRow and DataImportColumnMap instances based on provided session identifiers. The implementation lacks an ownership verification mechanism, failing to filter the querysets against the current user's identity or the owner field of the parent DataImportSession model.\nIn a secure implementation, the application should strictly enforce that the requested DataImportSession ID belongs to the authenticated user. In the vulnerable versions, the backend relies on direct object lookup without secondary validation of session ownership. An authenticated attacker can iterate through or guess session identifiers to retrieve data that was never intended for their view.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates as a legitimate user within the InvenTree instance. 2) The attacker intercepts or identifies valid identifiers for DataImportSession objects. 3) The attacker sends HTTP GET requests to /api/importer/row/ or /api/importer/mapping/ while specifying these session identifiers. 4) The server processes the request without validating ownership, returning the row_data, data fields, and column mappings belonging to the target session. 5) The attacker successfully exfiltrates the contents of the target user's import session.\nBecause the endpoints return comprehensive data structures used for the import process, the impact includes the exposure of metadata, file content, and schema mapping definitions. This level of access exposes sensitive information stored within staged imports before they are formally processed into the system. This vulnerability affects all InvenTree versions prior to 1.4.0. The lack of granular access control at the API object level signifies a deficiency in secure object-level authorization (BOLA/IDOR), which is a critical concern in multi-tenant or multi-user instances where privacy of staged data must be maintained."
}