CVE-2026-55496

CVE-2026-55496 is a medium-severity security vulnerability in github.com/cloudreve/Cloudreve/v4 (go), affecting versions < 4.0.0-20260613023921-7e1289d55279. It is fixed in 4.0.0-20260613023921-7e1289d55279.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Cloudreve: Information Exposure in GET /api/v4/user/search: SearchActive omits the active-status predicate, leaking inactive/banned account emails

GET /api/v4/user/search is available to any logged-in user. 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.

A normal logged-in user can therefore enumerate and retrieve the email (plus nickname, avatar, creation time, redacted group, profile share-visibility) of inactive and banned accounts that an active-user directory is supposed to suppress. No global status interceptor compensates, the only User query interceptor is soft-delete, and inactive/banned rows are not soft-deleted.

Details

Root cause (verified at 26b6b10)

1. Route, logged-in + UserInfo.Read scope (routers/router.go):

user := v4.Group("user")            // protected user group (login required)
user.GET("search",
    middleware.RequiredScopes(types.ScopeUserInfoRead),
    controllers.FromQuery[usersvc.SearchUserService](...), controllers.UserSearch)

The RequiredScopes check applies to scoped OAuth tokens; plain session requests are not gated by it, so any logged-in user reaches the search.

2. Service, 2-char keyword to SearchActive (service/user/info.go):

type SearchUserService struct { Keyword string `form:"keyword" binding:"required,min=2"` }
const resultLimit = 10
func (s *SearchUserService) Search(c *gin.Context) ([]*ent.User, error) {
    return dep.UserClient().SearchActive(c, resultLimit, s.Keyword)
}

3. The bug, SearchActive has no status predicate (inventory/user.go):

func (c *userClient) SearchActive(ctx context.Context, limit int, keyword string) ([]*ent.User, error) {
    ctx = context.WithValue(ctx, LoadUserGroup{}, true)
    return withUserEagerLoading(ctx,
        c.client.User.Query().
            Where(user.Or(user.EmailContainsFold(keyword), user.NickContainsFold(keyword))).
            Limit(limit),                       // <-- no user.StatusEQ(user.StatusActive)
    ).All(ctx)
}

Contrast the siblings immediately above:

func (c *userClient) GetActiveByID(...)        { ... Where(user.ID(id)).Where(user.StatusEQ(user.StatusActive)) ... }
func (c *userClient) GetActiveByDavAccount(...) { ... Where(user.EmailEqualFold(email)).Where(user.StatusEQ(user.StatusActive)) ... }

withUserEagerLoading only eager-loads the group/passkey edges; it adds no status filter. Status values are active/inactive/manual_banned/sys_banned (ent/user/user.go).

4. No global status interceptor, User.Mixin() is CommonMixin{} (ent/schema/user.go), whose Interceptors() returns only softDeleteInterceptors (ent/schema/common.go). Inactive/banned users are not soft-deleted, so nothing filters them out at query time.

5. Results serialized with email (routers/controllers/user.goservice/user/response.go):

// UserSearch:
return user.BuildUserRedacted(item, user.RedactLevelUser, hasher)
// BuildUserRedacted:
if level == RedactLevelUser { user.Email = userRaw.Email }   // email included

Secondary path: GET /api/v4/user/info/:idGetUser uses GetByID (no status filter), and the controller picks RedactLevelUser for any non-anonymous caller (RedactLevelAnonymous only for anonymous). So a logged-in caller with an inactive/banned user's hashed ID also receives the email-bearing profile. (Less practical than search, since it needs the hashed ID rather than a 2-char keyword.)

Steps to reproduce (requires a live instance)

  1. Ensure a target account exists in inactive or manual_banned/sys_banned status (e.g., an unconfirmed registration or a banned user).
  2. As any logged-in user:
    GET /api/v4/user/search?keyword=<>=2 chars of the target email/nick>
    Cookie: cloudreve-session=<attacker-session>
    
  3. Observe the inactive/banned account in the results, including its email.
    Expected: only active accounts appear (matching the method name and the sibling GetActive* behavior).
    Actual: inactive/banned accounts are returned with their email addresses.

Impact

Any logged-in user can enumerate and harvest the email addresses (and basic profile metadata) of inactive and banned accounts that active-user lookups intentionally hide. No account access, passwords, or 2FA secrets are exposed; the impact is PII leakage and user enumeration.

CVE-2026-55496 has a CVSS score of 4.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.0-20260613023921-7e1289d55279); upgrading removes the vulnerable code path.

Affected versions

github.com/cloudreve/Cloudreve/v4 (< 4.0.0-20260613023921-7e1289d55279) github.com/cloudreve/Cloudreve/v3 (<= 3.0.0-20250225100611-da4e44b77af4)

Security releases

github.com/cloudreve/Cloudreve/v4 → 4.0.0-20260613023921-7e1289d55279 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

  • Add Where(user.StatusEQ(user.StatusActive)) to SearchActive (matching GetActiveByID).
  • Apply the same active-status requirement to GET /api/v4/user/info/:id, or fall back to anonymous-level redaction unless the target account is active.
  • Consider not returning email from directory search at all, display name + hashed ID is usually sufficient.
  • Regression tests: searching a keyword that matches an inactive/banned account must return no result (or no email).

Frequently Asked Questions

  1. What is CVE-2026-55496? CVE-2026-55496 is a medium-severity security vulnerability in github.com/cloudreve/Cloudreve/v4 (go), affecting versions < 4.0.0-20260613023921-7e1289d55279. It is fixed in 4.0.0-20260613023921-7e1289d55279.
  2. How severe is CVE-2026-55496? CVE-2026-55496 has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by CVE-2026-55496?
    • github.com/cloudreve/Cloudreve/v4 (go) (versions < 4.0.0-20260613023921-7e1289d55279)
    • github.com/cloudreve/Cloudreve/v3 (go) (versions <= 3.0.0-20250225100611-da4e44b77af4)
  4. Is there a fix for CVE-2026-55496? Yes. CVE-2026-55496 is fixed in 4.0.0-20260613023921-7e1289d55279. Upgrade to this version or later.
  5. Is CVE-2026-55496 exploitable, and should I be worried? Whether CVE-2026-55496 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-55496 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-55496? Upgrade github.com/cloudreve/Cloudreve/v4 to 4.0.0-20260613023921-7e1289d55279 or later.

Other vulnerabilities in github.com/cloudreve/Cloudreve/v4

Stop the waste.
Protect your environment with Kodem.