What is the CVSS score of EUVD-2026-44705?

EUVD-2026-44705 has a CVSS 3.1 base score of 3.1 (Low). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.2%.

Is there a patch available for EUVD-2026-44705?

Yes, a patch is available for EUVD-2026-44705. Update the affected software to the latest version immediately.

File Browser EUVD-2026-44705

| CVE-2026-62683 LOW

Incorrect Authorization (CWE-863)

2026-07-15 GitHub_M

Authentication Bypass Filebrowser

3.1

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

3.1 LOW

AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

vuln.today AI

3.1 LOW

AC:H for the mandatory multi-step precondition chain; PR:L because directory deletion requires authentication; C:L as the sole impact is unauthorized read of files at the recreated path.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jul 15, 2026 - 17:48 EUVD

Source Code Evidence Fetched

Jul 15, 2026 - 16:19 vuln.today

Analysis Generated

Jul 15, 2026 - 16:19 vuln.today

DescriptionCVE.org

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.

AnalysisAI

File Browser prior to 2.63.17 retains stale public directory share records after a shared directory is deleted via a trailing-slash path, because the Bolt storage backend queries for shares using the unnormalized path before trimming the slash - causing the exact-match share record (stored as '/a') to be missed by a query against '/a/'. If the directory is subsequently recreated at the same path, any holder of the original share URL immediately gains unauthorized read access to the new directory contents. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.

Technical ContextAI

File Browser is an open-source, self-hosted web file manager (CPE: cpe:2.3:a:filebrowser:filebrowser:*:*:*:*:*:*:*:*) that uses a BoltDB-backed storage layer to persist public share links. Share records are stored with a normalized Path field (no trailing slash). The resource-delete API for directories appends a trailing slash to the requested path (e.g., DELETE /api/resources/a/ becomes path '/a/'). The share cleanup function DeleteWithPathPrefix passed this unnormalized path directly to the Bolt prefix query before calling strings.TrimRight, so the prefix scan searched for entries beginning with '/a/' and found children but not the exact stored '/a' share. The root cause class is CWE-863 (Incorrect Authorization) - specifically, an authorization side-effect (share revocation) fails silently due to path normalization ordering. Fix commit f30fca636c1af9ef401e9a82ff60391cb3db97e1 moves TrimRight to before the database query, ensuring '/a/' is normalized to '/a' prior to the Bolt prefix lookup.

RemediationAI

Upgrade to File Browser version 2.63.17 or later, available at https://github.com/filebrowser/filebrowser/releases/tag/v2.63.17. This release applies the one-line fix from commit f30fca636c1af9ef401e9a82ff60391cb3db97e1 that normalizes trailing slashes before the BoltDB prefix query. If immediate upgrade is not feasible, administrators should audit the share database after any directory deletion - particularly deletions performed via the web interface or REST API, which send directory paths with trailing slashes - and manually revoke any share records whose target path no longer exists. As a further compensating control, restricting the ability to create public shares to trusted users reduces the population of shares that could be left dangling; note that this does not remediate existing stale shares. There are no known workarounds that address the root cause without code changes.