Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-09T14:17:23.553Z",
  "pubdate": "2026-09-09T14:17:23.553Z",
  "executiveSummary": "An improper authorization vulnerability exists in Snipe-IT versions up to and including 8.6.3, specifically affecting deployments with Full Multiple Company Support (FMCS) enabled.\nThe vulnerability resides within the ReportsController endpoints 'POST /reports/unaccepted_assets/sent_reminder' and 'DELETE /reports/unaccepted_assets/{acceptanceId}/delete'.\nAuthenticated users possessing 'reports.view' permissions can bypass multi-tenancy constraints to perform unauthorized actions on asset acceptance records they should not have access to.\nThe impact includes the ability to trigger unauthorized email reminders containing sensitive asset metadata and the permanent deletion of asset acceptance records, which compromises the audit trail of the IT asset management system.\nExploitation is facilitated by the sequential nature of acceptance IDs, allowing an attacker to systematically target cross-company data.\nThe vulnerability is primarily caused by flawed authorization logic in the 'ReportsController::currentUserCanAccessAcceptance()' guard, which incorrectly validates users with a NULL 'company_id' column.\nThe risk is significant due to the potential for data integrity loss and unauthorized information disclosure across defined organizational boundaries.",
  "technicalDetails": "The root cause of this vulnerability is an authorization bypass in the ReportsController component of Snipe-IT. When Full Multiple Company Support (FMCS) is active, the application fails to enforce tenant-based scoping for specific asset acceptance management endpoints.\nIn version 8.6.3, the security guard function 'ReportsController::currentUserCanAccessAcceptance()' contains a logical flaw: it returns 'true' if the authenticated user's 'users.company_id' column is NULL. In Snipe-IT's architecture, users assigned to companies via the 'company_user' pivot table often have a NULL 'company_id' scalar value. Consequently, these 'pivot-only' users effectively bypass all subsequent ownership checks.\nVersions prior to 8.6.3 are even more susceptible, as they entirely lack the 'currentUserCanAccessAcceptance()' guard mechanism, providing no server-side restriction on object access for users with 'reports.view' permissions.\nThe attack flow follows a predictable pattern: 1) An authenticated attacker with 'reports.view' permissions identifies the target endpoint (e.g., '/reports/unaccepted_assets/{acceptanceId}/delete'). 2) Because acceptance IDs are sequential integers, an attacker can enumerate these IDs to identify records belonging to other companies. 3) The attacker issues a DELETE request or a POST reminder request against these IDs. 4) The application, failing to verify if the user's authorized company association matches the asset's ownership, executes the request.\nFor the delete operation, this leads to the permanent removal of data from the database, irreversibly corrupting the audit trail for asset acceptances. For the reminder operation, it triggers an outbound email that exposes cross-company asset metadata—including item names and specific assignment details—to the email recipient, constituting an information disclosure vulnerability.\nThis vulnerability is particularly dangerous because the authorization check is bypassed at the controller level before the application logic reaches the database query layer, meaning the backend does not apply any additional 'where' clauses to restrict the scope to the user's authorized company, allowing global access to all 'unaccepted_assets' entries across the entire installation."
}