CVE-2026-25726: Cloudreve Privilege Escalation Vulnerability

CVE-2026-25726 Overview

CVE-2026-25726 is an insecure random number generation vulnerability in Cloudreve, a self-hosted file management and sharing system. Prior to version 4.13.0, the application uses the weak pseudo-random number generator math/rand seeded with time.Now().UnixNano() to generate critical security secrets, including the secret_key and hash_id_salt. These secrets are generated upon first startup and persisted in the database.

An attacker can exploit this weakness by obtaining the administrator's account creation time via public API endpoints to narrow the search window for the PRNG seed, then use known hashid values to validate the seed. By brute-forcing the seed (demonstrated to take less than 3 hours on a general consumer PC), an attacker can predict the secret_key. This allows them to forge valid JSON Web Tokens (JWTs) for any user, including administrators, leading to full account takeover and privilege escalation.

Critical Impact

Successful exploitation allows attackers to forge valid JWTs for any user including administrators, resulting in complete account takeover and privilege escalation across the entire Cloudreve instance.

Affected Products

• Cloudreve versions prior to 4.13.0
• Self-hosted Cloudreve file management deployments using default secret generation
• Instances where administrator account creation timestamps are publicly accessible

Discovery Timeline

• 2026-04-03 - CVE-2026-25726 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-25726

Vulnerability Analysis

This vulnerability falls under CWE-338 (Use of Cryptographically Weak Pseudo-Random Number Generator). The core issue lies in Cloudreve's use of Go's math/rand package for generating security-critical secrets. The math/rand package is designed for speed and statistical randomness, not cryptographic security, making it unsuitable for generating secrets that protect authentication tokens.

When Cloudreve initializes for the first time, it generates two critical values: the secret_key used for signing JWTs and the hash_id_salt used for obfuscating database identifiers. Both are derived from the same weak PRNG seeded with the current Unix nanosecond timestamp. Since the seed space is limited to the time window around server initialization, and the administrator account creation time can be inferred through public API endpoints, an attacker can significantly reduce the computational effort required to recover the seed.

Root Cause

The root cause is the improper use of math/rand seeded with time.Now().UnixNano() for cryptographic secret generation. In Go, the math/rand package produces deterministic output given the same seed, and nanosecond-precision timestamps provide insufficient entropy for security-critical applications. The proper approach would be to use crypto/rand, which provides cryptographically secure random bytes suitable for secret key generation.

Attack Vector

The attack leverages network-accessible API endpoints to gather timing information that constrains the PRNG seed search space. The attack proceeds as follows:

1. Information Gathering: The attacker queries public API endpoints to obtain the administrator's account creation timestamp, which closely correlates with the server's initial startup time when secrets were generated.

2. Seed Space Reduction: Using the account creation timestamp, the attacker narrows down the possible seed values to a window of nanoseconds around the estimated server startup time.

3. Brute Force Attack: The attacker iterates through possible seed values, generating candidate secret_key and hash_id_salt values for each seed. Known hashid values from observable system behavior can be used to validate when the correct seed is found.

4. JWT Forgery: Once the correct secret_key is recovered, the attacker can forge valid JWTs for any user account, including administrator accounts, bypassing all authentication controls.

The attack is practical on consumer hardware with the demonstrated timeframe of less than 3 hours, making it accessible to unsophisticated attackers.

Detection Methods for CVE-2026-25726

Indicators of Compromise

• Unusual JWT tokens appearing in logs that were not generated through normal authentication flows
• Multiple API requests probing for user account metadata or timestamps from single IP addresses
• Authentication logs showing administrator access from unexpected locations or IP addresses
• Rapid enumeration of user-related API endpoints from external sources

Detection Strategies

• Monitor for unusual patterns of API calls to endpoints that expose user metadata or timestamps
• Implement anomaly detection for JWT usage patterns that deviate from normal user behavior
• Deploy web application firewalls with rules to detect enumeration attacks against user endpoints
• Correlate authentication events with known administrator access patterns to identify anomalies

Monitoring Recommendations

• Enable comprehensive logging for all authentication-related API endpoints
• Implement alerting for failed or unusual JWT validation attempts
• Monitor for bulk requests to public API endpoints that return user timing information
• Review access logs regularly for signs of reconnaissance activity targeting account metadata

How to Mitigate CVE-2026-25726

Immediate Actions Required

• Upgrade Cloudreve to version 4.13.0 or later immediately
• After upgrading, regenerate all security secrets including secret_key and hash_id_salt
• Force re-authentication of all active sessions after secret rotation
• Review access logs for any signs of exploitation prior to patching

Patch Information

The vulnerability has been patched in Cloudreve version 4.13.0. The patch replaces the insecure math/rand implementation with a cryptographically secure random number generator for secret generation. For detailed information about the patch, refer to the GitHub Release 4.13.0 and the GitHub Security Advisory GHSA-f8xp-wvcx-p6f4.

Workarounds

• If immediate upgrade is not possible, manually regenerate secrets using a cryptographically secure method and update database entries
• Restrict public access to API endpoints that expose user account creation timestamps
• Implement additional network-level access controls to limit exposure of the Cloudreve instance
• Consider placing the application behind a VPN or other access gateway to reduce attack surface

# Configuration example
# After upgrading to 4.13.0, force secret regeneration by:
# 1. Backup your current database
# 2. Remove existing secret entries from the database
# 3. Restart Cloudreve to trigger secure secret generation

# Verify your Cloudreve version
cloudreve -version
# Expected output: 4.13.0 or higher

# If running in Docker, update to the patched image
docker pull cloudreve/cloudreve:4.13.0
docker stop cloudreve_container
docker rm cloudreve_container
docker run -d --name cloudreve_container cloudreve/cloudreve:4.13.0