CVE-2026-86747 in Snipe-IT
Summary
by MITRE • 09/09/2026
Snipe-IT is an open source IT asset management system. In versions up to and including 8.6.3, the report acceptance endpoints POST /reports/unaccepted_assets/sent_reminder (ReportsController::sentAssetAcceptanceReminder) and DELETE /reports/unaccepted_assets/{acceptanceId}/delete (ReportsController::deleteAssetAcceptance) are not correctly scoped when Full Multiple Company Support (FMCS) is enabled. In 8.6.3 the guard ReportsController::currentUserCanAccessAcceptance() early-exits with 'return true' when '! $user->company_id' is truthy, which is the case for every pivot-only user (a user associated with companies through the company_user pivot table whose scalar users.company_id column is NULL); versions prior to 8.6.3 lacked the guard altogether. As a result, an authenticated user holding the reports.view permission can send acceptance-reminder emails for, and permanently delete, any pending acceptance record in the install regardless of which company owns the underlying checkoutable. Deletion is destructive and forfeits the acceptance audit trail for the affected item, and the reminder email exposes limited cross-company acceptance context (item name and assignment metadata) to the recipient. Acceptance IDs are sequential integers and can be enumerated. This issue is fixed in version 8.7.0.
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 up to and including 8.6.3 represents a critical failure in access control logic, specifically within the context of Full Multiple Company Support (FMCS). The core technical flaw resides in the ReportsController methods responsible for sending asset acceptance reminders via POST /reports/unaccepted_assets/sent_reminder and deleting pending acceptances via DELETE /reports/unaccepted_assets/{acceptanceId}/delete. These endpoints are designed to manage user acknowledgment of IT assets, but they lack proper scoping mechanisms that restrict operations to resources belonging exclusively to the authenticated user's assigned company or companies. This architectural oversight allows for a severe breach in data isolation between distinct organizational units within a multi-tenant deployment.
The root cause is traced to an insufficient authorization guard implemented as ReportsController::currentUserCanAccessAcceptance(). In version 8.6.3, this function contains a logic error where it returns true if the user's company_id property is null or falsy. This condition inadvertently grants unrestricted access to pivot-only users—accounts that are associated with companies through a many-to-many relationship table (company_user) but do not have a direct scalar value in their primary users.company_id column. For these users, who constitute a significant portion of multi-company deployments, the security check effectively bypasses all validation, returning true regardless of whether the user has any legitimate connection to the target asset's owning company. In versions prior to 8.6.3, this guard was entirely absent, resulting in an even broader scope of vulnerability where no such checks existed at all for these specific endpoints.
The operational impact of this flaw is substantial and multifaceted. An authenticated user possessing only the reports.view permission can exploit this misconfiguration to perform destructive actions on assets outside their authorized domain. Specifically, they can permanently delete pending acceptance records using the DELETE endpoint. This action is particularly damaging because it forfeits the audit trail associated with that specific asset acceptance event, potentially obscuring compliance history and creating gaps in forensic evidence regarding who had access to or responsibility for an item at a given time. Furthermore, the POST endpoint allows these unauthorized users to send reminder emails to other employees. While this does not directly exfiltrate sensitive data, it exposes limited cross-company context such as asset names and assignment metadata, which can aid attackers in mapping out the internal IT infrastructure and identifying high-value targets for further exploitation.
From a classification perspective, this vulnerability aligns with CWE-269: Improper Privilege Management, specifically illustrating how insufficient role-based access control leads to unauthorized actions. It also maps closely to ATT&CK technique T1078: Valid Accounts, as the attacker leverages legitimate credentials that are improperly scoped due to a flaw in the application's authorization logic rather than credential theft or privilege escalation through other means. The sequential nature of acceptance IDs further exacerbates the risk by allowing for easy enumeration of records across different companies, turning what might be an isolated incident into a systematic data integrity and privacy issue affecting multiple organizational units simultaneously.
Mitigation strategies must prioritize immediate upgrading to version 8.7.0 or later, where this logic error has been corrected to properly scope access based on the user's actual company associations rather than relying on flawed null checks. For organizations unable to upgrade immediately due to operational constraints, temporary mitigations should include restricting the reports.view permission to a minimal set of trusted administrators who possess direct scalar company assignments, thereby avoiding the pivot-only user scenario that triggers the vulnerability. Additionally, implementing strict input validation and ensuring that all API endpoints verify ownership against the full list of companies associated with the authenticated user via the pivot table is essential. Regular audits of access control lists and review of authorization logic in multi-tenant applications are recommended to prevent similar scoping failures in other modules of the system.