Description

backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. Prior to 6.8.12 and 7.0.35, HasUploadFields::uploadMultipleFilesToDisk in src/app/Models/Traits/HasUploadFields.php trusts disk-relative paths from clear_<attribute>[] and passes them to Storage::disk()->delete without confirming that the paths are persisted on the current model record. An authenticated user with Update access to a CRUD using this mutator through src/app/Models/Traits/CrudTrait.php can delete another record's attachment, a shared asset, or another operational file on the configured disk by submitting its path. The newer MultipleFiles uploader is not affected because it intersects requested deletions with the record's persisted file list. This flaw does not permit reading the deleted files. The 5.x line remains affected through its final releases. This issue is fixed in versions 6.8.12 and 7.0.35.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-14T18:17:52.917Z",
  "pubdate": "2026-09-14T18:17:52.917Z",
  "executiveSummary": "A path traversal and arbitrary file deletion vulnerability exists in the backpack/crud package, specifically within the HasUploadFields trait. This vulnerability allows an authenticated user with Update access to manipulate file paths provided to the clear_<attribute>[] parameter, resulting in the unauthorized deletion of files on the configured storage disk.\nThe vulnerability stems from a lack of server-side validation, as the application fails to verify if the requested deletion path corresponds to a file legitimately associated with the current model record. An attacker can leverage this flaw to remove arbitrary files, including shared assets or operational data, by supplying paths relative to the storage disk.\nThe vulnerability affects versions prior to 6.8.12 and 7.0.35, including the entire 5.x release line. While the vulnerability does not facilitate unauthorized file disclosure or remote code execution, it presents a significant risk to data integrity and system availability. Exploitation requires authenticated access to the administrative CRUD interface with sufficient privileges to perform update operations on affected models.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the HasUploadFields::uploadMultipleFilesToDisk function located in src/app/Models/Traits/HasUploadFields.php. The application incorrectly trusts disk-relative paths supplied via the clear_<attribute>[] input array without performing a validation check to ensure the file exists within the specific record's persistent storage state.\nThe vulnerable execution flow begins when an authenticated user with CRUD Update permissions submits a request to a controller utilizing CrudTrait.php. By manipulating the clear_<attribute>[] request parameter, an attacker injects an arbitrary file path. The application then passes this unvalidated input directly to Storage::disk()->delete. Because the logic assumes the input refers only to authorized files, it proceeds to trigger the filesystem deletion operation on the target disk.\nThis vulnerability is effectively an arbitrary file deletion flaw. The attacker does not need to bypass authentication, but they must have legitimate access to an administrative CRUD panel. By submitting a path string that points to sensitive or operational files stored on the disk, the attacker can force the backend to remove those files. Unlike the modern 'MultipleFiles' uploader implementation, which correctly intersects requested deletions against an established whitelist of records persisted in the database, the vulnerable implementation performs no such verification, allowing the deletion of files outside the scope of the current model's ownership.\nThe vulnerability is present in versions 6.8.12 and 7.0.35, with all releases in the 5.x branch remaining susceptible to this issue. The impact is limited to file deletion; the application does not return file content or disclose the contents of the disk to the user. The primary threat is the disruption of service or the deletion of critical system assets, which can lead to application instability or the loss of important administrative data. The newer MultipleFiles uploader architecture serves as the secure design pattern that mitigates this risk by ensuring all deletion requests are validated against the actual record metadata."
}