CVE-2026-55496
MediumCVSS 4.3Exploitation Probability (EPSS)
Low risk29th percentile - higher than 29% of all known CVEs
Summary
Cloudreve before version 4.17.0 has a vulnerability in the GET /api/v4/user/search endpoint that calls SearchActive without adding a StatusActive predicate and serializes matches at RedactLevelUser. This allows any logged-in user to enumerate email addresses and profile metadata for inactive or banned accounts.
Risk Assessment
An attacker can obtain sensitive information such as email addresses of inactive or banned users, violating privacy and potentially enabling further attacks.
Recommendation
Upgrade Cloudreve to version 4.17.0 or later, which includes a fix to properly filter account status.
Other vulnerabilities in Cloudreve
See all- CVE-2026-62323Medium
In Cloudreve before version 4.17.0, WOPI session validation uses only the session-id prefix of the access token and does not enforce the requested action, allowing a malicious viewer to forge the token suffix and invoke file write operations.
- CVE-2026-55502High
Vulnerability in Cloudreve before 4.17.0, where the POST /api/v4/admin/policy/oauth/signin endpoint requires only Admin.Read permission but allows modification of OneDrive storage policy credentials without Admin.Write, enabling changes to secret and app_id.
- CVE-2026-55499Medium
In Cloudreve before version 4.17.0, a single-file share event-stream subscription resolves the share root to the owner's parent folder and subscribes to it, allowing an authenticated share recipient to receive information about unshared sibling files and folders.
- CVE-2026-55497Medium
Cloudreve before version 4.17.0 has a vulnerability in thumbnail and avatar decoders that limit compressed file size but not decoded pixel dimensions. An authenticated user can submit a small PNG, JPEG, or GIF that triggers unbounded memory allocation and terminates the Cloudreve process due to an out-of-memory error.
- CVE-2026-55495Medium
Cloudreve before version 4.17.0 has a vulnerability in the WOPI PUT_RELATIVE handler that passes X-WOPI-SuggestedTarget to URI.JoinRaw as a path rather than a filename. This allows slash and dot-dot segments to escape the source file directory and create or conditionally overwrite files elsewhere in the same owner account.
- CVE-2026-54563High
In Cloudreve prior to version 4.16.1, a WebDAV account scoped to a configured folder can bypass the restriction by sending paths containing encoded ".." characters (e.g., %2e%2e). The stripPrefix function in pkg/webdav/webdav.go joins the decoded request suffix to the account root without checking containment, allowing reading and listing files outside the folder, and for writable accounts also creating, overwriting, moving, or deleting them.
- CVE-2026-54562Medium
Cloudreve before version 4.16.1 allows non-admin users with remote download permission to fetch internal-only URLs (e.g., localhost, loopback) via the POST /api/v4/workflow/download endpoint. The vulnerability is due to missing blocking of loopback, localhost, IPv6 localhost, and redirect-to-loopback targets.
- CVE-2026-54560High
Cloudreve versions 4.12.0 through 4.16.1 issue OAuth access tokens without the client_id claim, causing the JWT verifier to not load token scopes into the request context. The RequiredScopes function treats such requests as non-scoped session authentication, allowing a low-scope OAuth token to call APIs requiring higher scopes, including file, share, workflow, user settings, WebDAV accounts, and potentially admin scopes.
- CVE-2026-25726High
Vulnerability in Cloudreve (self-hosted file management and sharing system) before version 4.13.0. The application uses a weak PRNG (math/rand) seeded with admin account creation time. An attacker can recover the secret_key and forge JWT tokens, leading to admin account takeover.
Original NVD description (English source)
Cloudreve is a self-hosted file management and sharing system. Prior to 4.17.0, GET /api/v4/user/search calls SearchActive without adding a StatusActive predicate and serializes matches at RedactLevelUser, allowing any logged-in user to enumerate email addresses and profile metadata for inactive or banned accounts. The service calls userClient.SearchActive, but despite its name that method filters only by email/nickname keyword and never adds a StatusActive predicate — while the sibling lookups GetActiveByID and GetActiveByDavAccount, defined a few lines above it, do. Search hits are serialized at RedactLevelUser, which includes the email address. This issue is fixed in version 4.17.0.