In the OpenSSL compatibility layer implementation, the function RANDpoll() was not behaving as expected and leading to the potential for predictable values returned from RANDbytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RANDbytes() and doing fork() operations. This only affects applications explicitly calling RANDbytes() after fork() and does not affect any internal TLS operations. Although RANDbytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RANDpoll(), an additional code change was also made in wolfSSL to make RANDbytes() behave similar to OpenSSL after a fork() call without calling RANDpoll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RANDbytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report.

Heap buffer overread in wcPKCS7DecodeEnvelopedData when parsing crafted PKCS7 EnvelopedData. This could theoretically be triggered by attacker-supplied data delivered via S/MIME or CMS.

Use-after-free in PQC hybrid key-share handling. This is an incomplete-fix follow-up to CVE-2026-5460 (released in 5.9.1): a malicious TLS 1.3 server sending a truncated PQC hybrid KeyShare can still trigger the error cleanup path to operate on freed memory.