GHSA-j3rh-8vwq-wh84 is a critical-severity (CVSS 9.8) CWE-338 vulnerability in generator-jhipster-kotlin. 2 public exploit references exist, so weaponization risk is real. O3 Security confirms whether GHSA-j3rh-8vwq-wh84 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
JHipster Kotlin using insecure source of randomness `RandomStringUtils` before v1.2.0
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
generator-jhipster-kotlinnpmDescription
JHipster Kotlin is using an insecure source of randomness to generate all of its random values. JHipster Kotlin relies upon apache commons lang3 RandomStringUtils.
From the documentation:
Caveat: Instances of Random, upon which the implementation of this class relies, are not cryptographically secure. - https://commons.apache.org/proper/commons-lang/javadocs/api-3.9/org/apache/commons/lang3/RandomStringUtils.html
Here are the examples of JHipster Kotlin's use of an insecure PRNG:
Proof Of Concepts Already Exist
There has been a POC of taking one RNG value generated RandomStringUtils and reversing it to generate all of the past/future RNG values public since March 3rd, 2018.
POC Repository: https://github.com/alex91ar/randomstringutils
Potential Impact Technical
All that is required is to get one password reset token from a JHipster Kotlin generated service and using the POC above, you can reverse what all future password reset tokens to be generated by this server. This allows an attacker to pick and choose what account they would like to takeover by sending account password reset requests for targeted accounts.
Potential Impact Scale
Not as large as for the original jhipster project as the kotlin blueprint is not that widely used.
Patches
Update your generated applications to > 1.2.0
Workarounds
Change the content of RandomUtil.kt like this:
import java.security.SecureRandom
import org.apache.commons.lang3.RandomStringUtils
private const val DEF_COUNT = 20
object RandomUtil {
private val secureRandom: SecureRandom = SecureRandom()
init {
secureRandom.nextBytes(byteArrayOf(64.toByte()))
}
private fun generateRandomAlphanumericString(): String {
return RandomStringUtils.random(DEF_COUNT, 0, 0, true, true, null, secureRandom)
}
/**
* Generate a password.
*
* @return the generated password.
*/
fun generatePassword(): String = generateRandomAlphanumericString()
}
Important is to exchange every call of RandomStringUtils.randomAlphaNumeric.
For more information
If you have any questions or comments about this advisory:
- Open an issue in JHipster Kotlin
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | generator-jhipster-kotlin | all versions | 1.2.0 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for generator-jhipster-kotlin. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update generator-jhipster-kotlin to 1.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j3rh-8vwq-wh84 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-j3rh-8vwq-wh84 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j3rh-8vwq-wh84. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j3rh-8vwq-wh84 in your dependencies?
O3 detects GHSA-j3rh-8vwq-wh84 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.