CVE-2026-86768 in Snipe-IT
Summary
by MITRE • 09/09/2026
Snipe-IT before 8.7.0 fails to validate soft-deleted state in API checkout endpoints, allowing authenticated users with checkout permissions to bind live inventory to trashed targets. Attackers can submit POST requests to hardware, component, or consumable checkout endpoints with soft-deleted user, asset, or location IDs to create orphaned references that corrupt the asset ledger and audit trails.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Snipe-IT versions prior to 8.7.0 represents a critical logic flaw within the application's API layer, specifically affecting the checkout endpoints for hardware, components, and consumables. This issue stems from an insufficient validation of entity states during transaction processing. When an authenticated user possessing checkout permissions initiates a request to assign inventory items to targets such as users, assets, or locations, the system fails to verify whether those target entities have been marked as soft-deleted. In database design patterns common in web applications like Snipe-IT, soft deletion is intended to preserve historical data and audit trails by marking records as inactive rather than permanently removing them from the database. However, this implementation oversight allows the application to treat these logically deleted targets as active recipients for new inventory assignments.
From a technical perspective, the flaw lies in the absence of integrity checks within the checkout logic that would filter out or reject requests targeting entities with a soft-delete flag set to true. By submitting POST requests containing identifiers associated with trashed users, assets, or locations, an attacker can successfully bind live inventory items to these non-existent or inactive targets. This action results in the creation of orphaned references within the database structure. These references are not immediately visible through standard user interface views because they point to records that are filtered out by default queries, but they persist in the underlying data model and disrupt the relational integrity between assets and their assigned entities.
The operational impact of this vulnerability is significant for organizations relying on Snipe-IT for accurate asset management and compliance auditing. The primary consequence is the corruption of the asset ledger and audit trails. Because inventory items are now associated with targets that do not exist in an active state, reports generated by the system may become inaccurate or misleading. This can lead to discrepancies in financial reporting, as assets might appear assigned when they are effectively unaccounted for in practical terms. Furthermore, it complicates forensic analysis and compliance audits, which depend on clean, traceable chains of custody for hardware and consumables. The ability to create these orphaned records also introduces a risk of data integrity issues that could require complex database cleanup procedures to resolve manually.
This vulnerability aligns with CWE-862, Missing Authorization Check, as the application fails to enforce proper access control logic regarding the state of target entities during specific operations. It is further categorized under CWE-913, Improper Control of Dynamically-Managed Resource Identifiers, because the system accepts and processes resource identifiers without validating their current operational status against business rules. In terms of offensive security frameworks, this behavior can be leveraged in conjunction with ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials to perform unauthorized actions that degrade data integrity rather than directly stealing sensitive information. The attack vector is classified as remote and requires authentication, placing it within the scope of authenticated API abuse scenarios.
Mitigation for this vulnerability involves upgrading Snipe-IT to version 8.7.0 or later, where the developers have implemented strict validation checks to ensure that checkout operations only proceed if all target entities are in an active state. For organizations unable to upgrade immediately due to compatibility constraints with other systems, temporary mitigations include restricting API access through network-level controls such as firewalls or reverse proxies to limit exposure of the affected endpoints. Additionally, implementing rigorous input validation at the application gateway level can help filter out requests that reference known soft-deleted identifiers if a mapping service is available. Regular database integrity checks and audits should also be conducted to identify any existing orphaned references created prior to patching, ensuring that asset records remain accurate and reliable for operational decision-making.