File Browser CVE-2026-62683

Exploitation requires all of the following specific conditions to be met simultaneously: (1) A public share must have been previously created for a directory on the File Browser instance, stored in BoltDB as path '/X' (without trailing slash); (2) that directory must be deleted via the trailing-slash API path (e.g., 'DELETE /api/resources/X/'), which is the standard behavior of the File Browser web UI and REST API for directory resources - this requires the deleting user to have at least low-privilege authenticated access; (3) the same directory path must be subsequently recreated and populated with content. Exploitation is further constrained by: the share-link holder needing to retain the old URL; the path recreation being performed by a separate action (typically by a different user or administrator); and the vulnerability affecting only BoltDB-backed instances. Exploitation is not possible against paths that never had a public share, against file resources (as opposed to directories), or if the path is never recreated after deletion.

The NVD-reported CVSS 3.1 score of 3.1 (Low) is consistent with the constrained exploitation scenario: AC:H reflects the multi-step precondition chain (active share exists, deletion must use trailing-slash path, and the same path must be recreated); PR:L confirms an authenticated user is required to trigger the deletion; and C:L bounds impact to unauthorized read of files placed at the recreated path. EPSS data was not provided in the input, so exploitation probability cannot be quantified. The vulnerability is absent from CISA KEV, and no standalone proof-of-concept exploit has been identified beyond the regression test embedded in the fix commit. The 'Authentication Bypass' tag is somewhat misleading - this is better characterized as a share-revocation residue flaw rather than a traditional authentication bypass. Real-world risk depends heavily on whether: (a) public shares are in active use on the instance, (b) directory paths are reused after deletion, and (c) someone retains an old share URL. For most File Browser deployments, all three conditions being simultaneously true is uncommon, keeping actual exploitation risk low despite the network-accessible nature of the stale share endpoint.

An authenticated low-privilege user creates a public share link for the directory '/a/' on a File Browser instance. The user (or an administrator) then deletes '/a/' through the standard web interface, which issues the request as 'DELETE /api/resources/a/' - triggering the buggy trailing-slash code path that leaves the '/a' share record intact in BoltDB. When an administrator later recreates '/a/' and populates it with sensitive files, anyone in possession of the original share URL can immediately browse and download those new files without any additional authentication.