Description

Snipe-IT 8.6.3 and earlier do not check the return value of Storage::put() when writing the signature PNG and the generated acceptance PDF in Account\AcceptanceController::store(). On filesystem drivers that return false instead of throwing on a write failure (for example the local disk with restrictive permissions, S3 with expired credentials, or a storage backend that is out of quota), execution continues into $acceptance->accept(), which sets accepted_at and the signature_filename/eula_filename fields, creates the 'accepted' action-log entry, and dispatches completion notifications even though the evidence files were never stored. The result is an acceptance record marked complete whose supporting evidence files do not exist, yielding a materially incomplete compliance artifact for EULA acknowledgement or equipment-receipt workflows. The condition is triggered when an authenticated user completes an acceptance while the storage backend is silently failing writes; an attacker cannot directly force the storage backend into that state. Fixed in Snipe-IT 8.7.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-09-09T14:17:22.387Z",
  "pubdate": "2026-09-09T14:17:22.387Z",
  "executiveSummary": "This vulnerability involves an improper validation of file write operations within Snipe-IT versions 8.6.3 and earlier. Specifically, the Account\\AcceptanceController::store() method fails to verify the return status of the Storage::put() function when generating signature PNGs and acceptance PDFs.\nThis flaw allows the application to proceed with database updates and notification dispatching even when the underlying storage backend fails to persist the associated compliance artifacts. The primary impact is the creation of 'ghost' acceptance records where the system reports a successful EULA acknowledgement or equipment receipt despite the absence of required legal or evidentiary documentation.\nThe vulnerability requires no direct attacker intervention to trigger; it occurs when the storage backend (e.g., local disk, S3) experiences write failures. While an attacker cannot force the storage failure, the condition results in a loss of compliance integrity and audit trail reliability. The issue is resolved in Snipe-IT 8.7.0 by implementing mandatory return value checks for file system operations.",
  "technicalDetails": "The root cause of this vulnerability lies in the silent failure handling of Laravel's Storage::put() method within the Account\\AcceptanceController::store() logic. In many filesystem driver implementations, Storage::put() returns a boolean false rather than throwing an exception when a write operation fails due to factors such as exhausted storage quotas, expired cloud storage credentials, or restrictive filesystem permissions.\nIn the vulnerable versions 8.6.3 and earlier, the application code does not inspect the return value of these calls. Consequently, the controller proceeds as if the file write operation was successful. The execution flow continues to the $acceptance->accept() method, which performs three critical actions: it updates the 'accepted_at' timestamp, records the 'signature_filename' and 'eula_filename' metadata into the database, and creates an 'accepted' entry in the application logs.\nFurthermore, the system dispatches completion notifications to relevant stakeholders. Because the database records are successfully committed, the system reports the acceptance as complete and valid within the user interface. However, the actual binary blobs—the signature PNG and the generated acceptance PDF—never reach the physical storage backend.\nThe attack flow/trigger mechanism is as follows: 1) An authenticated user initiates the acceptance workflow. 2) The backend storage encounters a transient or persistent failure (e.g., S3 connection timeout, disk full). 3) Storage::put() returns 'false'. 4) The application ignores this failure, assumes success, and proceeds to record the transaction in the database. 5) The application communicates successful completion to the user and system administrators.\nThe post-exploitation impact is a material failure in compliance and record-keeping integrity. Organizations relying on Snipe-IT for asset management or legal compliance will hold 'accepted' records that lack the associated documentation required for audit purposes. This creates a disconnect between the application's reported state and the actual evidentiary state of the system. While this is not an arbitrary code execution vulnerability, it represents a significant business logic flaw regarding data integrity and compliance assurance."
}