A flaw was found in stunnel before 5.57, where it improperly validates client certificates when it is configured to use both redirect and verifyChain options. This flaw allows an attacker with a certificate signed by a Certificate Authority, which is not the one accepted by the stunnel server, to access the tunneled service instead of being redirected to the address specified in the redirect option. The highest threat from this vulnerability is to confidentiality.

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.