Listen to this Post
The vulnerability exists because the API endpoint `/api/v1/{object_type}/{id}/files` in `app/Http/Controllers/Api/UploadedFilesController.php` incorrectly authorizes requests using `view` permission instead of `write` or `create` permissions.
In Snipe-IT versions up to 8.4.0, any authenticated user who can view an asset, consumable, accessory, or license can send a POST request to that endpoint.
The controller lacks a proper `Gate::check(‘update’, $object)` or similar write-level gate.
Instead, it only checks Gate::check('view', $object), which grants upload capabilities to read-only users.
An attacker with low-privileged API credentials (e.g., a helpdesk user who can view assets) can exploit this.
The attacker crafts a multipart POST request containing a malicious file – for example, a PHP web shell named shell.php.
The request is sent to `/api/v1/assets/{asset_id}/files` where the attacker has view access.
The server accepts the upload, stores the file in the configured uploads directory (typically public/uploads), and creates an audit log entry attributed to the attacker.
Because the uploaded file retains its original extension and is placed in a web-accessible location, the attacker can later request https://target.com/uploads/shell.php`.
If the web server executes PHP (or other scriptable file types), the attacker gains arbitrary code execution on the host.
The application does not validate file types or sanitize filenames sufficiently against RCE.
The audit log records the action as a “file upload” under the “view” permission, which does not trigger typical write-based alerts.
The vulnerability affects all object types that support file attachments: assets, consumables, accessories, licenses, users, and custom fields.
The issue was introduced in earlier versions and persisted until commit `676a9958` (2026-03-10).
<h2 style="color: blue;">No workarounds exist; only upgrading mitigates the risk.</h2>
This is a classic violation of the principle of least privilege, where a read operation leads to a write effect and ultimately remote code execution.
<h2 style="color: blue;">dailycve form:</h2>
Platform: Snipe-IT platform
Version: Through 8.4.0
Vulnerability : View-permission upload
Severity: Critical
date: 2026-03-10
<h2 style="color: blue;">Prediction: 2026-03-15</h2>
<h2 style="color: blue;">What Undercode Say:</h2>
<h2 style="color: blue;">Analytics</h2>
Check installed version (if accessible via CLI) php artisan snipeit:version | grep -E "8\.[0-4]\.[0-9]" Query API version endpoint curl -k -X GET https://target.com/api/v1/status -H "Authorization: Bearer $VIEW_TOKEN" | jq '.version' Detect vulnerable endpoint response for a view-permission user curl -k -X POST https://target.com/api/v1/assets/1/files \ -H "Authorization: Bearer $VIEW_TOKEN" \ -F "[email protected]" Monitor audit log for unexpected uploads tail -f storage/logs/laravel.log | grep "UploadedFilesController"
<h2 style="color: blue;">Exploit:</h2>
Send POST to `/api/v1/assets/{viewable_id}/files` with valid Bearer token of a user having only `view` permission. Attach PHP file. Then accesshttps://target.com/uploads/filename.php` to execute commands.
Protection from this CVE
Upgrade to Snipe-IT version 8.4.1 or later (commit after 676a9958). If upgrade impossible, revoke all `view` permissions for untrusted users manually via database, or disable file uploads completely by removing the route.
Impact:
Remote authenticated attacker with only read/view privileges achieves arbitrary code execution, leading to full server compromise, data theft, and lateral movement.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
