CVE-2025-62710 Overview
CVE-2025-62710 affects Sakai, an open-source Collaboration and Learning Environment maintained by the Sakai Project. The vulnerability resides in EncryptionUtilityServiceImpl, which initialized the AES256TextEncryptor password (serverSecretKey) using RandomStringUtils backed by the default java.util.Random. Because java.util.Random is a non-cryptographic pseudo-random number generator (PRNG), attackers who know or approximate the seed can predict generated values. This weakness reduces the effective search space of the encryption key. The issue is tracked as SAK-49866 and is fixed in Sakai 23.5 and 25.0. The vulnerability maps to [CWE-337: Predictable Seed in Pseudo-Random Number Generator].
Critical Impact
An attacker with access to ciphertexts protected by the affected service and knowledge of the server start-time window can reconstruct the serverSecretKey and decrypt sensitive data at rest.
Affected Products
- Sakai versions prior to 23.5
- Sakai versions prior to 25.0
- Sakai trunk builds prior to the SAK-49866 patch
Discovery Timeline
- 2025-10-22 - CVE-2025-62710 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-62710
Vulnerability Analysis
The flaw arises in the EncryptionUtilityServiceImpl class within the Sakai kernel. During initialization, the service constructs the AES256 encryption password using Apache Commons Lang RandomStringUtils, which historically delegates to java.util.Random. This PRNG is deterministic and its 48-bit internal state can be recovered from a small number of observed outputs or narrowed by seeding heuristics such as system start time. Once the state is recovered, an attacker can regenerate the exact serverSecretKey produced at Sakai startup. Any string encrypted by the service, including exported artifacts and persisted at-rest values, can then be decrypted offline.
Root Cause
The root cause is the use of a non-cryptographic PRNG to derive cryptographic material. java.util.Random is not suitable for security-sensitive key generation, yet RandomStringUtils.random(...) used it by default. Cryptographic key generation must use java.security.SecureRandom or an equivalent CSPRNG so that keys cannot be predicted from seed or state inference.
Attack Vector
The attack requires network-adjacent access to ciphertexts produced by an affected Sakai instance and the ability to approximate the PRNG seed window (for example, by observing the server start time or process metadata). No authentication or user interaction is required. Given ciphertext and a candidate seed range, the attacker iterates seeds, regenerates candidate keys, and attempts decryption until known plaintext structure is recovered. Success yields plaintext confidentiality loss for all data encrypted with that server's key.
// Patch: EncryptionUtilityServiceImpl.java (SAK-49866)
import lombok.extern.slf4j.Slf4j;
+import java.security.SecureRandom;
+
import org.apache.commons.lang3.RandomStringUtils;
import org.jasypt.util.text.AES256TextEncryptor;
import org.sakaiproject.util.api.EncryptionUtilityService;
Source: Sakai commit bde0701. The fix introduces SecureRandom and switches key material generation to commons-text's RandomStringGenerator seeded from a CSPRNG.
Detection Methods for CVE-2025-62710
Indicators of Compromise
- Unexpected access to Sakai database tables or exports containing Jasypt-encrypted (AES256TextEncryptor) strings.
- Off-hours enumeration of Sakai server metadata that could reveal process start time (for example, JMX, /proc, or admin console access).
- Unauthorized decryption or reuse of previously exported encrypted configuration or user data.
Detection Strategies
- Inventory Sakai deployments and confirm the running version; flag any instance below 23.5 or 25.0.
- Search source and deployed JARs for EncryptionUtilityServiceImpl referencing RandomStringUtils without SecureRandom.
- Review audit logs for exports of encrypted attributes and correlate with external access to backup or object storage locations.
Monitoring Recommendations
- Alert on read access to Sakai backup files, database dumps, or configuration exports containing encrypted fields.
- Monitor administrative endpoints that expose JVM start time or process uptime, which could aid seed prediction.
- Track outbound transfers of Sakai data archives to unrecognized destinations.
How to Mitigate CVE-2025-62710
Immediate Actions Required
- Upgrade Sakai to version 23.5, 25.0, or a trunk build containing the SAK-49866 fix.
- After upgrading, rotate the serverSecretKey and re-encrypt any data protected by the previous key.
- Treat existing ciphertexts and backups as potentially compromised and restrict their exposure until re-encryption completes.
Patch Information
The fix is delivered in commit bde070104b1de01f4a6458dca6d9e0880a0e3c04, which replaces the insecure PRNG usage with SecureRandom and commons-text based generation. See the Sakai GHSA-gr7h-xw4f-wh86 advisory and the upstream commit for implementation details.
Workarounds
- Restrict filesystem, database, and backup access so that ciphertexts protected by EncryptionUtilityServiceImpl cannot be exfiltrated.
- Limit exposure of server metadata that reveals JVM start time or uptime to reduce seed-prediction feasibility.
- If upgrading is not immediately possible, isolate the Sakai host and rotate any secrets, tokens, or credentials that may have been encrypted with the weak key.
# Verify Sakai version and confirm patched build
grep -r "version" $CATALINA_HOME/webapps/sakai-*/META-INF/MANIFEST.MF | head
# After upgrade, rotate the server secret key and re-encrypt affected data
# (perform in a maintenance window; back up first)
export SAKAI_HOME=/opt/sakai
cp $SAKAI_HOME/sakai.properties $SAKAI_HOME/sakai.properties.bak
# Update serverSecretKey in sakai.properties with a new CSPRNG-generated value
openssl rand -base64 48
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

