CVE-2026-54177

## Summary `HasUploadFields` (used via `CrudTrait` on Backpack-managed models) and the `withFiles()` uploader preserve the client-supplied file extension without validation. On installations using a `public` disk with `php artisan storage:link`, this allows an authenticated administrator to upload a file with a server-executable extension that the web server will pass to the PHP interpreter - if no MIME or other type of upload validation is present. ## Details The `uploadFileToDisk` and `uploadMultipleFilesToDisk` methods hash the filename stem but write the client-supplied extension to disk verbatim — no allowlist, blocklist, or MIME check is applied inside the trait itself. The newer `withFiles()` path (via `FileNameGenerator`) resolves the extension from the file's MIME type rather than the client filename, but also does not block server-executable types. Applications that follow the Backpack quickstart without adding explicit `mimes:` or `mimetypes:` validation rules in their form requests are affected. ## Impact An authenticated administrator with access to an upload-enabled CRUD panel, on a site using the `public` disk with web-accessible storage and no MIME type validation, can upload a server-executable file and achieve remote code execution. **Conditions required for exploitation:** - Authenticated admin access to a Backpack CRUD panel - An upload field with no `mimes:` / `mimetypes:` validation rule - The `public` disk in use (standard pattern for web-visible uploads) - `php artisan storage:link` in place - A web server + PHP-FPM stack (default on most hosts) ## Fix A denylist for server-executable extensions has been added to both `HasUploadFields` and `FileNameGenerator`. Image-typed fields now additionally enforce an allowlist. This is defence-in-depth — it does not replace application-level validation. ## Recommended developer action Review all upload fields and add explicit `mimes:` or `mimetypes:` validation in your form requests or fiel