How many CVEs does the NVD list for my wolfSSL version?
Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 23 October 2026 through the NVD API, rejected entries excluded. The NVD lists wolfSSL under cpe:2.3:a:wolfssl:wolfssl; wolfCrypt has no CVE record of its own, its vulnerabilities are listed under wolfSSL. The old CyaSSL names returned no hit for any of the versions checked.
The “9.0 or higher” figure follows the NVD's score. wolfSSL as CNA often scores much lower: CVE-2026-4395 is 9.8 at the NVD and 1.3 (“Low”) at wolfSSL.
| Version, release date | CVEs according to the NVD, of which CVSS 9.0 or higher |
|---|---|
| 3.15.7, 26 December 2018 (last 3.x) | 81 CVEs, of which 15 at 9.0 or higher |
| 4.8.1, 16 July 2021 (last 4.x) | 71 CVEs, of which 12 at 9.0 or higher |
| 5.0.0, 1 November 2021 | 72 CVEs, of which 13 at 9.0 or higher |
| 5.5.4, 21 December 2022 (last 5.5) | 71 CVEs, of which 11 at 9.0 or higher |
| 5.6.6, 19 December 2023 (last 5.6) | 72 CVEs, of which 11 at 9.0 or higher |
| 5.7.6, 31 December 2024 (last 5.7) | 71 CVEs, of which 10 at 9.0 or higher |
| 5.8.2, 17 July 2025 | 80 CVEs, of which 11 at 9.0 or higher |
| 5.8.4, 20 November 2025 (last 5.8) | 78 CVEs, of which 11 at 9.0 or higher |
| 5.9.0, 18 March 2026 | 63 CVEs, of which 7 at 9.0 or higher |
| 5.9.1, 8 April 2026 | 39 CVEs, of which 2 at 9.0 or higher |
| 5.9.2, 23 June 2026 | 10 CVEs, of which 1 at 9.0 or higher (CVE-2026-89134) |
| 5.9.4, 25 September 2026 (newest) | None in the NVD. CVE-2026-89136 (RPK, 5.6.0 to 5.9.2 according to wolfSSL) is still listed there without a configuration. |
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:wolfssl:wolfssl:5.8.4&noRejected" \
| jq .totalResults78curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:wolfssl:wolfssl:5.9.4&noRejected" \
| jq .totalResults0Which eleven CVEs at 9.0 or higher does wolfSSL 5.8.4 have?
Most of them require a feature that must be switched on in the build. The condition is stated in each CVE's description. The first number is the NVD's score, the second wolfSSL's.
| CVE, CVSS NVD / wolfSSL | What, condition, fixed according to the NVD |
|---|---|
| CVE-2026-3548, 9.8 / 7.2 | Buffer overflows in the CRL parser on CRL numbers. Only with CRL support and a CRL from an untrusted source. Fixed in 5.9.0. |
| CVE-2026-3549, 9.8 / 8.3 | Heap overflow when parsing ECH in TLS 1.3. ECH is off by default. Fixed in 5.9.0. |
| CVE-2026-3849, 9.8 / 6.9 | Stack overflow on the client through an oversized ECH config. Only with --enable-ech. Fixed in 5.9.0. |
| CVE-2026-4395, 9.8 / 1.3 | Heap overflow in the ECC path via KCAPI (WOLFSSL_KCAPI_ECC). Fixed in 5.9.0. |
| CVE-2026-5187, 9.8 / 2.3 | Out-of-bounds write in DecodeObjectId() on crafted OIDs. No condition stated. Affected up to and including 5.9.0. |
| CVE-2026-5264, 9.8 / 8.3 | Heap overflow on DTLS 1.3 ACK messages. Fixed in 5.9.1. |
| CVE-2026-7531, 9.8 / 2.3 | Use-after-free in the PQC hybrid key exchange in TLS 1.3, triggered by a malicious server. Incomplete fix of CVE-2026-5460. Fixed in 5.9.2. |
| CVE-2026-5194, 9.1 / 9.3 | ECDSA verification accepts hashes that are too short. Only when EdDSA or a PQC signature scheme is also enabled. Fixed in 5.9.1. |
| CVE-2026-5393, 9.1 / 6.3 | Out-of-bounds read on dual-algorithm CertificateVerify. Only with --enable-experimental and --enable-dual-alg-certs. Fixed in 5.9.1. |
| CVE-2026-5503, 9.1 / 6.9 | ECH and SNI: 255 bytes are written past the end of the buffer. Only with ECH. Affected up to and including 5.9.0. |
| CVE-2026-6094, 9.1 / 6.3 | Out-of-bounds read in wc_PKCS7_DecodeEnvelopedData, for example via S/MIME or CMS. Fixed in 5.9.2. |
Can I switch the vulnerable code off in the build?
Eight of the eleven depend on features that are off by default in configure: ECH (HAVE_ECH, three CVEs), CRL (HAVE_CRL), DTLS 1.3 (WOLFSSL_DTLS13), PKCS7 (HAVE_PKCS7), KCAPI for ECC (WOLFSSL_KCAPI_ECC) and dual-algorithm certificates (WOLFSSL_DUAL_ALG_CERTS, which additionally requires --enable-experimental).
Keil and IAR projects have no configure. There user_settings.h states which macros are set. If you do not need ECH, CRL, DTLS 1.3 or PKCS7, remove the macro; the code is then missing from the build. For CVE-2026-5187 the description states no condition; only a new release helps here.
curl -s https:/Output
[AS_HELP_STRING([--enable-ech],[Enable ECH (default: disabled)])],
[AS_HELP_STRING([--enable-kcapi-ecc],[Enable libkcapi use for ECC (default: disabled)])],
[AS_HELP_STRING([--enable-dtls13],[Enable wolfSSL DTLS v1.3 (default: disabled)])],
[AS_HELP_STRING([--enable-crl],[Enable CRL (Use =io for inline CRL HTTP GET) (default: disabled)])],
[AS_HELP_STRING([--enable-pkcs7],[Enable PKCS7 (default: disabled)])],Which wolfSSL version do vendor SDKs ship?
ESP-IDF uses mbedTLS for TLS by default. wolfSSL only enters the build with the option CONFIG_ESP_TLS_USING_WOLFSSL and a separate component.
| Source, as of 23 October 2026 | wolfSSL version, CVEs according to the NVD |
|---|---|
| Espressif's esp-wolfssl, last commit 15 June 2026 | 5.9.1, exactly the tag v5.9.1-stable. 39 CVEs, of which 2 at 9.0 or higher. No longer within wolfSSL's support window. |
ESP Component Registry, component wolfssl/wolfssl | Newest version 5.8.2~1 of 22 August 2025. 80 CVEs for 5.8.2, of which 11 at 9.0 or higher. |
curl -s https:/Output
#define LIBWOLFSSL_VERSION_STRING "5.9.1"Where do the NVD and wolfSSL disagree?
wolfSSL keeps its own list of its vulnerabilities with severity and fixed version. Of the 167 rows it shows on 23 October 2026, 19 carry no CVE number; those vulnerabilities are missing from every NVD query.
Others are in the NVD without a configuration and count for no version: CVE-2026-89136 (authentication bypass with raw public keys, 5.6.0 to 5.9.2 according to wolfSSL, fixed in 5.9.4) with status “Awaiting Analysis”, and CVE-2025-7395 (hostname check, only with Apple certificate validation) with status “Deferred”.
The scores differ as well. SECURITY-POLICY.md explains part of it: defects that require physical access, physical-level side channels or fault injection are usually handled by wolfSSL as bug fixes, not as CVEs.
Which wolfSSL releases still get fixes?
SECURITY-POLICY.md (last updated 22 April 2026): “Security fixes are released for the current stable release and the immediately prior stable release. Older releases receive security fixes only under active commercial support agreements.” On 23 October 2026 these are 5.9.4 and 5.9.2.
wolfSSL publishes three to four releases a year, in 2026 so far 5.9.0 (18 March), 5.9.1 (8 April), 5.9.2 (23 June) and 5.9.4 (25 September). Staying on a line therefore means getting fixes only by moving to a new release.
Where is the wolfSSL version in my firmware?
In the source the version sits in wolfssl/version.h: LIBWOLFSSL_VERSION_STRING and LIBWOLFSSL_VERSION_HEX (0x05009004 for 5.9.4). The file ships with the release; Keil and IAR projects take it over unchanged.
In the build the version only appears if the firmware calls wolfSSL_lib_version() or prints the macro itself, and then as a bare “5.9.4” without the name wolfSSL. In our test build (5.9.4, GCC for x86-64 with --gc-sections, stripped) strings found neither the version nor the name without that call. The version then comes from version.h in the project; the function names with the prefix wolfSSL_ in the ELF symbol table show that wolfSSL is linked.
grep -E "define LIBWOLFSSL_VERSION_(STRING|HEX)" \
wolfssl-5.9.4/wolfssl/version.hOutput
#define LIBWOLFSSL_VERSION_STRING "5.9.4"
#define LIBWOLFSSL_VERSION_HEX 0x05009004How do I check this by hand?
- 1
Read the version: in the project from
wolfssl/version.h; in the build withstrings -a firmware.elfif the firmware prints the version. - 2
Check whether wolfSSL is linked:
arm-none-eabi-nm firmware.elf | grep -i wolfssl_lists its functions in the image. - 3
Query the NVD with
cpe:2.3:a:wolfssl:wolfssl:<version>. - 4
Read wolfSSL's vulnerability list: it names vulnerabilities without a CVE number and fixes whose version the NVD states differently.
- 5
Check the configuration: many vulnerabilities need an option, such as RPK (
HAVE_RPK) for CVE-2026-89136. The options are inuser_settings.hor in theconfigureoptions. - 6
Check the CISA KEV catalogue for actively exploited vulnerabilities.
Can this run automatically?
LegacyMind reads the linked libraries with their versions from the build and matches each against the vulnerability sources, with the place in the build where it was read. Where the binary proves no version, the field stays empty.
Questions
Which wolfSSL version should I use?
The current release, as of 23 October 2026 that is 5.9.4 of 25 September 2026. Only this one and the previous stable release (5.9.2) receive security fixes without commercial support.
Does wolfSSL 5.8 still get security fixes?
Not without commercial support. For 5.8.4, the last release of that line, the NVD lists 78 CVEs on 23 October 2026.
Which wolfSSL version is in ESP-IDF?
ESP-IDF itself ships no wolfSSL and uses mbedTLS. Espressif's esp-wolfssl component contains wolfSSL 5.9.1 on 23 October 2026, the wolfssl/wolfssl component in the ESP Component Registry 5.8.2~1.
Does an ECH or CRL vulnerability affect me if I do not use the feature?
Only if the code is in the build. ECH, CRL, DTLS 1.3, PKCS7 and dual-algorithm certificates are off by default in configure; with Keil and IAR user_settings.h decides. If the macro is not set, the affected code is missing from the image.
Is a wolfSSL vulnerability actively exploited?
As of 23 October 2026 no wolfSSL vulnerability is in the CISA catalogue of known exploited vulnerabilities (catalogue version 2026.10.23).
Why does the NVD score wolfSSL vulnerabilities so much higher than wolfSSL?
The NVD scores without regard to the configuration and to the attack paths wolfSSL excludes. For the assessment in a device what counts is whether the affected function is built and reachable.