CVE-2026-61747: Authorization Bypass in InvenTree Import API Exposes Staged Data Across Users

Summary

CVE-2026-61747 is a CWE-639 authorization bypass vulnerability in InvenTree, an open-source inventory management system, affecting versions prior to 1.4.0. The /api/importer/row/ and /api/importer/mapping/ API endpoints fail to scope their database querysets to the owner of the associated DataImportSession, allowing any authenticated user to retrieve another user’s staged import data by supplying an arbitrary import session identifier. The issue is fixed in version 1.4.0.

Technical Analysis

InvenTree provides a data import feature that allows users to stage data for import into the inventory system. This feature is exposed through two REST API endpoints: /api/importer/row/ and /api/importer/mapping/. These endpoints serve data from two Django models: DataImportRow and DataImportColumnMap, both of which are associated with a parent DataImportSession model that tracks an individual import operation.

The vulnerability, classified as CWE-639 (Authorization Bypass Through User-Controlled Key), arises because the querysets returned by these endpoints are not filtered to restrict results to the owner of the associated DataImportSession. In a properly secured Django REST Framework application, a queryset for these endpoints would include a filter clause ensuring that only records belonging to import sessions owned by the requesting user are returned. In this case, that filter is absent.

The user-controlled key in this CWE-639 pattern is the import session identifier. When a user requests data from /api/importer/row/ or /api/importer/mapping/, they supply an import session identifier as part of the request. The backend retrieves the corresponding DataImportRow or DataImportColumnMap records without verifying that the requesting user is the owner of that DataImportSession. This means that any valid session identifier, regardless of who created it, can be used to fetch the associated data.

The CVSS 3.1 vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N breaks down as follows:

Attack Vector (AV:N): Network — the vulnerability is exploitable over the network via the REST API.
Attack Complexity (AC:L): Low — exploitation requires no special conditions; the attacker simply needs to supply a valid session identifier.
Privileges Required (PR:L): Low — the attacker must be an authenticated user, but no specific roles or permissions are required. The description explicitly states that even accounts with no assigned roles can exploit this.
User Interaction (UI:N): None — no interaction from the victim is needed.
Scope (S:U): Unchanged — the vulnerability does not cross security boundaries.
Confidentiality (C:L): Low — the attacker can read staged import data belonging to other users, but the impact is limited to data that has been staged for import, not the full database.
Integrity (I:N): None — the attacker cannot modify data.
Availability (A:N): None — the attacker cannot disrupt service.

The resulting CVSS base score of 4.3 places this vulnerability in the MEDIUM severity band. The relatively modest score reflects the fact that the vulnerability is read-only, with no integrity or availability impact, and that the InvenTree threat model treats authenticated instance users as trusted. This threat model assumption is significant: it means the developers considered authenticated users to be generally trustworthy, and the import API was not designed with cross-user isolation as a primary security boundary. However, the description notes that accounts with no assigned roles can exploit this, which means the trust model does not align with the actual access control behavior. A user with no roles should not be able to access any business data, let alone another user’s staged import data.

The fix, implemented in commit 3c17367e3c2b23631a5d1d7d9b7d93c4174b8eb1 and released in version 1.4.0, addresses the issue by scoping the DataImportRow and DataImportColumnMap querysets to the owner of the associated DataImportSession. This ensures that a user requesting data from these endpoints only receives records from import sessions they own.

Affected Software and Versions

The vulnerability affects InvenTree, an open-source inventory management system, in all versions prior to 1.4.0. The fix is included in version 1.4.0, as documented in the official release notes and the associated GitHub security advisory.

Affected versions: InvenTree prior to 1.4.0
Fixed version: InvenTree 1.4.0
Fix commit: 3c17367e3c2b23631a5d1d7d9b7d93c4174b8eb1
Related pull request: PR #12169

Specific version ranges below 1.4.0 are not enumerated in the available advisory data. Organizations running any version of InvenTree older than 1.4.0 should assume they are affected.

Impact

The vulnerability allows any authenticated InvenTree user, including accounts with no assigned roles, to access the full contents of data that other users have staged for import. Specifically, the exposed data includes:

row_data: The actual data values staged for import, which may contain sensitive inventory information such as part numbers, stock quantities, supplier details, pricing data, or custom field values.
data fields: The field definitions associated with the staged import data, revealing the structure and schema of the data being imported.
column mappings: The mapping between source columns and target fields, which reveals how the user intends to structure their data within InvenTree.

The confidentiality impact is rated as Low (C:L) in the CVSS vector. This reflects the fact that the exposed data is limited to staged import sessions rather than the entire InvenTree database. However, the practical impact depends heavily on what data users are importing. In an enterprise context, staged import data could contain commercially sensitive information such as supplier pricing, proprietary part specifications, or internal stock level data. An attacker who can enumerate import session identifiers could systematically exfiltrate all staged import data across the instance.

There is no integrity or availability impact. The vulnerability is strictly read-only: the attacker cannot modify or delete import sessions, alter column mappings, or disrupt the import process. The CVSS vector confirms this with I:N (no integrity impact) and A:N (no availability impact).

The InvenTree threat model treats authenticated instance users as trusted, which partially explains the MEDIUM severity rating. However, the fact that accounts with no assigned roles can exploit this vulnerability means the impact extends beyond what the threat model intended. A no-role user should not have access to any business data, and the ability to read another user’s staged import data represents a meaningful confidentiality breach, particularly in multi-tenant or shared deployments.

Exploitation Scenario

The following scenario is illustrative and derived from the vulnerability description. It does not represent a documented real-world exploit.

Consider an InvenTree instance used by a manufacturing company. User A, an inventory manager, uploads a CSV file containing supplier pricing data for 500 components. This creates a DataImportSession with a unique identifier. User A reviews the staged data through the import interface, checking column mappings and row data before committing the import.

User B, who has an account on the same InvenTree instance but no assigned roles, learns of the import API endpoints. User B authenticates to the API and sends a request to /api/importer/row/ supplying User A’s import session identifier. Because the queryset is not scoped to the session owner, the API returns all DataImportRow records associated with User A’s session, exposing the complete contents of the staged pricing data.

User B then sends a request to /api/importer/mapping/ with the same session identifier and retrieves the DataImportColumnMap records, revealing how User A mapped source columns to InvenTree fields. With this information, User B has a complete picture of User A’s intended import, including the raw data and its structural mapping.

If import session identifiers are sequential or predictable, User B could enumerate across multiple session identifiers, harvesting staged import data from all users on the instance. Even if identifiers are not sequential, any session identifier obtained through observation, log exposure, or other means could be used to retrieve the associated data. The vulnerability requires only authentication and knowledge of a valid session identifier, making it straightforward to exploit once an identifier is obtained.

Detection and Mitigation

Upgrade to version 1.4.0. The primary mitigation is to upgrade InvenTree to version 1.4.0, which includes the fix for this vulnerability. The fix scopes the DataImportRow and DataImportColumnMap querysets to the owner of the associated DataImportSession, ensuring users can only access their own import sessions.

Review API access logs. Organizations that cannot immediately upgrade should review API access logs for requests to /api/importer/row/ and /api/importer/mapping/. Look for requests from users who do not own the referenced import session identifiers. Suspicious patterns include requests from no-role accounts or requests that enumerate multiple session identifiers in rapid succession.

Restrict API access. As a temporary measure, network-level access controls can be used to restrict API access to trusted networks or VPN clients. While this does not fix the underlying authorization flaw, it reduces the attack surface by limiting who can reach the API endpoints.

Review no-role accounts. The vulnerability is exploitable by accounts with no assigned roles. Organizations should audit their InvenTree user base and disable or remove accounts that do not require access, particularly any accounts that were created for testing or evaluation purposes and remain active.

Apply the fix manually. If upgrading to 1.4.0 is not immediately feasible, the fix can be applied by cherry-picking commit 3c17367e3c2b23631a5d1d7d9b7d93c4174b8eb1 into the current deployment. However, this approach should be tested thoroughly before deployment, and upgrading to the official release is strongly preferred.

Bug Bounty Angle

CVE-2026-61747 is a textbook example of CWE-639, a vulnerability class that is highly relevant to bug bounty hunters and offensive security researchers. The pattern — a user-controlled key used to access resources without ownership verification — is one of the most common and impactful vulnerability types in modern web applications, particularly those built with Django REST Framework or similar API frameworks.

Targeting queryset scoping in Django REST Framework. When testing applications built with Django REST Framework, pay close attention to list and retrieve endpoints that accept identifiers for parent or related objects. The framework’s queryset filtering is the primary access control mechanism for model-backed API views. If a queryset is not properly scoped — for example, by filtering on user=request.user or a similar ownership clause — any authenticated user can access records belonging to other users by supplying the corresponding identifier.

Testing with low-privilege accounts. This vulnerability was exploitable by accounts with no assigned roles, which is a critical lesson for bug bounty hunters. Always test with the lowest-privilege account available. If an application allows self-registration or creates accounts with no default permissions, use those accounts to test every API endpoint. Endpoints that return data without checking role-based access control are prime targets for CWE-639 vulnerabilities.

Enumerating identifiers. Import session identifiers, like many database primary keys, may be sequential integers or predictable UUIDs. When testing for CWE-639, attempt to enumerate identifiers by incrementing or decrementing known values. If the application returns data for identifiers you do not own, you have found an authorization bypass. Start with identifiers near your own session IDs, then expand the range to confirm the scope of the vulnerability.

Looking for import and export features. Data import and export functionality is a common source of authorization bypass vulnerabilities. These features often involve multi-step workflows — upload, map columns, review, commit — with intermediate data stored in the database. Each step may expose API endpoints that handle the intermediate data, and each endpoint is a potential target for queryset scoping issues. Map out the full workflow and test every endpoint for proper ownership checks.

Understanding threat models. The InvenTree advisory notes that the threat model treats authenticated users as trusted. This is a common assumption in open-source projects and internal tools. When a threat model underestimates the risk of authenticated user access, it often leads to missing access controls on endpoints that handle sensitive data. Look for gaps between the stated threat model and the actual access control implementation. Endpoints that assume trust but handle user-specific data are particularly promising targets.

Reporting considerations. When reporting CWE-639 vulnerabilities, clearly document the attack path: how the identifier was obtained, what data was accessible, and whether low-privilege or no-role accounts can exploit the issue. The fact that this vulnerability was exploitable by no-role accounts strengthens the severity argument, even when the CVSS score is moderate. Include evidence that the same endpoint returns data only for the requesting user’s own sessions after the fix is applied, if possible.

Frequently Asked Questions

What is CVE-2026-61747?

CVE-2026-61747 is a CWE-639 authorization bypass vulnerability in InvenTree versions prior to 1.4.0. The /api/importer/row/ and /api/importer/mapping/ endpoints do not scope querysets to the session owner, allowing any authenticated user to retrieve other users’ staged import data.

Which versions of InvenTree are affected?

All versions of InvenTree prior to 1.4.0 are affected. The vulnerability is fixed in version 1.4.0, which scopes the DataImportRow and DataImportColumnMap querysets to the owner of the associated DataImportSession.

Can a user with no roles exploit this vulnerability?

Yes. The description explicitly states that any authenticated user, including accounts with no assigned roles, can supply another user’s import session identifier and retrieve that session’s row_data, data fields, and column mappings.

What data is exposed through this vulnerability?

The vulnerability exposes the full contents of data staged for import, including row_data values, data field definitions, and column mappings. This may contain sensitive inventory information such as part numbers, pricing, supplier details, or custom field values.