CVE-2026-32758: File Browser has an Access Rule Bypass via Path Traversal in Copy/Rename Destination Parameter

Published Mar 16, 2026
·
Updated

Description

The resourcePatchHandler in http/resource.go validates the destination path against configured access rules before the path is cleaned/normalized. The rules engine (rules/rules.go) uses literal string prefix matching (strings.HasPrefix) or regex matching against the raw path. The actual file operation (fileutils.Copy, patchAction) subsequently calls path.Clean() which resolves .. sequences, producing a different effective path than the one validated.

This allows an authenticated user with Create or Rename permissions to bypass administrator-configured deny rules by including .. (dot-dot) path traversal sequences in the destination query parameter of a PATCH request.

Steps to Reproduce

1. Verify the rule works normally

bash This should return 403 Forbidden curl -X PATCH \ -H "X-Auth: <alicejwt>" \ "http://host/api/resources/public/test.txt?action=copy&destination=%2Frestricted%2Fcopied.txt"

2. Exploit the bypass

bash This should succeed despite the deny rule curl -X PATCH \ -H "X-Auth: <alicejwt>" \ "http://host/api/resources/public/test.txt?action=copy&destination=%2Fpublic%2F..%2Frestricted%2Fcopied.txt"

3. Result

The file test.txt is copied to /restricted/copied.txt despite the deny rule for /restricted/.

Root Cause Analysis

In http/resource.go:209-257:

go dst := r.URL.Query().Get("destination") // line 212 dst, err := url.QueryUnescape(dst) // line 214 — dst contains ".." if !d.Check(src) || !d.Check(dst) { // line 215 — CHECK ON UNCLEANED PATH return http.StatusForbidden, nil }

In rules/rules.go:29-35:

go func (r Rule) Matches(path string) bool { if r.Regex { return r.Regexp.MatchString(path) // regex on literal path } return strings.HasPrefix(path, r.Path) // prefix on literal path }

In fileutils/copy.go:12-17:

go func Copy(afs afero.Fs, src, dst string, ...) error { if dst = path.Clean("/" + dst); dst == "" { // CLEANING HAPPENS HERE, AFTER CHECK return os.ErrNotExist }

The rules check sees /public/../restricted/copied.txt (no match for /restricted/ prefix). The file operation resolves it to /restricted/copied.txt (within the restricted path).

Secondary Issue

In the same handler, the error from url.QueryUnescape is checked after d.Check() runs (lines 214-220), meaning the rules check executes on a potentially malformed string if unescaping fails.

Impact

An authenticated user with Copy (Create) or Rename permission can write or move files into any path within their scope that is protected by deny rules. This bypasses both:

- Prefix-based rules: strings.HasPrefix on uncleaned path misses the match - Regex-based rules: Standard patterns like ^/restricted/. fail on uncleaned path

Cannot be used to:

- Escape the user's BasePathFs scope (afero prevents this) - Read from restricted paths (GET handler uses cleaned r.URL.Path)

Suggested Fix

Clean the destination path before the rules check:

go dst, err := url.QueryUnescape(dst) if err != nil { return errToStatus(err), err } dst = path.Clean("/" + dst) src = path.Clean("/" + src) if !d.Check(src) || !d.Check(dst) { return http.StatusForbidden, nil } if dst == "/" || src == "/" { return http.StatusForbidden, nil }

Other sources

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Versions 2.61.2 and below are vulnerable to Path Traversal through the resourcePatchHandler (http/resource.go). The destination path in resourcePatchHandler is validated against access rules before being cleaned/normalized, while the actual file operation calls path.Clean() afterward—resolving .. sequences into a different effective path. This allows an authenticated user with Create or Rename permissions to bypass administrator-configured deny rules (both prefix-based and regex-based) by injecting .. sequences in the destination parameter of a PATCH request. As a result, the user can write or move files into any deny-rule-protected path within their scope. However, this cannot be used to escape the user's BasePathFs scope or read from restricted paths. This issue has been fixed in version 2.62.0.

MITRE

Affected Software

2 affected componentsFixes available
go/github.com/filebrowser/filebrowser/v2<=2.61.2
2.62.0
Filebrowser Filebrowser<2.62.0

Event History

Mar 16, 2026
Advisory Published
via GitHub·08:45 PM
Data Sourced
via GitHub·08:45 PM
DescriptionSeverityWeaknessAffected Software
Mar 19, 2026
CVE Published
via MITRE·11:22 PM
Data Sourced
via MITRE·11:22 PM
DescriptionSeverityWeakness
Mar 20, 2026
Data Sourced
via NVD·12:16 AM
RemedyDescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-32758?

CVE-2026-32758 has a high severity due to improper path validation leading to potential access control issues.

2

How do I fix CVE-2026-32758?

To fix CVE-2026-32758, update the affected software package to version 2.62.0 or later.

3

What systems are affected by CVE-2026-32758?

CVE-2026-32758 affects all versions of the GitHub repository 'github.com/filebrowser/filebrowser/v2' up to and including version 2.61.2.

4

What type of vulnerability is CVE-2026-32758?

CVE-2026-32758 is an access control vulnerability due to improper validation of paths.

5

Can CVE-2026-32758 be exploited remotely?

Yes, CVE-2026-32758 can potentially be exploited remotely if an attacker can craft URLs that bypass access controls.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203