GHSA-fmm7-x4gx-8jhr

Описание

Summary

A scoped, non-admin File Browser user holding only the Create permission can delete arbitrary files outside their scope (other tenants' data, and the application's own database) via the upload failure-cleanup path. This is an incomplete fix of CVE-2026-54094: the v2.63.14 ScopedFs containment wrapper was applied to read/write/list/rename but NOT to the delete path. Confidentiality is preserved (reads stay blocked); integrity and availability are not.

ScopedFs.RemoveAll is the one dereferencing operation that skips the symlink guard every other method enforces. The direct-upload handler runs RemoveAll on the user-controlled path during failed-upload cleanup, gated only by Perm.Create. If an escaping directory symlink already exists inside the user's scope, an authenticated create-only user can delete an out-of-scope target, bypassing both the ScopedFs boundary and the Perm.Delete gate.

Affected code: https://github.com/filebrowser/filebrowser/blob/be23ab3a15bf957928ecfed88de5ab67850c1b9c/http/resource.go#L172-L174

Details

CVE-2026-54094 was fixed by a ScopedFs afero wrapper whose guard() resolves every path component with filepath.EvalSymlinks and rejects out-of-scope targets. guard() is invoked on read, write, list, rename, stat, etc. The fix is incomplete; two gaps combine:

1. ScopedFs.Remove and ScopedFs.RemoveAll skip guard() (files/scoped.go:138-144) — they call s.base.Remove/RemoveAll directly, unlike every other method.
2. resourcePostHandler does not return on a NewFileInfo containment error (http/resource.go:125-180). For an out-of-scope path NewFileInfo fails, but the handler only uses that for the override branch (if err == nil) and falls through to writeFile, which is correctly guard-blocked and errors — triggering the failure-cleanup _ = d.user.Fs.RemoveAll(r.URL.Path) (http/resource.go:173) on the unvalidated path.

Because Go's os.RemoveAll follows a symlinked ancestor, RemoveAll("link/secret.txt") where link -> /srv/victim deletes /srv/victim/secret.txt, outside scope. The HTTP response is 403 (write blocked), masking the deletion.

Of the three handlers calling RemoveAll, only resourcePostHandler is exploitable; resourceDeleteHandler (:114) and tusDeleteHandler (:264) return the NewFileInfo error first (shadowed, confirmed by negative controls). If the target is a directory, RemoveAll recursively removes out-of-scope contents.

Precondition

An escaping directory symlink must already exist inside the user's scope. File Browser exposes no symlink-creation API, so it is planted out of band (admin, mounted/shared volume, restored backup, extracted archive, another process). This is the same threat model accepted by CVE-2026-54094.

Proof of concept

Root /tmp/fb-root, a Create-only non-admin user scoped to /scope with Perm.Create=true (and Perm.Delete=false — the bug must not need it), and a pre-existing symlink /tmp/fb-root/scope/link -> /tmp/fb-out:

Minimal HTTP summary (Create-only user carol, scope /attacker, pre-existing symlink /attacker/link -> /srv/victim, file /srv/victim/secret.txt):

Verified blast radius (per-case HTTP + on-disk before/after captured): create-only no-override deletion; cross-tenant deletion; full-instance DoS (delete the database dir → all users/shares/config gone, admin login fails); negative controls on the DELETE sinks (403, file survives).

Impact

A per-tenant / per-share scoped user with only Create can destroy any file the File Browser process can reach via a symlink lexically inside their scope: other tenants' data or the application database (instance DoS). A create-only user deletes out-of-scope files reachable through an escaping symlinked directory, bypassing the ScopedFs boundary and the Perm.Delete gate. If the target is a directory, RemoveAll recursively removes out-of-scope contents. Precondition: a symlink present in the user's scope — identical to the parent CVE-2026-54094, which the project treated as in-scope, and which arises naturally via mounted volumes, restored backups, or extracted archives.

Suggested fix

1. Add guard() to ScopedFs.Remove and ScopedFs.RemoveAll (files/scoped.go), mirroring the other methods (closes the class for all callers).
2. Defense-in-depth: in resourcePostHandler, return early when NewFileInfo returns a non-not-exist error (do not fall through to writeFile/cleanup on a path that failed containment).

References

• Incomplete fix of CVE-2026-54094 / GHSA-239w-m3h6-ch8v.
• Affected code: files/scoped.go (ScopedFs.Remove, ScopedFs.RemoveAll), reached from http/resource.go (resourcePostHandler failure-cleanup, line 173).
• Confirmed unpatched at HEAD be23ab3 (v2.63.15); no open issue/PR addresses the Remove/RemoveAll gap.