Description

Snipe-IT through version 8.6.3 fails to perform object-level authorization in the updateLicense, updateConsumable, updateAccessory, and updateModel endpoints and in the storeModel endpoint for Predefined Kits. The existing check authorizes only the parent Predefined Kit (update on PredefinedKit) and not the child object being attached. As a result, an authenticated user holding only the kits.edit permission can attach a License, Consumable, Accessory, or Asset Model that they are otherwise denied (HTTP 403) from reading directly to a Predefined Kit, and the kit relation index then discloses the attached object's name back to that low-privilege user. This is the update-path and storeModel counterpart to CVE-2026-55478, which fixed only the storeLicense, storeConsumable, and storeAccessory methods in 8.6.2. Note that updateModel was code-vulnerable in 8.6.3 but not reachable in practice because a route-name typo bound the route to a nonexistent controller method, causing HTTP 500 responses. The issue is fixed in Snipe-IT 8.7.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-09T14:17:28.040Z",
  "pubdate": "2026-09-09T14:17:28.040Z",
  "executiveSummary": "Snipe-IT through version 8.6.3 suffers from a Broken Object-Level Authorization (BOLA) vulnerability within its Predefined Kits management subsystem.\nThe vulnerability exists in the updateLicense, updateConsumable, updateAccessory, and updateModel endpoints, as well as the storeModel endpoint for Predefined Kits.\nThe flaw allows an authenticated user with restricted kits.edit privileges to bypass authorization checks when attaching sensitive assets—such as Licenses, Consumables, Accessories, or Asset Models—to a Predefined Kit, even if the user lacks sufficient read/write permissions for the target object itself.\nThis represents a failure in access control logic, where the application validates the parent kit authorization but fails to verify if the requesting user possesses authorization to manage or view the child object being attached.\nThe successful exploitation of this vulnerability leads to unauthorized information disclosure, as the system subsequently exposes the sensitive metadata of the attached objects through the kit relation index.\nThe issue serves as a functional counterpart to CVE-2026-55478, which addressed similar flaws in store-based methods. This vulnerability was resolved in Snipe-IT 8.7.0.",
  "technicalDetails": "The root cause of this vulnerability is improper validation of authorization scopes during object-relational mapping updates within the Predefined Kits module. The application implements an authorization check that confirms the user has permissions to modify the parent 'PredefinedKit' object, but it fails to apply an exhaustive authorization verification on the specific child entities—Licenses, Consumables, Accessories, and Asset Models—being associated with that kit.\nIn versions 8.6.3 and earlier, the application logic assumes that authorization to edit a kit implies implied authority over any resource assigned to it. This creates a security gap where an authenticated user with limited 'kits.edit' permissions can craft requests to bind resources to a kit that they are otherwise forbidden from accessing or interacting with.\nThe attack flow proceeds as follows: 1. An attacker identifies a target resource (e.g., a restricted License or Accessory) that they do not have direct read or edit permissions for. 2. The attacker triggers the vulnerable update or store methods (updateLicense, updateConsumable, updateAccessory, updateModel, or storeModel) via a crafted HTTP request. 3. The server validates the request against the 'PredefinedKit' permissions, which the attacker possesses. 4. The server executes the association logic, successfully linking the restricted child object to the parent kit. 5. Once the association is complete, the attacker performs a look-up on the kit relation index. Because the association exists in the database, the system inadvertently discloses the sensitive name and metadata of the protected child object to the attacker, bypassing intended access control restrictions.\nRegarding the updateModel endpoint, although it was code-vulnerable in 8.6.3, it was functionally unreachable due to a route-name typo that misdirected the request to a non-existent controller method, resulting in an HTTP 500 error. Other endpoints remained fully exploitable.\nThis vulnerability highlights a critical failure in the Principle of Least Privilege, as the application relies on coarse-grained permission checks at the parent level instead of implementing fine-grained, object-level authorization for the specific resources being managed or disclosed. This provides an attacker with a mechanism for both unauthorized resource association and the subsequent leakage of protected system data."
}