Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/cloudreve/Cloudreve/v4 >= 4.0.0-20260114075425-bc6845bd742c, < 4.0.0-20260606015557-ed20843dc3df
Fixed in
4.0.0-20260606015557-ed20843dc3df· Vendor fix available
Issue
Cloudreve's OAuth access tokens can bypass OAuth scope enforcement. This does not appear to be the intended design. The documentation describes OAuth client permissions/scopes, the API has an insufficient-scope error code, and the code comments say RequiredScopes(...) should verify scopes when a token has scopes, while skipping checks only for non-scoped session-based authentication. However, OAuth access tokens are issued without the OAuth clientid claim. Later, the JWT verifier only loads scopes into the request context when claims.ClientID != "". Because the OAuth access token has no clientid, its scopes are not loaded, and RequiredScopes(...) treats the request like a non-scoped first-party/session token and skips scope checks. As a result, a low-scope OAuth access token, for example one granted only openid, can call APIs requiring higher scopes such as file, share, workflow, user setting, WebDAV account, and potentially admin scopes when the authorizing user is an…
Recommended action: Upgrade to 4.0.0-20260606015557-ed20843dc3df (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/cloudreve/Cloudreve/v4 < 4.0.0-20260205113604-ec9fdd33bc54
Fixed in
4.0.0-20260205113604-ec9fdd33bc54· Vendor fix available
Issue
Impact This vulnerability affects Cloudreve instances that were first deployed/initialized with versions prior to V4.10.0. The application uses the weak pseudo-random number generator math/rand seeded with time.Now().UnixNano() to generate critical security secrets, including the secretkey, and hashidsalt. These secrets are generated upon first startup and persisted in the database. An attacker can exploit this by obtaining the administrator's account creation time (via public API endpoints) to narrow the search window for the PRNG seed, and use known hashid to validate the seed. By brute-forcing the seed (demonstrated to take <3 hours on general consumer PC), an attacker can predict the secretkey. This allows them to forge valid JSON Web Tokens (JWTs) for any user, including administrators, leading to full account takeover and privilege escalation. Note: Servers running V4.10.0+ are still vulnerable if they were originally installed using an older version, as the weak secrets…
Recommended action: Upgrade to 4.0.0-20260205113604-ec9fdd33bc54 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.