Stunnel 5.00 through 5.13, when using the redirect option, does not redirect client connections to the expected server after the initial connection, which allows remote attackers to bypass authentication.

A flaw was found in the way stunnel, a socket wrapper which can provide SSL support to ordinary applications, performed (re)initialization of PRNG after fork. When accepting a new connection, the server forks and the child process handles the request. The RANDbytes() function of openssl doesn't reset its state after the fork, but seeds the PRNG with the output of time(NULL). The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key.

stunnel 4.21 through 4.54, when CONNECT protocol negotiation and NTLM authentication are enabled, does not correctly perform integer conversion, which allows remote proxy servers to execute arbitrary code via a crafted request that triggers a buffer overflow.

stunnel 4.40 and 4.41 might allow remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via unspecified vectors.

The OCSP functionality in stunnel before 4.24 does not properly search certificate revocation lists (CRL), which allows remote attackers to bypass intended access restrictions by using revoked certificates.

Unspecified vulnerability in stunnel before 4.23, when running as a service on Windows, allows local users to gain privileges via unknown attack vectors.