CVE-2026-86763 in Snipe-IT
Summary
by MITRE • 09/09/2026
Snipe-IT versions >= 7.0.12 and <= 8.6.3 contain an authorization bypass in the Livewire importer component (App\Livewire\Importer, mounted at the imports.index route). The component only checked the broad 'import' ability at mount time, while its files() and activeFile() computed properties queried the imports table with no owner or company scope. As a result, any authenticated non-superuser holding the import permission could view every Import record on the instance (original filename, file_path, filesize, import_type and creation timestamp) and could invoke the selectFile($id) Livewire action with any auto-incrementing Import ID to load another user's record, exposing its stored preview data (header_row column headers and first_row, the first data row of the CSV). Because import CSVs commonly contain personal data, asset serial numbers and license keys, this discloses sensitive information; in Full Multiple Companies Support (FMCS) deployments the disclosure also crosses company/tenant boundaries. Impact is limited to preview data rather than the full CSV file, and superusers were unaffected. Fixed in version 8.7.0, which scopes non-superuser reads to imports owned by the caller.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Snipe-IT versions ranging from 7.0.12 through 8.6.3 represents a critical authorization bypass within the Livewire-based importer component, specifically located at App\Livewire\Importer and accessible via the imports.index route. This flaw stems from an insufficient access control mechanism where the application performs only a broad permission check for the import capability during the initial mount phase of the component. While this superficial check ensures that the user possesses some level of import privilege, it fails to enforce granular ownership constraints when retrieving specific data records. Consequently, authenticated users who are not superusers but hold the general import permission can bypass intended isolation boundaries and access sensitive information belonging to other users or organizations within the system.
The technical root cause lies in how the files() and activeFile() computed properties interact with the database layer. These methods query the imports table without applying any scope filters based on user ownership or company affiliation. In a properly secured implementation, such queries should be scoped to ensure that a user can only retrieve records they own or are explicitly authorized to view by their organizational hierarchy. The absence of these scopes allows an attacker with valid credentials and basic import permissions to enumerate all Import records present in the database instance. This enumeration reveals metadata including original filenames, file paths, file sizes, import types, and creation timestamps for every record stored on the system, regardless of who created them or which company they belong to.
Beyond mere enumeration, the vulnerability enables a more severe data disclosure through the selectFile($id) Livewire action. By supplying any auto-incrementing Import ID, an authenticated non-superuser can force the application to load and render preview data associated with another user's import record. This preview data typically includes header row column headers and the first data row of the CSV file being processed. Since Snipe-IT is frequently used to manage IT assets, license keys, serial numbers, and employee personal information, these initial rows often contain highly sensitive proprietary or personally identifiable information. The exposure of this preview data effectively leaks confidential organizational details that were intended to remain private within specific user accounts or company tenants.
The operational impact of this vulnerability is significant in environments utilizing Full Multiple Companies Support (FMCS), where the lack of proper scoping allows for cross-tenant data leakage. An attacker can traverse organization boundaries, viewing import previews from companies they do not belong to, thereby violating multi-tenancy isolation principles. Although the scope of disclosure is limited to preview data rather than the full CSV file contents, which mitigates some risk by preventing direct access to entire datasets, the exposure of even partial sensitive information such as asset serial numbers or license keys can facilitate further attacks including social engineering, intellectual property theft, or compliance violations under regulations like GDPR or HIPAA. Superusers remain unaffected due to their elevated privileges that inherently bypass these specific checks, but standard users with import permissions are fully vulnerable.
This vulnerability aligns with CWE-284 Improper Access Control and is consistent with ATT&CK techniques related to Collection via Local Network Sharing or Data from Information Repositories if leveraged in conjunction with other exploits for lateral movement or data exfiltration planning. The flaw highlights the importance of implementing strict object-level authorization checks rather than relying solely on role-based access control at entry points. Developers must ensure that every database query involving user-specific resources applies appropriate scoping mechanisms to verify ownership before returning any data.
To mitigate this vulnerability, organizations running Snipe-IT versions between 7.0.12 and 8.6.3 should immediately upgrade to version 8.7.0 or later. The fixed release addresses the issue by properly scoping non-superuser reads to only include imports owned by the calling user, thereby restoring the intended isolation boundaries. Until an upgrade is performed, administrators can consider restricting import permissions to a minimal set of trusted users and monitoring logs for unusual access patterns involving import records not associated with active sessions or known legitimate activities. Additionally, reviewing CSV files uploaded during this period may be necessary if there is suspicion that sensitive preview data was accessed by unauthorized parties.