CVE-2026-55496: Cloudreve Information Disclosure Flaw

CVE-2026-55496 Overview

Cloudreve, a self-hosted file management and sharing system, contains an information disclosure vulnerability in versions prior to 4.17.0. The GET /api/v4/user/search endpoint invokes SearchActive without applying a StatusActive predicate, allowing any authenticated user to enumerate email addresses and profile metadata for inactive or banned accounts. Search results are serialized at RedactLevelUser, which exposes the email address field. The issue is fixed in Cloudreve 4.17.0. This weakness is classified as [CWE-200] Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact
Authenticated users can enumerate email addresses and profile metadata for deactivated or banned accounts, enabling reconnaissance against dormant identities.

Affected Products

Cloudreve versions prior to 4.17.0
Self-hosted Cloudreve file management deployments
Cloudreve instances exposing /api/v4/user/search

Discovery Timeline

2026-07-31 - CVE-2026-55496 published to NVD
2026-07-31 - Last updated in NVD database

Technical Details for CVE-2026-55496

Vulnerability Analysis

The vulnerability resides in Cloudreve's user search backend. The handler for GET /api/v4/user/search calls userClient.SearchActive, whose name implies filtering by active status. In practice, SearchActive only applies an email or nickname keyword predicate against the user table. Sibling helpers GetActiveByID and GetActiveByDavAccount, defined nearby in the same file, correctly enforce user.StatusEQ(user.StatusActive).

Because the active-status filter is absent, matched rows include users whose accounts are Inactive or Banned. Results are then serialized at RedactLevelUser, a redaction tier that includes the email address alongside nickname and profile metadata. Any logged-in user can issue targeted queries and iterate through partial keywords to enumerate the user directory, including dormant identities that administrators expect to be non-discoverable.

Root Cause

The root cause is a missing authorization predicate in the query builder. The SearchActive function name suggests active-user filtering, but the implementation only filters by keyword. The redaction level applied to search hits also exposes email addresses, compounding the disclosure.

Attack Vector

Exploitation requires only low-privilege authenticated access. An attacker with any valid Cloudreve user session sends crafted GET /api/v4/user/search?keyword=<value> requests and parses the returned JSON. Iterating through character prefixes yields the email addresses and profile metadata of banned or deactivated accounts.

// Patch: inventory/user.go — restricts search to StatusActive users
		ctx,
		c.client.User.Query().
			Where(user.Or(user.EmailContainsFold(keyword), user.NickContainsFold(keyword))).
+			Where(user.StatusEQ(user.StatusActive)).
			Limit(limit),
	).All(ctx)
}

Source: GitHub Commit 7e1289d

Detection Methods for CVE-2026-55496

Indicators of Compromise

High-volume GET /api/v4/user/search requests from a single authenticated session iterating through keyword prefixes.
Search requests returning user records whose status field maps to inactive or banned states.
Unusual API access patterns from low-privilege user accounts targeting the user directory.

Detection Strategies

Instrument the reverse proxy or application logs to record every /api/v4/user/search call with the requesting user ID, query string, and result count.
Alert when a single user issues more than a defined threshold of search requests within a short window, indicating enumeration.
Compare returned account IDs against the current active-user set and flag any hits on inactive or banned accounts.

Monitoring Recommendations

Forward Cloudreve access logs to a central SIEM and build detections for repeated search API queries by the same principal.
Track email address patterns appearing in API responses to identify potential harvesting of dormant accounts.
Monitor for post-enumeration activity such as password reset requests or phishing follow-ups targeting recently disclosed addresses.

How to Mitigate CVE-2026-55496

Immediate Actions Required

Upgrade Cloudreve to version 4.17.0 or later, which enforces the StatusActive predicate in the search query.
Audit access logs for prior GET /api/v4/user/search traffic and identify accounts that may have performed enumeration.
Rotate email addresses or notify users of banned and inactive accounts that may have been exposed.

Patch Information

The fix is available in Cloudreve 4.17.0. The patch adds Where(user.StatusEQ(user.StatusActive)) to the search query builder in inventory/user.go, as documented in GHSA-8r7f-r8hj-r3rv.

Workarounds

Restrict access to /api/v4/user/search at the reverse proxy layer to administrative roles until the upgrade is applied.
Apply rate limiting on the search endpoint to slow enumeration attempts.
Disable public registration and require administrator approval for new accounts to reduce the pool of low-privilege attackers.

bash

# Example nginx rule to restrict the search endpoint pending upgrade
location /api/v4/user/search {
    limit_req zone=user_search burst=5 nodelay;
    allow 10.0.0.0/8;   # trusted admin network
    deny all;
    proxy_pass http://cloudreve_backend;
}