WOLFSSL SECURITY VULNERABILITIES
This page lists known vulnerabilities for the wolfSSL embedded SSL/TLS library, wolfCrypt embedded crypto engine, and other wolfSSL products. Each vulnerability is linked to the description and CVE if available. Please contact us with any questions or concerns.
Known wolfSSL Vulnerabilities
The SSL/TLS protocol is documented and under constant scrutiny by the top experts in security and cryptography. SSL was quickly adopted as a standard world wide. SSL and TLS together secure communications between billions of computers, servers, Internet of Things (IoT) devices, and embedded systems. The security provided by an SSL/TLS Library depends on the underlying strength of its cryptography which is used to encrypt communications.
| INFO | CVE ID | SEVERITY | DESCRIPTION | TIME TO FIX | FIXED IN VERSION |
|---|---|---|---|---|---|
| LINK | N/A | Low | When the OpenSSL compatibility layer is enabled, certificate verification behaved differently in wolfSSL than OpenSSL, in the X509_STORE_add_cert() and X509_STORE_load_locations() implementations. Previously, in cases where an application explicitly loaded an intermediate certificate, wolfSSL was verifying only up to that intermediate certificate, rather than verifying up to the root CA. This only affects use cases where the API is called directly, and does not affect TLS connections. Users that call the API X509_STORE_add_cert() or X509_STORE_load_locations() directly in their applications are recommended to update the version of wolfSSL used or to have additional sanity checks on certificates loaded into the X509_STORE when verifying a certificate. Fixed in GitHub PR #8087. | TBD | 5.7.4 |
| LINK | CVE-2024-5288 | Medium | A private key blinding operation, enabled by defining the macro WOLFSSL_BLIND_PRIVATE_KEY, was added to mitigate a potential row hammer attack on ECC operations. If performing ECC private key operations in an environment where a malicious user could gain fine control over the device and perform row hammer style attacks it is recommended to update the version of wolfSSL used and to build with WOLFSSL_BLIND_PRIVATE_KEY defined. Thanks to Kemal Derya, M. Caner Tol, Berk Sunar for the report (Vernam Applied Cryptography and Cybersecurity Lab at Worcester Polytechnic Institute) Fixed in github pull request #7416 | 8 days | 5.7.2 |
| LINK | N/A | Low | When parsing a provided maliciously crafted certificate directly using wolfSSL API, outside of a TLS connection, a certificate with an excessively large number of extensions could lead to a potential DoS. There are existing sanity checks during a TLS handshake with wolfSSL which mitigate this issue. Thanks to Bing Shi for the report. Fixed in github pull request #7597 | 5 days | 5.7.2 |
| LINK | CVE-2024-5991 | Low | In the function MatchDomainName(), input param str is treated as a NULL terminated string despite being user provided and unchecked. Specifically, the Openssl compatibility function X509_check_host() takes in a pointer and length to check against, with no requirements that it be NULL terminated. While calling without a NULL terminated string is very uncommon, it is still technically allowed. If a caller was attempting to do a name check on a non*NULL terminated buffer, the code would read beyond the bounds of the input array until it found a NULL terminator. Fixed in github pull request #7604 | 17 days | 5.7.2 |
| LINK | CVE-2024-5814 | Medium | A malicious TLS1.2 server can force a TLS1.3 client with downgrade capability to use a ciphersuite that it did not agree to and achieve a successful connection. This is because, aside from the extensions, the client was skipping fully parsing the server hello when downgrading from TLS 1.3. Fixed in github pull request #7619 | 5 days | 5.7.2 |
| LINK | N/A | Medium | OCSP stapling version 2 response verification bypass issue when a crafted response of length 0 is received. Found with internal testing. Fixed in github pull request #7702 | 12 days | 5.7.2 |
| LINK | N/A | Medium | OCSP stapling version 2 revocation bypass with a retry of a TLS connection attempt. A revoked CA certificate could incorrectly be loaded into the trusted signers list and used in a repeat connection attempt. Found with internal testing. Fixed in github pull request #7702 | 5 days | 5.7.2 |
| LINK | CVE-2024-2881 | Medium | Fault injection attack with EdDSA signature operations. This affects ed25519 sign operations where the system could be susceptible to Rowhammer attacks. Thanks to Junkai Liang, Zhi Zhang, Xin Zhang, Qingni Shen for the report (Peking University, The University of Western Australia). Fixed in this GitHub pull request #7212 | 0 days | 5.7.0 |
| LINK | CVE-2024-1545 | Medium | Fault Injection vulnerability in RsaPrivateDecryption function that potentially allows an attacker that has access to the same system with a victims process to perform a Rowhammer fault injection. Thanks to Junkai Liang, Zhi Zhang, Xin Zhang, Qingni Shen for the report (Peking University, The University of Western Australia)." Fixed in this GitHub pull request #7167 | 9 days | 5.7.0 |
| LINK | CVE-2024-0901 | High | Potential denial of service and out of bounds read. Affects TLS 1.3 on the server side when accepting a connection from a malicious TLS 1.3 client. If using TLS 1.3 on the server side it is recommended to update the version of wolfSSL used. Fixed in this GitHub pull request #7099 | 5 days | 5.7.0 |
| LINK | CVE-2024-1544 | Medium | Potential ECDSA nonce side channel attack in versions of wolfSSL before 5.6.6 with wc_ecc_sign_hash calls. Generating the ECDSA nonce k samples a random number r and then truncates this randomness with a modular reduction mod n where n is the order of the elliptic curve. Analyzing the division through a control-flow revealing side-channel reveals a bias in the most significant bits of k. Depending on the curve this is either a negligible bias or a significant bias large enough to reconstruct k with lattice reduction methods. Thanks to Luca Wilke, Florian Sieck and Thomas Eisenbarth (University of Lübeck) for reporting the vulnerability. Details will appear in the proceedings of CCS 24. Fixed #7020 | 0 days | 5.6.6 |
| LINK | CVE-2023-6935 | Medium | After review of the previous RSA timing fix in wolfSSL 5.6.4, additional changes were found to be required. A complete resistant change is delivered in this release. This fix is for the Marvin attack, leading to being able to decrypt a saved TLS connection and potentially forge a signature after probing with a very large number of trial connections. This issue is around RSA decryption and affects the optional static RSA cipher suites on the server side, which are considered weak, not recommended to be used and are off by default in wolfSSL (even with –enable-all). Static RSA cipher suites were also removed from the TLS 1.3 protocol and are only present in TLS 1.2 and lower. All padding versions of RSA decrypt are affected since the code under review is outside of the padding processing. Information about the private keys is NOT compromised in affected code. It is recommended to disable static RSA cipher suites and update the version of wolfSSL used if using RSA private decryption alone outside of TLS. Thanks to Hubert Kario for the report. The fix for this issue is located in the following GitHub Pull Request: https://github.com/wolfSSL/wolfssl/pull/6955. | 8 days | 5.6.6 |
| LINK | CVE-2023-6936 | Low | A potential heap overflow read is possible in servers connecting over TLS 1.3 when the optional WOLFSSL_CALLBACKS has been defined. The out of bounds read can occur when a server receives a malicious malformed ClientHello. Users should either discontinue use of WOLFSSL_CALLBACKS on the server side or update versions of wolfSSL to 5.6.6. Thanks to the tlspuffin fuzzer team for the report which was designed and developed by; Lucca Hirschi (Inria, LORIA), Steve Kremer (Inria, LORIA), and Max Ammann (Trail of Bits). The fix for this issue is located in the following GitHub Pull Request: https://github.com/wolfSSL/wolfssl/pull/6949. | 8 days | 5.6.6 |
| LINK | CVE-2024-1543 | Low | A side channel vulnerability with AES T-Tables is possible in a very controlled environment where precision sub-cache-line inspection can happen, such as inside an Intel SGX enclave. This can lead to recovery of the AES key. To prevent this type of attack, wolfSSL added an AES bitsliced implementation which can be enabled with the “--enable-aes-bitsliced” configure option. Thanks to Florian Sieck, Zhiyuan Zhang, Sebastian Berndt, Chitchanok Chuengsatiansup, Thomas Eisenbarth, and Yuval Yarom for the report (Universities of Lübeck, Melbourne, Adelaide and Bochum). The fix for this issue is located in the following GitHub Pull Request: https://github.com/wolfSSL/wolfssl/pull/6854. | 11 days | 5.6.6 |
| LINK | CVE-2023-6937 | Low | wolfSSL prior to 5.6.6 did not check that messages in a single (D)TLS record do not span key boundaries. As a result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the server containing first a ServerHello message and then the rest of the first server flight would be accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL client would accept an unencrypted flight from the server. This does not compromise key negotiation and authentication so it is assigned a low severity rating. Thanks to Johannes Wilson for the report (Sectra Communications and Linköping University). The fix for this issue is located in the following GitHub Pull Request: https://github.com/wolfSSL/wolfssl/pull/7029. | 12 days | 5.6.6 |
| LINK | CVE-2023-3724 | High | In previous versions of wolfSSL if a TLS 1.3 client gets neither a PSK (pre shared key) extension nor a KSE (key share extension) when connecting to a malicious server, a default predictable buffer gets used for the IKM value when generating the session master secret. Using a potentially known IKM value when generating the session master secret key compromises the key generated, allowing an eavesdropper to reconstruct it and potentially allowing surreptitious access to or meddling with message contents in the session. This issue does not affect client validation of connected servers, nor expose private key information, but could result in an insecure TLS 1.3 session when not controlling both sides of the connection. We recommend that TLS 1.3 client side users update the version of wolfSSL used. Thanks to Johannes from Sectra Communications and Linköping University for the report. Fixed in the following GitHub pull request #6412 | 5 days | 5.6.2 |
| LINK | N/A | Low | In cases where a malicious agent could analyze cache timing at a very detailed level, information about the AES key used could be leaked during T/S Box lookups. One such case was shown on RISC-V hardware using the MicroWalk tool (https://github.com/microwalk-project/Microwalk). A hardened version of T/S Box lookups was added in wolfSSL to help mitigate this potential attack and is now on by default with RISC-V builds and can be enabled on other builds if desired by compiling wolfSSL with the macro WOLFSSL_AES_TOUCH_LINES. Thanks to Jan Wichelmann, Christopher Peredy, Florian Sieck, Anna Pätschke, Thomas Eisenbarth (University of Lübeck): MAMBO-V: Dynamic Side-Channel Leakage Analysis on RISC-V. Fixed in the following GitHub pull request #6309 | 4 days | 5.6.2 |
| LINK | CVE-2022-42905 | Medium | In the case that the WOLFSSL_CALLBACKS macro is set when building wolfSSL, there is a potential heap over read of 5 bytes when handling TLS 1.3 client connections. This heap over read is limited to wolfSSL builds explicitly setting the macro WOLFSSL_CALLBACKS, the feature does not get turned on by any other build options. The macro WOLFSSL_CALLBACKS is intended for debug use only, but if having it enabled in production, users are recommended to disable WOLFSSL_CALLBACKS. Users enabling WOLFSSL_CALLBACKS are recommended to update their version of wolfSSL. Thanks to Lucca Hirschi and Steve Kremer from LORIA, Inria and Max Ammann from Trail of Bits for finding and reporting the bug with the tlspuffin tool developed partly at LORIA and Trail of Bits. | 1 day | 5.5.2 |
| LINK | CVE-2022-39173 | Medium | Denial of service attack and buffer overflow against TLS 1.3 servers using session ticket resumption. When built with --enable-session-ticket and making use of TLS 1.3 server code in wolfSSL, there is the possibility of a malicious client to craft a malformed second ClientHello packet that causes the server to crash. This issue is limited to when using both --enable-session-ticket and TLS 1.3 on the server side. Users with TLS 1.3 servers, and having --enable-session-ticket, should update to the latest version of wolfSSL. Thanks to Max at Trail of Bits for the report, found by Lucca Hirschi from LORIA, Inria, France with the tlspuffin tool developed partly at LORIA and Trail of Bits. | 0 days | 5.5.1 |
| LINK | CVE-2022-42961 | Low | Fault injection attack on RAM via Rowhammer leads to ECDSA key disclosure. Users doing operations with private ECC keys such as server side TLS connections and creating ECC signatures, who also have hardware that could be targeted with a sophisticated Rowhammer attack should update the version of wolfSSL and compile using the macro WOLFSSL_CHECK_SIG_FAULTS. Thanks to Yarkin Doroz, Berk Sunar, Koksal Must, Caner Tol, and Kristi Rahman all affiliated with the Vernam Applied Cryptography and Cybersecurity Lab at Worcester Polytechnic Institute for the report. | 5 days | 5.5.0 |
| LINK | CVE-2022-38153 | Low | In wolfSSL version 5.3.0 if compiled with --enable-session-ticket and the client has non-empty session cache, with TLS 1.2 there is the possibility of a man in the middle passing a large session ticket to the client and causing a crash due to an invalid free. There is also the potential for a malicious TLS 1.3 server to crash a client in a similar manner except in TLS 1.3 it is not susceptible to a man in the middle attack. Users on the client side with –enable-session-ticket compiled in and using wolfSSL version 5.3.0 should update their version of wolfSSL. Thanks to Max at Trail of Bits for the report and "LORIA, INRIA, France" for research on tlspuffin. | 5 days | 5.5.0 |
| LINK | CVE-2022-38152 | Low | If using wolfSSL_clear to reset a WOLFSSL object (vs the normal wolfSSL_free/wolfSSL_new) it can result in runtime issues. This exists with builds using the wolfSSL compatibility layer (--enable-opnesslextra) and only when the application is making use of wolfSSL_clear instead of SSL_free/SSL_new. In the case of a TLS 1.3 resumption, after continuing to use the WOLFSSH object after having called wolfSSL_clear, an application could crash. It is suggested that users calling wolfSSL_clear update the version of wolfSSL used. Thanks to Max at Trail of Bits for the report and "LORIA, INRIA, France" for research on tlspuffin. | 2 days | 5.5.0 |
| LINK | N/A | Medium | Potential DoS attack on DTLS 1.2. In the case of receiving a malicious plaintext handshake message at epoch 0 the connection will enter an error state reporting a duplicate message. This affects both server and client side. Users that have DTLS enabled and in use should update their version of wolfSSL to mitigate the potential for a DoS attack. | 0 days | 5.5.0 |
| LINK | CVE-2022-34293 | High | Potential for DTLS DoS attack. In wolfSSL versions before 5.4.0 the return-routability check is wrongly skipped in a specific edge case. The check on the return-routability is there for stopping attacks that either consume excessive resources on the server, or try to use the server as an amplifier sending an excessive amount of messages to a victim IP. If using DTLS 1.0/1.2 on the server side users should update to avoid the potential DoS attack. | 4 days | 5.4.0 |
| LINK | N/A | Medium | Ciphertext side channel attack on ECC and DH operations. Users on systems where rogue agents can monitor memory use should update the version of wolfSSL and change private ECC keys. Thanks to Sen Deng from Southern University of Science and Technology (SUSTech) for the report. | 6 days | 5.4.0 |
| LINK | CVE-2022-25640 | High | A TLS v1.3 server who requires mutual authentication can be bypassed. If a malicious client does not send the certificate_verify message a client can connect without presenting a certificate even if the server requires one. Thank you to Aina Toky Rasoamanana and Olivier Levillain of Télécom SudParis. | 11 days | 5.2.0 |
| LINK | CVE-2022-25638 | High | A TLS v1.3 client attempting to authenticate a TLS v1.3 server can have its certificate check bypassed. If the sig_algo in the certificate_verify message is different than the certificate message checking may be bypassed. Thank you to Aina Toky Rasoamanana and Olivier Levillain of Télécom SudParis. | 6 days | 5.2.0 |
| LINK | CVE-2022-23408 | High | In connections using AES-CBC or DES3 with TLS/DTLS 1.2 or 1.1 the IV being used is not random. Users using wolfSSL version 5.0.0 or 5.1.0 doing TLS/DTLS 1.2 or 1.1 connections, without AEAD only, should update the version of wolfSSL used. | 0 days | 5.1.1 |
| LINK | CVE-2020-12966 CVE-2021-46744 | Medium | Public disclosure of a side channel vulnerability that has been fixed since wolfSSL version 5.1.0. When running on AMD there is the potential to leak private key information with ECDSA operations due to a ciphertext side channel attack. Users on AMD doing ECDSA operations with wolfSSL versions less than 5.1.0 should update their wolfSSL version used. Thanks to professor Yinqian Zhang from Southern University of Science and Technology (SUSTech), his Ph.D. student Mengyuan Li from The Ohio State University, and his M.S students Sen Deng and Yining Tang from SUStech along with other collaborators; Luca Wilke, Jan Wichelmann and Professor Thomas Eisenbarth from the University of Lubeck, Professor Shuai Wang from Hong Kong University of Science and Technology, Professor Radu Teodorescu from The Ohio State University, Huibo Wang, Kang Li and Yueqiang Cheng from Baidu Security and Shoumeng Yang from Ant Financial Services Group. | Fixed 107 days prior to CVE issuance. | 5.1.0 |
| LINK | CVE-2021-44718 | Low | Potential for DoS attack on a wolfSSL client due to processing hello packets of the incorrect side. This affects only connections using TLS v1.2 or less that have also been compromised by a man in the middle attack. Thanks to James Henderson, Mathy Vanhoef, Chris M. Stone, Sam L. Thomas, Nicolas Bailleut, and Tom Chothia (University of Birmingham, KU Leuven, ENS Rennes for the report. | 0 days | 5.1.0 |
| LINK | N/A | Low | Client side session resumption issue once the session resumption cache has been filled up. The hijacking of a session resumption has been demonstrated so far with only non verified peer connections. That is where the client is not verifying the server’s CA that it is connecting to. There is the potential though for other cases involving proxies that are verifying the server to be at risk, if using wolfSSL in a case involving proxies use wolfSSL_get1_session and then wolfSSL_SESSION_free when done where possible. If not adding in the session get/free function calls we recommend that users of wolfSSL that are resuming sessions update to the latest version (wolfSSL version 5.1.0 or later). Thanks to the UK's National Cyber Security Centre (NCSC) for the report. | 6 days | 5.1.0 |
| LINK | N/A | Low | Hang with DSA signature creation when a specific q value is used in a maliciously crafted key. If a DSA key with an invalid q value of either 1 or 0 was decoded and used for creating a signature, it would result in a hang in wolfSSL. Users that are creating signatures with DSA and are using keys supplied from an outside source are affected. | 3 days | 5.0.0 |
| LINK | N/A | Low | Issue with incorrectly validating a certificate that has multiple subject alternative names when given a name constraint. In the case where more than one subject alternative name is used in the certificate, previous versions of wolfSSL could incorrectly validate the certificate. Users verifying certificates with multiple alternative names and name constraints, are recommended to either use the certificate verify callback to check for this case or update the version of wolfSSL used. Thanks to Luiz Angelo Daros de Luca for the report. | 2 days | 5.0.0 |
| LINK | CVE-2021-38597 | High | OCSP verification issue when response is for a certificate with no relation to the chain in question BUT that response contains the NoCheck extension which effectively disables ALL verification of that one cert. Users who should upgrade to 4.8.1 are TLS client users doing OCSP, TLS server users doing mutual auth with OCSP, and CertManager users doing OCSP independent of TLS. Thanks to Jan Nauber, Marco Smeets, Werner Rueschenbaum and Alissa Kim for the report. | 8 days | 4.8.1 |
| LINK | N/A | Low | OCSP request/response verification issue. In the case that the serial number in the OCSP request differs from the serial number in the OCSP response the error from the comparison was not resulting in a failed verification. We recommend users that have wolfSSL version 4.6.0 and 4.7.0 with OCSP enabled update their version of wolfSSL. Version 4.5.0 and earlier are not affected by this report. Thanks to Rainer, Roee, Barak, Hila and Shoshi (from Cymotive and CARIAD) for the report. | 2 days | 4.8.0 |
| LINK | CVE-2021-3336 | High | In earlier versions of wolfSSL there exists a potential man in the middle attack on TLS 1.3 clients. Malicious attackers with a privileged network position can impersonate TLS 1.3 servers and bypass authentication. Users that have applications with client side code and have TLS 1.3 turned on, should update to the latest version of wolfSSL. Users that do not have TLS 1.3 turned on, or that are server side only, are NOT affected by this report. For the code change see https://github.com/wolfSSL/wolfssl/pull/3676. Thanks to Aina Toky Rasoamanana and Olivier Levillain from Télécom SudParis for the report. | Fixed 12 days prior to CVE issuance | 4.7.0 |
| LINK | N/A | Low | In the case of using custom ECC curves there is the potential for a crafted compressed ECC key that has a custom prime value to cause a hang when imported. This only affects applications that are loading in ECC keys with wolfSSL builds that have compressed ECC keys and custom ECC curves enabled. | 1 day | 4.7.0 |
| LINK | N/A | Low | With TLS 1.3 authenticated-only ciphers a section of the server hello could contain 16 bytes of uninitialized data when sent to the connected peer. This affects only a specific build of wolfSSL with TLS 1.3 early data enabled and using authenticated-only ciphers with TLS 1.3. | 12 days | 4.7.0 |
| LINK | CVE-2021-24116 | Low | Side-Channel cache look up vulnerability in base64 PEM decoding for versions of wolfSSL 4.5.0 and earlier. Versions 4.6.0 and up contain a fix and do not need to be updated for this report. If decoding a PEM format private key using version 4.5.0 and older of wolfSSL then we recommend updating the version of wolfSSL used. Thanks to Florian Sieck, Jan Wichelmann, Sebastian Berndt and Thomas Eisenbarth for the report. | Fixed 7 months prior to CVE issuance | 4.6.0 |
| LINK | CVE-2020-36177 | High | RsaPad_PSS in wolfcrypt/src/rsa.c in wolfSSL before 4.6.0 has an out-of-bounds write for certain relationships between key size and digest size. | 1 day | 4.6.0 |
| LINK | CVE-2020-24613 | High | In wolfSSL versions prior to 4.5.0 there exists a potential man in the middle attack on TLS 1.3 clients. Malicious attackers with a privileged network position can impersonate TLS 1.3 servers and bypass authentication. Users that have applications with client side code and have TLS 1.3 turned on, should update to the latest version of wolfSSL. Users that do not have TLS 1.3 turned on, or that are server side only, are NOT affected by this report. Thanks to Gerald Doussot from NCC group for the report. | 2 days | 4.5.0 |
| LINK | CVE-2020-12457 | Low | In wolfSSL versions prior to 4.5.0, a denial of service attack on TLS 1.3 servers from repetitively sending ChangeCipherSpecs messages is possible. This denial of service results from the relatively low effort of sending a ChangeCipherSpecs message versus the effort of the server to process that message. Users with TLS 1.3 servers are recommended to update to the most recent version of wolfSSL which limits the number of TLS 1.3 ChangeCipherSpecs that can be received in order to avoid this DoS attack. CVE-2020-12457 was reserved for the report. Thanks to Lenny Wang of Tencent Security Xuanwu LAB. | Fixed 114 days prior to CVE issuance | 4.5.0 |
| LINK | CVE-2020-15309 | Low | wolfSSL versions prior to 4.5.0 included a potential cache timing attack on public key operations in builds that are not using SP (single precision). Users that have a system where malicious agents could execute code on the system, are not using the SP build with wolfSSL, and are doing private key operations on the system (such as signing with a private key) are recommended to regenerate private keys and update to the most recent version of wolfSSL. CVE-2020-15309 is reserved for this issue. Thanks to Ida Bruhns from Universität zu Lübeck for the report. | Fixed 57 days prior to CVE issuance | 4.5.0 |
| LINK | N/A | Low | In wolfSSL versions prior to 4.5.0, when using SGX with EC scalar multiplication the possibility of side-channel attacks are present. To mitigate the risk of side channel attacks wolfSSL’s single precision EC operations should be used instead. Release 4.5.0 turns this on be default now with SGX builds and in previous versions of wolfSSL this can be turned on by using the WOLFSSL_SP macros. Thank you to Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley from the Network and Information Security Group (NISEC) at Tampere University for the report. | 1 day | 4.5.0 |
| LINK | N/A | High | wolfSSL versions prior to 4.5.0 may leak the private key in the case that PEM format private keys are bundled in with PEM certificates into a single file. This is due to the misclassification of certificate type versus private key type when parsing through the PEM file. To be affected, wolfSSL would need to have been built with OPENSSL_EXTRA (--enable-opensslextra). Some build variants such as --enable-all and --enable-opensslall also turn on this code path, checking wolfssl/options.h for OPENSSL_EXTRA will show if the macro was used with the build. If having built with the opensslextra enable option and having placed PEM certificates with PEM private keys in the same file when loading up the certificate file, then we recommend updating wolfSSL for this use case and also recommend regenerating any private keys in the file. | 1 day | 4.5.0 |
| LINK | N/A | Low | In wolfSSL versions prior to 4.5.0, during the handshake, clear application_data messages in epoch 0 are processed and returned to the application. Fixed by dropping received application_data messages in epoch 0. Thank you to Paul Fiterau of Uppsala University and Robert Merget of Ruhr-University Bochum for the report. | 0 days | 4.5.0 |
| LINK | CVE-2020-11713 | Low | wolfSSL versions prior to 4.4.0 have mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Version 4.4.0 fixes this to be constant time and cache resistant. Thank you to Pietro Borrello at Sapienza University of Rome. | Fixed 4 days prior to CVE issuance | 4.4.0 |
| LINK | CVE-2020-11735 | Low | wolfSSL versions prior to 4.4.0 using fast math do not use a constant-time modular inverse when mapping to affine coordinates. Version 4.4.0 uses a constant time modular inverse when mapping to affine when operation involves a private key - keygen, calc shared secret, sign. Thank you to Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley from the Network and Information Security Group (NISEC) at Tampere University for the report. | Fixed 36 days prior to CVE issuance | 4.4.0 |
| CVE-2019-18840 | High | In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data while handshaking. Specifically, there is a one-byte heap-based buffer overflow inside the DecodedCert structure in GetName in wolfcrypt/src/asn.c because the domain name location index is mishandled. Because a pointer is overwritten, there is an invalid free | 0 days | 4.3.0 | |
| LINK | N/A | Low | In wolfSSL versions prior to 4.2.0, there is a potential program hang when ocspstapling2 is enabled. This is a moderate level fix that affects users who have ocspstapling2 enabled(off by default) and are on the server side. In parsing a CSR2 (Certificate Status Request v2 ) on the server side, there was the potential for a malformed extension to cause a program hang. Discovered by Robert Hoerr. | 5 days | 4.2.0 |
| LINK | CVE-2019-16748 | High | In wolfSSL through 4.1.0, there is a missing sanity check of memory accesses in parsing ASN.1 certificate data while handshaking. Specifically, there is a one-byte heap-based buffer over-read in CheckCertSignature_ex in wolfcrypt/src/asn.c. | 1 days | 4.2.0 |
| LINK | CVE-2019-15651 | High | wolfSSL 4.1.0 has a one-byte heap-based buffer over-read in DecodeCertExtensions in wolfcrypt/src/asn.c because reading the ASN_BOOLEAN byte is mishandled for a crafted DER certificate in GetLength_ex. | 1 days | 4.2.0 |
| LINK | N/A | Low | wolfSSL versions before 4.2.0 have potential for an invalid read when TLS 1.3 and pre-shared keys is enabled. Users without TLS 1.3 enabled are unaffected. Users with TLS 1.3 enabled and HAVE_SESSION_TICKET defined or NO_PSK not defined should update wolfSSL versions. Discovered by Robert Hoerr. | 0 days | 4.2.0 |
| LINK | CVE-2019-14317 | Low | Versions of wolfSSL before 4.2.0 are vulnerable to DSA operations involving an attack on recovering DSA private keys. This affects users that have DSA enabled and are performing DSA operations (off by default). ECDSA is NOT affected by this and TLS code is NOT affected by this issue. Discovered by Ján Jančár at Masaryk University. | 0 days | 4.2.0 |
| LINK | CVE-2019-13628 | Medium | Versions of wolfSSL before 4.1.0 are vulnerable to the potential leak of nonce sizes when performing ECDSA signing operations. The leak is considered to be difficult to exploit but it could potentially be used maliciously to perform a lattice based timing attack against previous wolfSSL versions. Discovered by Ján Jančár at Masaryk University. | 5 days | 4.1.0 |
| LINK | CVE-2019-11873 | High | In wolfSSL version 4.0.0, there is a potential buffer overflow case with the TLSv1.3 PSK extension parsing. This affects users that are enabling TLSv1.3 (--enable-tls13). Discovered by Robert Hoerr. | 0 days | 4.1.0 |
| LINK | CVE-2018-16870 | Medium | Versions of wolfSSL prior to 3.15.7 are vulnerable to a new variant of the Bleichenbacher attack to perform downgrade attacks against TLS, which may lead to leakage of sensible data. | 0 days | 3.15.7 |
| LINK | CVE-2018-12436 | Medium | Versions of wolfSSL up to and including 3.15.0 are vulnerable to a Key Extraction Side Channel Attack. A patch (wolfssl-3.15.1.patch) is available for download now on our website and a full release will be available next week containing the patch. | 0 days | 3.15.3 |
| LINK | CVE-2017-13099 | Medium | Versions of wolfSSL up to 3.12.2 have a weak Bleichenbacher vulnerability with suites that use an RSA-encrypted premaster secret. Discovered by Hanno Böck, Juraj Somorovsky, Craig Young. | 9 days | 3.13.0 |
| LINK | CVE-2017-2800 | Critical | Versions of wolfSSL before 3.11.0 have a possible out-of-bounds write by one from a crafted certificate being passed to the function wolfSSL_X509_NAME_get_text_by_NID. Discovered by Aleksandar Nikolic of Cisco Talos. | Fixed 20 days prior to CVE issuance | 3.11.0 |
| LINK | CVE-2017-8855 | High | In versions of wolfSSL before 3.11.0 there are cases where a malformed DH key is not rejected by the function wc_DhAgree. Thanks to Yueh-Hsun Lin and Peng Li at KNOX Security at Samsung Research America. | Fixed 5 days prior to CVE issuance | 3.11.0 |
| LINK | CVE-2017-8854 | High | Versions of wolfSSL before 3.10.2 have a possible out-of-bounds memory access when loading crafted DH parameters. Thanks to Yueh-Hsun Lin and Peng Li at KNOX Security at Samsung Research America. | Fixed 88 days prior to CVE issuance | 3.10.2 |
| LINK | CVE-2017-6076 | Medium | In versions of wolfSSL before 3.10.2 the software implementation makes it easier to extract RSA key information for a malicious user who has access to view the cache on a machine. | Fixed 13 days prior to CVE issuance | 3.10.2 |
| LINK | CVE-2016-7440 | Medium | Software AES table lookups do not properly consider cache-bank access times | Fixed 81 days prior to CVE issuance | 3.9.10 |
| LINK | CVE-2016-7439 | Medium | Software RSA does not properly consider cache-bank monitoring | Fixed 81 days prior to CVE issuance | 3.9.10 |
| LINK | CVE-2016-7438 | Medium | Software ECC does not properly consider cache-bank monitoring | Fixed 81 days prior to CVE issuance | 3.9.10 |
| LINK | CVE-2015-6925 | High | Potential DOS attack when using DTLS on the server side | Fixed 127 days prior to CVE issuance | 3.6.8 |
| LINK | CVE-2015-7744 | Medium | TLS servers using RSA with ephemeral keys may leak key bits on signature faults | Fixed 127 days prior to CVE issuance | 3.6.8 |
| LINK | CVE-2014-2903 | Medium | Server certificate not authorized for use in SSL/TLS handshake. CyaSSL does not check the key usage extension in leaf certificates. | Fixed 13 days prior to issuance | 2.9.4 |
| LINK | CVE-2014-2900 | Medium | Unknown critical certificate extension allowed | Fixed 13 days prior to issuance | 2.9.4 |
| LINK | CVE-2014-2899 | Medium | NULL pointer dereference on peer cert request after certificate parsing failure | Fixed 13 days prior to issuance | 2.9.4 |
| LINK | CVE-2014-2898 | Low | Out of bounds read on repeated calls to CyaSSL_read(), memory access error. | Fixed 13 days prior to issuance | 2.9.4 |
| LINK | CVE-2014-2897 | High | Out of bounds read, SSL 3.0 HMAC doesn't check padding length for verify failure | Fixed 13 days prior to issuance | 2.9.4 |
| LINK | CVE-2014-2896 | N/A | Memory corruption, possible out of bounds read on length check in DoAlert() | Fixed 13 days prior to issuance | 2.9.4 |
Known SSL/TLS Protocol Attacks
As researchers and security professionals release new attacks against SSL/TLS protocol versions, algorithms, or cryptographic modes, we want to keep our users informed if wolfSSL is vulnerable or safe to such attacks.
| DATE | NAME | SEVERITY | WOLFSSL AFFECTED | ADDRESSED |
|---|---|---|---|---|
| 09.09.2020 | Raccoon Attack | Low | NO | N/A |
| 12.08.2017 | The ROBOT Attack | Medium | YES | YES |
| 08.24.2016 | SWEET32 Attack | TLS & SSH - High OpenVPN - Medium | YES | YES |
| 03.01.2016 | DROWN Attack | Medium | NO | N/A |
| 01.07.2016 | SLOTH Attack | Medium | NO | N/A |
| 08.11.2015 | Pandora's Box Attack | N/A | NO | N/A |
| 07.09.2015 | Logjam Attack | Critical | NO | N/A |
| 03.30.2015 | Bar Mitzvah Attack | Medium | YES | YES |
| 03.04.2015 | FREAK Attack | Medium for all implementations | YES | N/A |
| 12.12.2014 | POODLE Bites Again | Medium | NO | N/A |
| 10.14.2014 | POODLE: Padding Oracle On Downgraded Legacy Encryption | Medium | YES | YES |
| 04.09.2014 | Heartbleed Bug | Medium | NO | N/A |
| 02.05.2014 | Lucky 13 Attack | Low | YES | YES |
| 09.24.2012 | CRIME Attack | Low | YES | YES |
| 05.13.2011 | BEAST Attack | Medium | YES | YES |
Known wolfSSH Vulnerabilities
The SSH protocol is well documented and under constant scrutiny by the top experts in security and cryptography. SSH was quickly adopted as a standard world wide. SSH secures connections between billions of users to their shell accounts, and allows for secure file transfers between billions of computers, servers, Internet of Things (IoT) devices, and embedded systems. The security provided by an SSH Library depends on the underlying strength of its cryptography which is used to encrypt communications.
| INFO | CVE ID | SEVERITY | DESCRIPTION | TIME TO FIX | FIXED IN VERSION |
|---|---|---|---|---|---|
| LINK | CVE-2024-2873 | High | A properly crafted SSH client can bypass user authentication in the wolfSSH server code. The added fix filters the messages that are allowed during different operational states. | 0 days | 1.4.17 |
| LINK | N/A | High | wolfSSHd would allow users without passwords to log in with any password. This is fixed as of this version. The return value of crypt() was not correctly checked. This issue was introduced in v1.4.11 and only affects wolfSSHd when using the default authentication callback provided with wolfSSHd. Anyone using wolfSSHd should upgrade to v1.4.13. | 18 days | 1.4.13 |
| LINK | N/A | Low | When processing SFTP messages, wolfSSH isn't checking data lengths against the size of the message and is potentially under-allocating, over-reading, and over-writing buffers. | 4 days | 1.4.8 |
| LINK | N/A | Low | When signing with RSA, wolfSSH wasn't checking if the signature succeeds. We added verify step to generating an RSA signature. There is a potential chance to analyze a bad signature to get the private key from it. | 2 days | 1.4.15 |
Contact Us
Email: facts@wolfssl.com
Phone: +1 (425) 245-8247