CVE-2026-3548 is a pair of buffer overflows in the wolfSSL CRL parser, scored 9.8 (Critical) in the CVE record. A crafted certificate revocation list can write out of bounds, on the heap or the stack. Only builds with CRL support that load CRLs from untrusted sources are exposed.
What's affected
- Product: wolfSSL, the embedded TLS library
- Affected builds: those that enable CRL support, and only when a CRL from an untrusted source is loaded
- Fix: two pull requests on the wolfSSL repository, number 9628 and number 9873
- Fixed release: the larger CRL number change in 9873 carries the label "Release version 5.9.4" on GitHub. The record itself names no version, so confirm in the wolfSSL release notes
The record describes a heap-based overflow when the CRL number is stored as a hexadecimal string, and a stack-based overflow for sufficiently large CRL numbers. The first pull request explains that the buffer was sized from the number of octets instead of the hexadecimal text length, which needs two characters per octet plus a terminator. The CVE is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
Check the wolfSSL version and the options your build used. For an autoconf build, the installed header shows both:
grep LIBWOLFSSL_VERSION_STRING /usr/local/include/wolfssl/version.h
grep -E "HAVE_CRL|HAVE_ECH" /usr/local/include/wolfssl/options.h
Paths differ by install. Many products embed wolfSSL, so also ask your vendors whether their firmware or application bundles it, and which version.
The record is clear that builds without CRL support are not affected. If HAVE_CRL does not appear in your options, you can lower the priority of this one for that build.
What to do now
- Find every place wolfSSL is used, including copies embedded in vendor products.
- Check whether CRL support is enabled in each build.
- Upgrade to a wolfSSL release that includes both fixes. The pull requests are labelled for 5.9.4, so check the release notes for the exact release.
- Until you upgrade, do not load CRLs from untrusted sources. Fetch them only from issuers you trust, over a channel you trust.
- For embedded devices, ask the vendor for a firmware update that includes the fix.
Why it matters
A buffer overflow, CWE-122 for the heap and CWE-787 for out-of-bounds writes in general, happens when code writes more data than a buffer holds. The parser here sizes a buffer by one rule and then fills it by another. Out-of-bounds writes in a TLS library are serious because the library parses data from the network.
The condition in the record keeps the real exposure narrower than the 9.8 score suggests. A CRL is usually fetched from an issuer you chose. The risk rises when software loads revocation lists from places it should not trust, or when an attacker can sit between the device and its source.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I do not use CRLs?
The record says only builds that enable CRL support are affected, and only when a CRL from an untrusted source is loaded.
Which release has the fix?
The record names none. The larger CRL number pull request is labelled for release 5.9.4 on GitHub. Check the wolfSSL release notes to confirm.
Sources
- CVE record for CVE-2026-3548 on Gold
- wolfSSL pull request 9628, CRL number hex string fix
- wolfSSL pull request 9873, larger CRL numbers
Last reviewed: 19 October 2026.
