---
id: "CVE-2026-62683"
page: "https://infrastack.ai/live/CVE-2026-62683"
kind: "vulnerability"
aliases: ["CVE-2026-62683", "GHSA-pp88-jhwj-5qh5"]
title: "File Browser: Trailing-slash directory deletion leaves public shares active for recreated paths"
severity: "low"
cvss: 3.1
epss: 0.00315
exploited: false
status: "open"
category: "package"
products: [{"name": "github.com/filebrowser/filebrowser/v2", "fixed": ["2.63.17"], "affected": "< 2.63.17", "ecosystem": "go"}]
ecosystems: ["go"]
tags: ["cwe-863", "file-browser", "go", "package", "self-hosted"]
not_affected_if: ["no-public-shares", "no-share-permission", "version-2.63.17-or-later"]
published_at: "2026-07-15T16:16:51+00:00"
first_seen_at: "2026-11-13T23:12:39+00:00"
updated_at: "2026-11-13T23:35:11+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-pp88-jhwj-5qh5", "first_seen_at": "2026-11-13T23:12:39+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62683", "first_seen_at": "2026-11-13T23:35:11+00:00"}]
exploit_sources: [{"type": "epss", "score": 0.00315, "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-62683"}]
---

# File Browser: Trailing-slash directory deletion leaves public shares active for recreated paths

Link for people: https://infrastack.ai/live/CVE-2026-62683 (this .md is for agents)

Deleting a shared directory through a path with a trailing slash leaves its public share link stored in the database. If a directory with the same path is later recreated, the old public URL serves the new contents without authentication.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- go:github.com/filebrowser/filebrowser/v2 affected < 2.63.17 fixed 2.63.17

## How to check

- Check the File Browser version with `filebrowser version` or the image tag; affected builds are below `2.63.17`.
- Review existing public shares in the admin UI or share list for links whose directory was deleted and later recreated.

## Fix

- File Browser: move to `2.63.17`.

## Timeline

- 2026-11-13T23:12:39+00:00 ghsa https://github.com/advisories/GHSA-pp88-jhwj-5qh5
- 2026-11-13T23:35:11+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-62683

## Documents

- [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/filebrowser/filebrowser/security-advisories/GHSA-pp88-jhwj-5qh5
- [advisory] Maintainer's advisory: github.com https://github.com/filebrowser/filebrowser/security/advisories/GHSA-pp88-jhwj-5qh5
- [fix] Patch: github.com https://github.com/filebrowser/filebrowser/commit/f30fca636c1af9ef401e9a82ff60391cb3db97e1
- [fix] Release: github.com https://github.com/filebrowser/filebrowser/releases/tag/v2.63.17

## From the sources

## Summary

File Browser v2.63.15 can leave a public directory share behind when the shared directory is deleted through a path with a trailing slash. The share cleanup path calls `DeleteWithPathPrefix(file.Path, userID)`, but the Bolt backend performs the database prefix query with the unnormalized argument before trimming the slash for boundary checks. For a stored share at `/a`, deleting `/a/` queries for paths prefixed by `/a/`, so the exact `/a` share is never loaded and never deleted.

If a directory with the same path is later recreated, the stale public share becomes active again and exposes the new directory contents through the old public URL.

## Impact

An authenticated user with share, download, and delete permissions can create a valid public share, delete the shared path with a trailing slash, and leave the public link in storage. The link is dormant while the path does not exist, but it exposes future content if the same path is recreated later. The final data exposure is unauthenticated through the public share URL.

This bypasses the intended lifecycle cleanup around public shares and is adjacent to the recent public-share path-existence and prefix-boundary fixes.

## Reproduction

The following test was run against v2.63.15, commit `be23ab3a15bf957928ecfed88de5ab67850c1b9c`.

1. Create a scoped user with share, download, and delete permissions.
2. Create `/a/old.txt` in that user's scope.
3. Store a valid public share row with `Hash: "h"`, `UserID: 1`, and `Path: "/a"`.
4. Send an authenticated delete request for `/a/` through the resource delete handler.
5. Confirm the directory is deleted.
6. Confirm share hash `h` still exists in storage.
7. Recreate `/a/future.txt`.
8. Request the public share handler at `h/` and observe that the unauthenticated response includes `future.txt`.

Command used for the local proof:

```bash
go test ./http -run TestValidationTrailingSlashDeleteLeavesExactDirectoryShare -count=1 -v
```

Observed result:

```text
=== RUN   TestValidationTrailingSlashDeleteLeavesExactDirectoryShare
--- PASS: TestValidationTrailingSlashDeleteLeavesExactDirectoryShare (0.03s)
PASS
ok  github.com/filebrowser/filebrowser/v2/http  0.044s
```

## Root cause

`storage/bolt/share.go` queries the share index before normalizing the path:

```go
func (s shareBackend) DeleteWithPathPrefix(pathPrefix string, userID uint) error {
    var links []share.Link
    if err := s.db.Prefix("Path", pathPrefix, &links); err != nil {
        ...
    }

    prefix := strings.TrimRight(pathPrefix, "/")

    for _, link := range links {
        if link.UserID != userID {
            continue
        }

        if link.Path != prefix && !strings.HasPrefix(link.Path, prefix+"/") {
            continue
        }
        ...
    }
}
```

For `pathPrefix == "/a/"`, the database prefix query can return descendants such as `/a/child`, but it does not return the exact share path `/a`. The later `TrimRight` cannot delete the exact share because that row was not loaded from storage.

`http/resource.go` passes the request-derived path into this cleanup before removing the resource:

```go
file, err := files.NewFileInfo(... Path: r.URL.Path ...)
...
err = d.store.Share.DeleteWithPathPrefix(file.Path, d.user.ID)
...
return d.user.Fs.RemoveAll(r.URL.Path)
```

A request for `/a/` therefore removes the directory but misses the exact `/a` share row.

## Remediation

Normalize the path before querying the share index, and cover both the exact normalized path and its descendants. Add regression tests where a stored share path `/a` is removed by `DeleteWithPathPrefix("/a/", userID)` and where `DELETE /api/resources/a/` deletes the exact public share row.

Fixed in version 2.63.17.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_