File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.1, when an admin revokes a user's Share and Download permissions, existing share links created by that user remain fully accessible to unauthenticated users. The public share download handler does not re-check the share owner's current permissions. This vulnerability is fixed in 2.63.1.

Affected: Go: github.com/filebrowser/filebrowser/v2

When an admin revokes a user's Share and Download permissions, existing share links created by that user remain fully accessible to unauthenticated users. The public share download handler does not re-check the share owner's current permissions. Verified with a running PoC against v2.62.2 (commit 860c19d).

## Details

Share creation (`http/share.go:21-29`) correctly checks permissions:

func withPermShare(fn handleFunc) handleFunc { return withUser(func(w http.ResponseWriter, r *http.Request, d *data) (int, error) { if !d.user.Perm.Share || !d.user.Perm.Download { return http.StatusForbidden, nil } return fn(w, r, d) }) }

But share access (`http/public.go:18-87`, `withHashFile`) does not:

var withHashFile = func(fn handleFunc) handleFunc { return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) { link, err := d.store.Share.GetByHash(id) // line 21: checks share exists authenticateShareRequest(r, link) // line 26: checks password user, err := d.store.Users.Get(...) // line 31: checks user exists d.user = user // line 36: sets user file, err := files.NewFileInfo(...) // line 38: gets file // MISSING: no check for d.user.Perm.Share or d.user.Perm.Download } }

## Proof of Concept (runtime-verified)

# Step 1: Login as admi…