CVE-2025-7394 is a critical (CVSS 9.8 in the record) flaw in wolfSSL's OpenSSL compatibility layer. After fork(), RAND_bytes() could return predictable values. wolfSSL fixed it in release 5.8.2, dated 17 July 2025, so update to that version or later. If you cannot yet, call RAND_poll() in the child process after every fork.
What's affected
The record says that in the OpenSSL compatibility layer, RAND_poll() did not behave as expected, which could lead to predictable values from RAND_bytes() after a fork(). This affects applications that call RAND_bytes() after forking. The record is explicit that it does not affect wolfSSL's internal TLS operations.
wolfSSL's release notes for 5.8.2 list the issue with a medium label ("Med. CVE-2025-7394"). The record scores it 9.8 and critical, using a network vector with no privileges and high impact on all three areas. The two sources disagree on severity. The vendor's reading limits the impact to code that uses the compatibility API in a particular way, while the base score assumes the worst case. Judge your own exposure by how your code uses the function.
The record gives no lower bound for the affected versions. The release notes place the fix in 5.8.2, so treat earlier releases that include the compatibility layer as in scope, and check the notes for details. The weaknesses are CWE-200 (exposure of sensitive information) and CWE-338 (weak pseudo-random number generator). The record's KEV flag is false and nothing I read says it is exploited.
The fix, per the notes: wolfSSL changed RAND_bytes() to behave like OpenSSL after a fork() even if RAND_poll() is not called. The Hash-DRBG now reseeds when it detects it is running in a new process. The notes recommend updating if you use RAND_bytes() and call fork().
How to check if you're exposed
Check the library version. If you built from source, the header has it:
grep LIBWOLFSSL_VERSION_STRING wolfssl/version.h
If wolfSSL is installed with its pkg-config file:
pkg-config --modversion wolfssl
Next, check your own code. You are exposed if all of these are true: you use the OpenSSL compatibility layer, you call RAND_bytes() after a fork(), and you do not call RAND_poll() in the child first. Search your sources:
grep -rn "RAND_bytes\|fork(" src/
Also check what your dependencies bundle. Many products ship wolfSSL inside a firmware image or a container, and the version there is the one that counts.
What to do now
- Inventory where wolfSSL is used, including bundled copies in products and images.
- Update to 5.8.2 or later and rebuild what links against it.
- In code that forks and then asks for random bytes, call
RAND_poll()in the child as a belt and braces step, as OpenSSL's own documentation advises. - Look at any secrets, tokens or keys generated by forked workers on affected builds, and consider regenerating the ones that matter.
- Track the vendor release notes for related fixes in the same release.
Why it matters
After fork(), parent and child processes share the same random generator state. If neither one reseeds, both produce the same stream, and values that should be unique, such as session tokens or keys, can repeat or be guessed. Pre-forking servers are the standard case.
OpenSSL's documentation already warned about this, and wolfSSL's compatibility layer was meant to behave the same way. The fix closes the gap by reseeding when a new process is detected. The scoring gap between 9.8 and a medium label shows why base scores alone are a poor guide: the real question is whether your code takes the path.
Try it yourself
See how a dependency inventory surfaces a library that is bundled deep inside a build.
Click through it at your own pace, or open it full screen.
Quick check
Does this break TLS in wolfSSL itself?
No. The record says it does not affect internal TLS operations. It affects applications that call RAND_bytes() after fork().
Why do the sources disagree on severity?
The record carries a base score of 9.8, which assumes the worst case. wolfSSL's own release notes label the issue medium, since it needs a specific usage pattern. Both are shown here so you can decide.
Sources
Last reviewed: 18 October 2026.
