https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 13 Nov 2026 04:52:13 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-54097 <p>File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.6, 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&#39;s stored share.Link.Path. The file contents of the victim are not exposed, but the victim&#39;s share links are irrevocably wiped. This vulnerability is fixed in 2.63.6.</p> <p>File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.6, 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&#39;s stored share.Link.Path. The file contents of the victim are not exposed, but the victim&#39;s share links are irrevocably wiped. This vulnerability is fixed in 2.63.6.</p> https://db.gcve.eu/vuln/fkie_cve-2026-54097 https://db.gcve.eu/vuln/ghsa-5ww9-jg6q-38r7 <p><strong>Affected:</strong> Go: github.com/filebrowser/filebrowser, Go: github.com/filebrowser/filebrowser/v2</p> <p>### 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&#39;s stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim&#39;s share links are irrevocably wiped.</p> <p>### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling:</p> <p>```go // http/resource.go err = d.store.Share.DeleteWithPathPrefix(file.Path) ```</p> <p>`file.Path` here is the *logical* path from the URL of the deleting user&#39;s request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend:</p> <p>```go // storage/bolt/share.go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error { var links []share.Link if err := s.db.Prefix(&#34;Path&#34;, pathPrefix, &amp;links); err != nil { return err } for _, link := range links { err = errors.Join(err, s.db.DeleteStruct(&amp;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 &amp;&amp; !d.user.Perm.Admin → 403`. The file-de…</p> <p><strong>Affected:</strong> Go: github.com/filebrowser/filebrowser, Go: github.com/filebrowser/filebrowser/v2</p> <p>### 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&#39;s stored `share.Link.Path`. The file contents of the victim are not exposed, but the victim&#39;s share links are irrevocably wiped.</p> <p>### Details `resourceDeleteHandler` in `http/resource.go` cleans up any share records that reference a deleted file by calling:</p> <p>```go // http/resource.go err = d.store.Share.DeleteWithPathPrefix(file.Path) ```</p> <p>`file.Path` here is the *logical* path from the URL of the deleting user&#39;s request (e.g. `/a`), not the absolute filesystem path. It is passed as-is to the bolt backend:</p> <p>```go // storage/bolt/share.go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string) error { var links []share.Link if err := s.db.Prefix(&#34;Path&#34;, pathPrefix, &amp;links); err != nil { return err } for _, link := range links { err = errors.Join(err, s.db.DeleteStruct(&amp;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 &amp;&amp; !d.user.Perm.Admin → 403`. The file-de…</p> https://db.gcve.eu/vuln/ghsa-5ww9-jg6q-38r7