CVE-2025-7394
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceIn wolfSSL's OpenSSL compatibility layer, RAND_poll() was not properly reseeding the random number generator after fork(), causing RAND_bytes() to return predictable values in child processes. This affects applications explicitly using RAND_bytes() after fork() but does not impact internal TLS operations.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data>= 3.15.0, <= 5.8.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify installed wolfSSL versionRun 'wolfssl version' or check the library file (libwolfssl.so or wolfssl.lib) metadata. If using a package manager, query the installed package version.Affected if The installed version is >= 3.15.0 and <= 5.8.0
-
Confirm OpenSSL compatibility layer is in useCheck if the application links against wolfSSL's OpenSSL compatibility headers (openssl/*.h) or if the library was compiled with OpenSSL compatibility enabled (look for --enable-opensslext or similar build flags).Affected if OpenSSL compatibility headers or the OpenSSL extension is enabled in the build
-
Identify fork() usage in the applicationReview application source code for calls to fork() or fork-related functions (vfork, posix_spawn), and trace whether RAND_bytes() or RAND_poll() is called in the child process after forking.Affected if The application calls RAND_bytes() in a child process after fork()
-
Verify RAND_poll is invoked post-forkCheck if the application explicitly calls RAND_poll() or if OpenSSL's RAND_poll() is triggered (e.g., via RAND_bytes() auto-seeding) after fork() in the child process.Affected if RAND_poll() is called after fork() in the child process
You are affected if wolfSSL version is between 3.15.0 and 5.8.0, the OpenSSL compatibility layer is enabled, and your application calls RAND_bytes() or triggers RAND_poll() in a child process after fork().
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpdate to the latest version of wolfSSL which automatically reseeds the Hash-DRBG after detecting execution in a new process following fork().
Latest stable wolfSSL release (version > 5.8.0)
- 1. Identify the current wolfSSL version in use by checking your application's dependency or running `wolfssl version` if the CLI is installed
- 2. Download the latest stable wolfSSL release from the official GitHub releases page (github.com/wolfSSL/wolfssl/releases)
- 3. Review the release notes for the latest version to confirm the RAND_poll() and fork() related fix is included
- 4. Upgrade wolfSSL to the latest stable release following your platform's standard upgrade procedure (e.g., recompile from source with `./configure && make && make install`, or update via package manager)
- 5. Rebuild and redeploy any applications that link against wolfSSL
- 6. Test that RAND_bytes() functions correctly after fork() operations in your application
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation2.0 h
- Testing6.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,552.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2025-7394 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2025-7394 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data