### Summary A low-privileged authenticated user of filebrowser (with `create` + `delete` permissions in their own isolated scope) can silently destroy share-link records belonging to any other user — including the administrator — by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped. ### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling: ```go // http/resource.go err = d.store.Share.DeleteWithPathPrefix(file.Path) ``` `file.Path` here is the *logical* path from the URL of the deleting user's request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend: ```go // storage/bolt/share.go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error { var links []share.Link if err := s.db.Prefix("Path", pathPrefix, &links); err != nil { return err } for _, link := range links { err = errors.Join(err, s.db.DeleteStruct(&share.Link{Hash: link.Hash})) } return err } ``` **Why the design contradicts this behavior.** `share.Link` carries a `UserID` field and the application elsewhere treats shares as per-user owned resources. `shareDeleteHandler` explicitly enforces `link.UserID != d.user.ID && !d.user.Perm.Admin → 403`. The file-deletion side-effect path is the only location that bypasses this rule. ### Impact - Integrity: unauthorized deletion of share-link metadata belonging to arbitrary users, including administrators. - Availability: effective denial-of-service of the share-link feature — a cooperating (or malicious) low-priv user can wipe the bulk of existing share links by iterating a short set of one- and two-character prefixes.
### Summary A low-privileged authenticated user of filebrowser (with `create` + `delete` permissions in their own isolated scope) can silently destroy share-link records belonging to any other user — including the administrator — by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped. ### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling: ```go // http/resource.go err = d.store.Share.DeleteWithPathPrefix(file.Path) ``` `file.Path` here is the *logical* path from the URL of the deleting user's request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend: ```go // storage/bolt/share.go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error { var links []share.Link if err := s.db.Prefix("Path", pathPrefix, &links); err != nil { return err } for _, link := range links { err = errors.Join(err, s.db.DeleteStruct(&share.Link{Hash: link.Hash})) } return err } ``` **Why the design contradicts this behavior.** `share.Link` carries a `UserID` field and the application elsewhere treats shares as per-user owned resources. `shareDeleteHandler` explicitly enforces `link.UserID != d.user.ID && !d.user.Perm.Admin → 403`. The file-deletion side-effect path is the only location that bypasses this rule. ### Impact - Integrity: unauthorized deletion of share-link metadata belonging to arbitrary users, including administrators. - Availability: effective denial-of-service of the share-link feature — a cooperating (or malicious) low-priv user can wipe the bulk of existing share links by iterating a short set of one- and two-character prefixes.
Update github.com/filebrowser/filebrowser/v2 to 2.63.6 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFile Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix affects github.com/filebrowser/filebrowser (go), github.com/filebrowser/filebrowser/v2 (go). Severity is high. ### Summary A low-privileged authenticated user of filebrowser (with `create` + `delete` permissions in their own isolated scope) can silently destroy share-link records belonging to any other user — including the administrator — by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped. ### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling: ```go // http/resource.go err = d.store.Share.DeleteWithPathPrefix(file.Path) ``` `file.Path` here is the *logical* path from the URL of the deleting user's request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend: ```go // storage/bolt/share.go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error { var links []share.Link if err := s.db.Prefix("Path", pathPrefix, &links); err != nil { return err } for _, link := range links { err = errors.Join(err, s.db.DeleteStruct(&share.Link{Hash: link.Hash})) } return err } ``` **Why the design contradicts this behavior.** `share.Link` carries a `UserID` field and the application elsewhere treats shares as per-user owned resources. `shareDeleteHandler` explicitly enforces `link.UserID != d.user.ID && !d.user.Perm.Admin → 403`. The file-deletion side-effect path is the only location that bypasses this rule. ### Impact - Integrity: unauthorized deletion of share-link metadata belonging to arbitrary users, including administrators. - Availability: effective denial-of-service of the share-link feature — a cooperating (or malicious) low-priv user can wipe the bulk of existing share links by iterating a short set of one- and two-character prefixes.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/filebrowser/filebrowsergo | <=1.11.0 | Not reported |
| github.com/filebrowser/filebrowser/v2go | <=2.63.5 | 2.63.6 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/filebrowser/filebrowser/v2 to 2.63.6 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFile Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix affects github.com/filebrowser/filebrowser (go), github.com/filebrowser/filebrowser/v2 (go). Severity is high. ### Summary A low-privileged authenticated user of filebrowser (with `create` + `delete` permissions in their own isolated scope) can silently destroy share-link records belonging to any other user — including the administrator — by performing a legitimate DELETE on a file in their own directory whose logical path happens to be a byte-prefix of another user's stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim's share links are irrevocably wiped. ### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling: ```go // http/resource.go err = d.store.Share.DeleteWithPathPrefix(file.Path) ``` `file.Path` here is the *logical* path from the URL of the deleting user's request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend: ```go // storage/bolt/share.go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error { var links []share.Link if err := s.db.Prefix("Path", pathPrefix, &links); err != nil { return err } for _, link := range links { err = errors.Join(err, s.db.DeleteStruct(&share.Link{Hash: link.Hash})) } return err } ``` **Why the design contradicts this behavior.** `share.Link` carries a `UserID` field and the application elsewhere treats shares as per-user owned resources. `shareDeleteHandler` explicitly enforces `link.UserID != d.user.ID && !d.user.Perm.Admin → 403`. The file-deletion side-effect path is the only location that bypasses this rule. ### Impact - Integrity: unauthorized deletion of share-link metadata belonging to arbitrary users, including administrators. - Availability: effective denial-of-service of the share-link feature — a cooperating (or malicious) low-priv user can wipe the bulk of existing share links by iterating a short set of one- and two-character prefixes.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/filebrowser/filebrowsergo | <=1.11.0 | Not reported |
| github.com/filebrowser/filebrowser/v2go | <=2.63.5 | 2.63.6 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard