Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestion detail

Untriaged
Permalink CVE-2026-62683
3.1 LOW
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): Low (L)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 5 hours ago Activity log
  • Created suggestion 5 hours ago
File Browser: Trailing-slash delete leaves a stale public share behind

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.17, File Browser can leave a public directory share behind when the shared directory is deleted through a path with a trailing slash because the share cleanup path calls DeleteWithPathPrefix(file.Path, userID) and the Bolt backend performs the database prefix query with the unnormalized path before trimming the slash for boundary checks, so deleting /a/ does not delete the stored /a share and the stale public share exposes future content if the same path is recreated. This issue is fixed in version 2.63.17.

Affected products

filebrowser
  • ==< 2.63.17

Matching in nixpkgs