CVE-2026-25726: 
vulnerability analysis and mitigation

CVE-2026-25726 is a weak cryptographic token generation vulnerability in Cloudreve, an open-source self-hosted cloud storage platform, that allows unauthenticated remote attackers to forge valid JWTs and achieve full account takeover. The vulnerability affects all Cloudreve instances first deployed/initialized with versions prior to V4.10.0, including those subsequently upgraded up to v4.12.4, as the weak secrets persist in the database. It was discovered by researcher orenyomtov, published on March 31, 2026, and patched in version 4.13.0. The GitHub Advisory Database assigns a CVSS v3.1 score of 8.1 (High) with High attack complexity, while Feedly's assessment rates it 9.8 (Critical) (GitHub Advisory, Cloudreve Advisory).

The root cause is classified as CWE-338 (Use of Cryptographically Weak Pseudo-Random Number Generator). Cloudreve uses Go's math/rand package seeded with time.Now().UnixNano() to generate critical security secrets — specifically secret_key and hash_id_salt — during first startup, which are then persisted in the database. Because the seed is time-based, an attacker can query public API endpoints to obtain the administrator's account creation timestamp, dramatically narrowing the PRNG seed search space; the attacker then validates candidate seeds against a known hashid value before using the predicted secret_key to forge arbitrary JWTs. The vulnerable seeding code is located at pkg/util/common.go#L21-L23 and the usage at inventory/setting.go#L591 (GitHub Advisory, Cloudreve Advisory).

Successful exploitation allows an unauthenticated attacker to forge valid JWTs for any user account, including administrators, resulting in complete account takeover and privilege escalation. This grants full access to all files stored in the Cloudreve instance, administrative controls, and any data accessible through the platform. The confidentiality, integrity, and availability of the entire Cloudreve deployment are fully compromised, and the attacker could use administrative access to pivot to connected storage backends or internal infrastructure (GitHub Advisory, Cloudreve Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). However, the attack has been demonstrated to complete in under 3 hours on consumer-grade hardware, making it practically feasible for motivated attackers. The EPSS score is approximately 0.023% (7th percentile), and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities catalog. No specific threat actor attribution has been reported.

1. Reconnaissance: Identify internet-facing Cloudreve instances (e.g., via Shodan or Censys) running versions prior to 4.13.0 that were originally initialized before V4.10.0.
2. Obtain admin creation timestamp: Query publicly accessible Cloudreve API endpoints to retrieve the administrator account's creation time, which provides the approximate time window for the PRNG seed (time.Now().UnixNano() at first startup).
3. Retrieve a known hashid: Obtain a known hash_id_salt-derived hashid value from the application (e.g., from a public file share link or user ID encoding), which will be used to validate candidate seeds.
4. Brute-force the PRNG seed: Iterate over nanosecond timestamps within the narrowed time window, simulating Go's math/rand seeded with each candidate value, and check whether the resulting hash_id_salt produces the known hashid. This process takes under 3 hours on consumer hardware.
5. Derive the secret_key: Once the correct seed is identified, use the same PRNG sequence to reproduce the secret_key generated during Cloudreve's first startup.
6. Forge a JWT: Craft a valid JSON Web Token signed with the recovered secret_key, setting the user claims to an administrator account.
7. Achieve account takeover: Submit the forged JWT in API requests to authenticate as the administrator, gaining full control over the Cloudreve instance and all stored data (GitHub Advisory, Cloudreve Advisory).

• Network: Unusual or repeated requests to Cloudreve public API endpoints querying user/account creation metadata from unexpected IP addresses; high-volume automated requests to user info or profile endpoints suggesting enumeration.
• Logs: Cloudreve access logs showing successful authentication events from IP addresses with no prior login history, especially for administrator accounts; JWT-authenticated requests immediately following a period of API enumeration activity.
• Application Behavior: Unexpected administrative actions (configuration changes, new user creation, storage policy modifications) performed outside normal business hours or from unfamiliar IP addresses; sudden invalidation of all user sessions if an attacker rotates the secret_key after gaining access.
• File System: Unexpected changes to Cloudreve database configuration entries for secret_key or hash_id_salt if an attacker modifies them post-compromise.

Upgrade Cloudreve to version 4.13.0 immediately; this release automatically invalidates the existing weak secret_key and regenerates a cryptographically secure replacement using Go's crypto/rand (Cloudreve Release). Note that upgrading will invalidate all active login sessions and any signed temporary links. If an immediate upgrade is not possible, manually rotate the secret_key by stopping the Cloudreve service, locating the secret_key entry in the Cloudreve database, replacing it with a cryptographically random value (e.g., openssl rand -base64 64), and restarting the service — this will also log out all active users (GitHub Advisory). Administrators should audit all Cloudreve instances originally deployed before V4.10.0, even if they have since been upgraded, as the vulnerable secrets persist until explicitly rotated.

The vulnerability was published by Cloudreve maintainer HFO4 on March 31, 2026, with credit to researcher orenyomtov for discovery. The release notes for v4.13.0 explicitly flag the update as a critical security release and note that full technical details would be disclosed 60 days after the patch release, following responsible disclosure practices (Cloudreve Release). Red Hat also tracked the vulnerability via their CVE database, indicating broader ecosystem awareness (GitHub Advisory).