Sakai LMS CVE-2025-62710

Exploitation requires two concrete prerequisites that significantly limit practicality: (1) the attacker must already possess ciphertext produced by EncryptionUtilityServiceImpl - specifically exported strings or at-rest values encrypted with the AES256TextEncryptor serverSecretKey - not merely network reachability of Sakai; and (2) the attacker must be able to approximate the java.util.Random seed, feasible because the PRNG is seeded from predictable state such as the server start-time window. The weakness is present by default in affected versions (no special configuration enables it), but the need for prior ciphertext access plus successful seed estimation is what drives the high attack complexity and keeps real-world risk below the raw network-vector reading. Confidentiality of previously-encrypted data remains at risk even after patching unless keys are rotated and old ciphertext is re-encrypted.

This is a genuine but comparatively low-urgency cryptographic weakness rather than a widely-exploitable critical flaw. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, 5.9 Medium) correctly signals the limiting factor: AC:H reflects that exploitation is not trivial - the attacker must both obtain ciphertext and successfully approximate the java.util.Random seed (e.g. the server start-time window) to reconstruct the AES256 serverSecretKey. Impact is confined to confidentiality (C:H, I:N, A:N). The multi-source signals are consistent and point to low real-world urgency: EPSS is 0.20% (9th percentile), the CVE is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis. The PR:N rating is technically defensible for the cryptographic flaw itself, but note a tension: the description states the attacker must first 'obtain ciphertexts (e.g., exported or at-rest strings)', which in practice presupposes some prior access to exported data or the datastore - a prerequisite not captured by the PR:N/AV:N vector alone and worth weighing when prioritizing. Overall: a real defense-in-depth issue meriting routine patching, not emergency response, absent evidence of active exploitation.

An attacker who has already obtained Sakai-encrypted data (for example an exported file or at-rest strings protected by EncryptionUtilityServiceImpl) estimates the server's startup time window to constrain the java.util.Random seed, then brute-forces the drastically reduced key space to reconstruct the serverSecretKey and decrypt the protected data offline. No public proof-of-concept is referenced, and the high attack complexity (seed approximation plus ciphertext access) makes this a targeted rather than opportunistic attack.