Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-21T19:17:07.190Z",
  "pubdate": "2026-09-21T19:17:07.190Z",
  "executiveSummary": "InvenTree versions prior to 1.4.0 contain a critical insecure direct object reference (IDOR) vulnerability within the barcode scanning API.\nThe vulnerability resides in the POST /api/barcode/ endpoint, where improper validation allows authenticated low-privileged users to access sensitive database objects.\nBy submitting a crafted JSON payload, an attacker can bypass model-level authorization checks and disclose sensitive records, including parts, stock levels, order details, and pricing data.\nThe root cause is a failure of the InvenTreeBarcodeMixin to verify granular user permissions before serializing and returning object instances to the requester.\nBecause the BarcodeView uses overly permissive scoping (IsAuthenticatedOrReadScope), any authenticated user can effectively enumerate primary keys across multiple sensitive models.\nThis represents a significant risk to commercial confidentiality, as unauthorized parties can gain comprehensive visibility into supply chain operations, inventory holdings, and internal business metrics.\nExploitation requires minimal technical effort and valid authentication credentials, making this an accessible target for malicious internal actors or compromised low-privilege accounts.",
  "technicalDetails": "The vulnerability exists in the handling of internal JSON barcode requests processed by the POST /api/barcode/ endpoint in InvenTree versions prior to 1.4.0.\nThe system architecture utilizes a barcode plugin mechanism that accepts a JSON structure containing a 'model' label and a primary key (pk) integer. The backend uses this input to perform a direct object lookup via the model.objects.get(pk=...) method.\nThe security deficiency stems from the InvenTreeBarcodeMixin, specifically the format_matched_response() function. While the view itself is protected by IsAuthenticatedOrReadScope, this permission check is insufficient to enforce granular, model-specific authorization requirements.\nWhen a user submits a synthetic barcode JSON, the application fails to validate whether the current user possesses the required READ permissions for the specific model being queried. Consequently, the application proceeds to serialize the entire object instance associated with the provided primary key.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates as a low-privileged user. 2) The attacker crafts a POST request to /api/barcode/ containing a serialized JSON object specifying an target model (e.g., 'stockitem', 'part', 'purchaseorder') and a target primary key. 3) The backend performs the query and the InvenTreeBarcodeMixin serializes the sensitive record data. 4) The server returns the complete, non-sanitized JSON object to the attacker.\nBecause the system allows for sequential primary key incrementation, an attacker can easily automate the enumeration of records. This allows for the bulk extraction of commercially sensitive data, including supplier/manufacturer metadata, internal pricing structures, build histories, and precise stock availability.\nThis flaw effectively bypasses standard Django-based authorization workflows for these models because the barcode processing logic operates outside the context of the standard model-view permission decorators that would otherwise restrict access based on user roles and group membership. The vulnerability is patched in version 1.4.0, which likely introduces strict authorization checks within the barcode processing pipeline to ensure the requester has explicit permissions for the retrieved data model before serialization occurs."
}