GHSA-8R7F-R8HJ-R3RV

Vulnerability from github – Published: 2026-07-24 20:46 – Updated: 2026-07-24 20:46
VLAI
Summary
Cloudreve: Information Exposure in `GET /api/v4/user/search`: `SearchActive` omits the active-status predicate, leaking inactive/banned account emails
Details

Summary

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 interceptorUser.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.

Remediation

  • 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).
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudreve/Cloudreve/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.0-20260613023921-7e1289d55279"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudreve/Cloudreve/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.0.0-20250225100611-da4e44b77af4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55496"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-359"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T20:46:49Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n \n`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** \u2014 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.\n \nA 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 \u2014 the only User query interceptor is soft-delete, and inactive/banned rows are not soft-deleted.\n\n### Details\n## Root cause (verified at `26b6b10`)\n \n**1. Route \u2014 logged-in + `UserInfo.Read` scope** (`routers/router.go`):\n```go\nuser := v4.Group(\"user\")            // protected user group (login required)\nuser.GET(\"search\",\n    middleware.RequiredScopes(types.ScopeUserInfoRead),\n    controllers.FromQuery[usersvc.SearchUserService](...), controllers.UserSearch)\n```\nThe `RequiredScopes` check applies to scoped OAuth tokens; plain session requests are not gated by it \u2014 so any logged-in user reaches the search.\n \n**2. Service \u2014 2-char keyword to `SearchActive`** (`service/user/info.go`):\n```go\ntype SearchUserService struct { Keyword string `form:\"keyword\" binding:\"required,min=2\"` }\nconst resultLimit = 10\nfunc (s *SearchUserService) Search(c *gin.Context) ([]*ent.User, error) {\n    return dep.UserClient().SearchActive(c, resultLimit, s.Keyword)\n}\n```\n \n**3. The bug \u2014 `SearchActive` has no status predicate** (`inventory/user.go`):\n```go\nfunc (c *userClient) SearchActive(ctx context.Context, limit int, keyword string) ([]*ent.User, error) {\n    ctx = context.WithValue(ctx, LoadUserGroup{}, true)\n    return withUserEagerLoading(ctx,\n        c.client.User.Query().\n            Where(user.Or(user.EmailContainsFold(keyword), user.NickContainsFold(keyword))).\n            Limit(limit),                       // \u003c-- no user.StatusEQ(user.StatusActive)\n    ).All(ctx)\n}\n```\nContrast the siblings immediately above:\n```go\nfunc (c *userClient) GetActiveByID(...)        { ... Where(user.ID(id)).Where(user.StatusEQ(user.StatusActive)) ... }\nfunc (c *userClient) GetActiveByDavAccount(...) { ... Where(user.EmailEqualFold(email)).Where(user.StatusEQ(user.StatusActive)) ... }\n```\n`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`).\n \n**4. No global status interceptor** \u2014 `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.\n \n**5. Results serialized with email** (`routers/controllers/user.go` \u2192 `service/user/response.go`):\n```go\n// UserSearch:\nreturn user.BuildUserRedacted(item, user.RedactLevelUser, hasher)\n// BuildUserRedacted:\nif level == RedactLevelUser { user.Email = userRaw.Email }   // email included\n```\n \n**Secondary path:** `GET /api/v4/user/info/:id` \u2192 `GetUser` 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\u0027s hashed ID also receives the email-bearing profile. (Less practical than search, since it needs the hashed ID rather than a 2-char keyword.)\n\n## Steps to reproduce (requires a live instance)\n \n1. Ensure a target account exists in `inactive` or `manual_banned`/`sys_banned` status (e.g., an unconfirmed registration or a banned user).\n2. As any logged-in user:\n   ```\n   GET /api/v4/user/search?keyword=\u003c\u003e=2 chars of the target email/nick\u003e\n   Cookie: cloudreve-session=\u003cattacker-session\u003e\n   ```\n3. Observe the inactive/banned account in the results, including its `email`.\n**Expected:** only active accounts appear (matching the method name and the sibling `GetActive*` behavior).\n**Actual:** inactive/banned accounts are returned with their email addresses.\n \n## Impact\n \nAny 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.\n \n## Remediation\n \n- Add `Where(user.StatusEQ(user.StatusActive))` to `SearchActive` (matching `GetActiveByID`).\n- 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.\n- Consider not returning email from directory search at all \u2014 display name + hashed ID is usually sufficient.\n- Regression tests: searching a keyword that matches an inactive/banned account must return no result (or no email).",
  "id": "GHSA-8r7f-r8hj-r3rv",
  "modified": "2026-07-24T20:46:49Z",
  "published": "2026-07-24T20:46:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-8r7f-r8hj-r3rv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudreve/cloudreve/commit/7e1289d552794bdbeb551be78456115c87dcb3da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudreve/cloudreve"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudreve/cloudreve/releases/tag/4.17.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cloudreve: Information Exposure in `GET /api/v4/user/search`: `SearchActive` omits the active-status predicate, leaking inactive/banned account emails"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…