CVE-2025-7394 json
In the OpenSSL compatibility layer implementation, the function `RAND_poll()` was not behaving as...
published last yr. modified 3mo ago also EUVD-2025-21938 , GHSA-jgh6-fqf6-cpj8 , JLSEC-2026-689
- cvss
- 9.8
- version 3.1, NVD
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.5%
- EPSS 0.5% chance of exploitation in 30 days, percentile 40%
- public exploits
- 0
- none known
Summary
In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report.
Patch / fix
- julia wolfSSL_jll 5.8.4+0
- wolfssl wolfssl 5.8.2
- wolfssl Debian 12 5.5.4-2+deb12u2
- wolfssl Debian 13 5.7.2-0.1+deb13u1
debian advisories DEBIAN-CVE-2025-7394
Is CVE-2025-7394 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCISA SSVC
- Exploitation
- none
- Automatable
- no
- Technical impact
- partial
- Assessed
- last yr.
Exploit prediction
0.46% chance of exploitation in the next 30 days, higher than 40% of all scored CVEs (FIRST EPSS, 2026-11-09).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 4.0 | 7.0 | CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N |
| CNA | 4.0 | 7.0 | CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X |
| NVD | 3.1 | 9.8 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| OSV | 3.1 | 9.8 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| julia | wolfSSL_jll | <5.8.4+0 |
5.8.4+0 |
Affected products
- wolfSSL wolfSSL
Classification
References
Sources
- CVE List CVE-2025-7394
- NVD CVE-2025-7394
- OSV JLSEC-2026-689
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.
CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.