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

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

Which versions of FileBrowser are affected by EUVD-2026-30344?

FileBrowser versions prior to the patched commit contain a critical path traversal vulnerability affecting any organization using FileBrowser with shared storage links.. A patch is available.

How to fix or mitigate EUVD-2026-30344?

Within 24 hours: Identify all FileBrowser instances in your environment and document current versions; assess if any are exposed to untrusted users via public share links. Within 7 days: Apply vendor-released patch (commit 112740bdd41de7d5eb01e13ba49d406bfc463f69 or later) to all FileBrowser deployments; verify patches are applied and services restarted. Within 30 days: Conduct audit of share link creation and deletion logs; review file deletion events from the vulnerability window; implement access logging for all public share links.

FileBrowser EUVD-2026-30344

| CVE-2026-44542 CRITICAL

Path Traversal (CWE-22)

2026-05-07 https://github.com/gtsteffaniak/filebrowser

GHSA-fwj3-42wh-8673

Path Traversal

9.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

9.1 CRITICAL

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 07, 2026 - 03:46 vuln.today

Analysis Generated

May 07, 2026 - 03:46 vuln.today

CVE Published

May 07, 2026 - 03:28 nvd

CRITICAL 9.1

DescriptionGitHub Advisory

Summary

Attacker-controlled path input is joined with a trusted base path prior to sanitization, allowing traversal sequences (e.g., ../) to escape the intended shared directory. As a result, an unauthenticated attacker possessing a valid public share hash with delete permissions enabled can delete arbitrary files outside the shared directory within the share owner’s configured storage scope.

Affected Components

Two distinct vulnerable code paths:

Stable versions (e.g., gtstef/filebrowser:stable)

DELETE /public/api/resources?hash=<hash>&path=../victim Root cause: middleware.go:111 Issue: path query parameter is joined before SanitizeUserPath()

Development / HEAD (e.g., commit eabdfd9)

DELETE /public/api/resources/bulk?hash=<hash> Body: [{"path":"../victim"}] Root cause: resource.go:274 Issue: item.Path is joined before SanitizeUserPath()

Steps to reproduce (Stable Version)

1. Create a directory structure:

/folder/shared_subdir/   (shared)
/folder/protected.txt    (outside shared directory)

2. Create a public share:

Path: /shared_subdir
AllowDelete=true

3. Send request:

curl -X DELETE "http://localhost/public/api/resources?hash=<HASH>&path=../protected.txt"

#Observe:
#protected.txt is deleted despite being outside the shared directory

Proof of Concept (HEAD / bulk endpoint)

curl -X DELETE "http://localhost/public/api/resources/bulk?hash=<HASH>" \
  -H "Content-Type: application/json" \
  -d '[{"path":"../protected.txt"}]'

Alternative PoC Scripts:

poc_v3.sh (If the script fails due to environment differences, the manual PoC above reliably reproduces the issue.)

Impact

An unauthenticated attacker with access to a public share link configured with delete permissions enabled can delete attacker-chosen files outside the shared directory, anywhere within the share owner’s storage scope. This results in unauthorized data loss and potential service disruption.

AnalysisAI

Path traversal in FileBrowser allows unauthenticated attackers possessing a valid public share hash with delete permissions to delete arbitrary files anywhere within the share owner's storage scope. The vulnerability exists in both stable and development versions due to user-controlled path input being joined with trusted base paths before sanitization in middleware.go:111 and resource.go:274. Proof-of-concept exploit code is publicly available via GitHub advisory GHSA-fwj3-42wh-8673. Vendor-released patch available in commit 112740bdd41de7d5eb01e13ba49d406bfc463f69.

Technical ContextAI

FileBrowser is a Go-based web file management application (github.com/gtsteffaniak/filebrowser) that provides public sharing capabilities. The vulnerability stems from CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). Two distinct code paths are affected: the stable version's DELETE /public/api/resources endpoint processes the 'path' query parameter, while the development branch's DELETE /public/api/resources/bulk endpoint processes JSON body path arrays. In both cases, the code joins user-supplied path strings containing traversal sequences (../) with the intended share directory base path before invoking SanitizeUserPath(), rendering the sanitization ineffective. The vulnerability occurs in the request processing middleware and resource deletion handlers, allowing attackers to construct paths that escape the share's intended directory boundary while remaining within the filesystem scope accessible to the share owner's account.

RemediationAI

Upgrade to FileBrowser commit 112740bdd41de7d5eb01e13ba49d406bfc463f69 or later (pseudo-version 0.0.0-20260501183844-112740bdd41d for Go module resolution), which relocates SanitizeUserPath() calls to execute before path joining operations in both middleware.go and resource.go. Patch commit available at https://github.com/gtsteffaniak/filebrowser/commit/112740bdd41de7d5eb01e13ba49d406bfc463f69. If immediate patching is not feasible, implement these compensating controls with noted trade-offs: (1) Disable delete permissions on all public shares via AllowDelete=false in share configuration - this fully mitigates the vulnerability but removes legitimate delete functionality for authorized share users. (2) Revoke and regenerate all existing public share hashes to invalidate potential attacker access - this requires redistributing new share links to legitimate users, causing operational disruption. (3) Implement network-level access controls restricting public share endpoints to trusted IP ranges - this reduces exposure but contradicts the intended public sharing use case and may not be viable for internet-facing deployments. No application-layer workaround exists to filter path traversal sequences without code modification, as the vulnerability occurs in core request handling logic. Organizations should audit logs for suspicious DELETE requests to /public/api/resources or /public/api/resources/bulk endpoints containing ../ sequences as potential exploitation indicators.