CVE-2026-61744 in InvenTree
Summary
by MITRE • 09/21/2026
InvenTree is an Open Source Inventory Management System. Prior to 1.4.0, POST /api/barcode/ accepts an attacker-synthesized internal JSON barcode containing a lowercase model label and integer primary key, while BarcodeView uses IsAuthenticatedOrReadScope and requires only authentication or a general read scope. The built-in barcode plugin selects the object with model.objects.get(pk=...), and InvenTreeBarcodeMixin.format_matched_response() returns the complete model serializer output as instance without checking the caller's per-model view role. A low-privilege user can enumerate primary keys for parts, stock, locations, supplier and manufacturer parts, orders, and builds to disclose commercially sensitive inventory, pricing, supplier, customer, and order data. 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
The vulnerability identified within InvenTree versions prior to 1.4.0 represents a critical failure in access control logic, specifically manifesting as an insecure direct object reference combined with insufficient authorization checks on the barcode scanning endpoint. The core of this issue lies in the implementation of the POST /api/barcode/ view, which utilizes the IsAuthenticatedOrReadScope permission class. This configuration allows any authenticated user or a user possessing only read-only scopes to interact with the endpoint without verifying whether they have specific permissions for the targeted resource type. When an attacker submits a synthesized internal JSON barcode payload containing a lowercase model label and an integer primary key, the system proceeds to resolve the object using standard database retrieval methods such as model.objects.get(pk=...). This mechanism assumes that the presence of authentication is sufficient to authorize access, ignoring the principle of least privilege which dictates that users should only have access to resources necessary for their specific role.
The technical flaw is further exacerbated by the behavior of the InvenTreeBarcodeMixin.format_matched_response() method. Upon successfully locating an object via its primary key, this function returns the complete serialized output of the model instance directly to the caller. Crucially, it fails to check the caller's per-model view role or verify if the authenticated user has permission to read that specific type of data. This oversight means that even a low-privilege user with minimal permissions can retrieve detailed information about high-value assets. The vulnerability enables horizontal and vertical privilege escalation in terms of data exposure, allowing an attacker to iterate through primary keys for various entity types including parts, stock levels, locations, supplier details, manufacturer components, purchase orders, and build records.
The operational impact of this vulnerability is severe due to the sensitive nature of inventory management systems. By exploiting this flaw, a malicious actor can perform systematic enumeration of database identifiers to harvest commercially sensitive information. This includes disclosing precise inventory counts which could reveal production capacity or supply chain bottlenecks to competitors. Furthermore, the exposure extends to pricing data, supplier contact details, customer order history, and manufacturing specifications. Such leakage not only compromises business confidentiality but also facilitates further attacks by providing attackers with a comprehensive map of the organization's digital assets and operational workflows. The ability to enumerate these resources without proper authorization checks undermines the integrity and confidentiality guarantees expected from enterprise-grade inventory software.
This vulnerability aligns closely with CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, as well as CWE-639, Injection of Critical Data into a Non-Critical Path, where the barcode input is treated as trusted data leading to unauthorized access. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1078, Valid Accounts, specifically in the context of using legitimate credentials to access resources beyond their intended scope, and potentially T1125, Video Surveillance, if such data were used for physical planning, though primarily it falls under information gathering phases like T1046, Network Service Discovery. The root cause is a misconfiguration of Django REST Framework permissions where the read scope was granted too broadly without implementing object-level permission checks that validate user ownership or role-based access control against the specific instance being accessed.
To mitigate this vulnerability and prevent similar issues in future developments, it is essential to implement strict object-level permissions within the API views. Developers should ensure that every endpoint performing data retrieval verifies not only that the user is authenticated but also that they possess explicit permission for the specific model type and instance requested. This can be achieved by overriding has_object_permission methods or utilizing libraries like django-guardian to enforce granular access controls. Additionally, input validation on barcode payloads should include strict schema checking to reject malformed requests before database queries are executed. Upgrading to InvenTree version 1.4.0 or later is the primary remediation step as it addresses these permission logic flaws by ensuring that data serialization respects the user's actual role and permissions rather than relying solely on broad read scopes. Regular security audits of API endpoints should also be conducted to identify any other instances where object-level authorization might be bypassed through similar ID enumeration techniques.