CVE-2026-25726 affects Cloudreve before 4.13.0. The self-hosted file manager created its secret_key and hash_id_salt with a weak random number generator seeded by the clock, so an attacker may predict them and forge login tokens. NVD scores it 8.1. Upgrade to 4.13.0.
What's affected
- Product: Cloudreve, a self-hosted file management and sharing system.
- Affected: versions before 4.13.0, and per the advisory instances first set up on versions before 4.10.0.
- Fixed: 4.13.0, which adds a migration that replaces the old secret_key with a securely generated one.
- Warning from the advisory: servers running 4.10.0 or later can still be vulnerable if they were first installed on an older version.
How to check if you're exposed
The version alone is not enough, because the weak secret persists across upgrades. Find the version in the admin dashboard and the date the instance was first initialised.
If your install predates 4.10.0, or you cannot tell, assume the secret is weak until you are on 4.13.0 and the migration has run.
What to do now
- Upgrade to Cloudreve 4.13.0 or later so the secret_key is regenerated.
- After the upgrade, expect existing sessions and tokens to be invalidated, and tell your users.
- If you cannot upgrade immediately, read the workarounds in the advisory.
- Review admin accounts, shared links and recent logins for anything you do not recognise.
- Restrict public access to the admin endpoints where possible.
Why it matters
The class is CWE-338, a cryptographically weak pseudo random number generator. Go's math/rand seeded from the time is guessable. Knowing roughly when the admin account was made, which public API endpoints can reveal, narrows the search, and a known hash id lets the attacker confirm the right guess. The advisory says a search took under three hours on a consumer PC.
Once the secret_key is known, the attacker can sign valid JWTs for any user including administrators. That is full account takeover. The bug is a good reminder that secrets need crypto/rand or an equivalent, and that fixing the generator must also rotate secrets already issued. The record does not mark it as exploited in the wild.
How to prioritise the fix
The unusual part of this advisory is that an upgrade alone is not the whole story for older installs, so begin by working out when each instance was first initialised. The secrets were created at that first start and stored in the database.
Plan the upgrade with users in mind. Rotating the secret key invalidates tokens signed with the old one, so expect people to log in again, and announce it. After the change, review administrator accounts and shared links, since an attacker who forged tokens earlier would not need the key again if they created persistent access.
If your instance is publicly reachable, treat it as the most urgent item here. Public API endpoints that reveal the admin account creation time are what narrow the search, according to the advisory.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is upgrading enough if my instance is old?
Version 4.13.0 includes a migration that invalidates the old key and creates a new one, so upgrading is the fix. Check that the migration ran.
Will users be logged out?
Rotating the secret invalidates tokens signed with the old one, so expect re-login.
Sources
Last reviewed: 19 October 2026.
