Mbed TLS and wolfSSL vulnerabilities in embedded firmware: identify, triage, patch

Both libraries are designed to be cut down at compile time. The Trusted Firmware project page for Mbed TLS describes it as implementing the TLS and DTLS protocols and X.509 certificate handling, using the PSA Crypto API in TF-PSA-Crypto for its cryptography, with a "small code footprint" that "makes the project suitable for embedded systems"; its users include TF-A, TF-M and OP-TEE. wolfSSL takes the same approach through configure flags and user_settings.h macros. The result is that two devices reporting the same library version can have very different attack surfaces: one may compile in TLS 1.3, DTLS, session tickets and an OpenSSL compatibility layer, while another builds a PSK-only TLS 1.2 client.

That matters for triage. Advisories from both projects routinely say a CVE applies only when a given feature or macro is enabled, so a version match is a starting point rather than a verdict. Our OpenSSL vulnerabilities in embedded firmware guide covers the third common TLS stack, where the problem is more often a frozen end-of-life branch and distribution backports.

Three classes account for most of the advisories both projects publish: memory-safety bugs in certificate and ASN.1 parsing, timing side channels, and state-machine bugs in the TLS 1.3 and DTLS handshakes.

Certificate and ASN.1 parsing. Every TLS client parses a certificate the peer sends before it knows whether to trust it, so parser bugs are reachable from the network. Mbed TLS's SECURITY.md states that it does not check certificates for strict X.509 compliance, but that if a certificate "causes undefined behavior when it is parsed by Mbed TLS, that is considered a security vulnerability." The CVE-2026-49300 advisory shows the subtler version of the problem: two parsing flaws make Mbed TLS read some invalid certificates as CA certificates while most other X.509 parsers read them as end-entity certificates. The advisory's own scenario is a device whose trusted roots can be customised and are validated off-device by a different implementation, which describes many managed IoT fleets. The CVE-2026-25833 advisory is a purely embedded case: the vulnerable x509_inet_pton_ipv6() is the library's own fallback, used only "where the platform/toolchain does not provide inet_pton()", which is common on bare-metal toolchains. Our memory corruption in embedded firmware guide covers the bug class itself.

Timing side channels. Mbed TLS's threat model says it provides limited protection against timing attacks and aims to cover "publicly documented attack techniques", and it makes no guarantees against physical attacks such as power analysis or fault injection, which must be mitigated by the platform. The CVE-2026-50587 advisory describes an attacker who submits crafted ciphertexts and recovers plaintext "as a Bleichenbacher oracle", for example the pre-master secret in a TLS 1.2 RSA key exchange; it follows CVE-2024-23170, a January 2024 RSA timing advisory tied to the Marvin attack. Compilers are a recurring source: the same SECURITY.md recommends -O2 or -Os because other optimisation levels are less scrutinised, and the wolfSSL vulnerabilities page lists CVE-2025-12888, timing side channels in X25519 "introduced by compiler optimizations" on Xtensa-based ESP32 chips, and CVE-2026-3580, where GCC at -O3 turned constant-time masking into branches on RISC-V RV32I.

TLS 1.3 and DTLS handshake logic. Newer protocol code carries more bugs per line than the parsers that have been fuzzed for a decade. The CVE-2026-34873 advisory explains how a server supporting both TLS 1.2 and 1.3, after sending a HelloRetryRequest, could resume a TLS 1.2 session "using an all-zero master secret", letting a man-in-the-middle bypass client authentication. wolfSSL's list includes a heap overflow in DTLS 1.3 ACK processing (CVE-2026-5264), a heap overflow in TLS 1.3 Encrypted Client Hello parsing (CVE-2026-3549, ECH being off by default) and a post-handshake authentication flaw (CVE-2026-55962) that only affects builds with --enable-postauth. Devices using DTLS, such as CoAP endpoints, should read our CoAP protocol security guide alongside these.

Mbed TLS publishes one page per advisory on its Security Advisories index, going back to the PolarSSL advisories of 2011. Each page has a fixed header (title, CVE, date, affected and unaffected versions, impact, severity, credits) followed by the vulnerability description, the conditions under which an application is affected, any work-around, the resolution and, on recent advisories, a table of fix commits per branch. That table comes with a caveat worth quoting to anyone planning a backport: the commits "may not apply cleanly to older versions of the library, and may not provide a complete fix even if they do apply", and the team "does not provide support outside of maintained branches."

The disclosure process is also worth knowing. The Mbed TLS vulnerability process page states that, because of export control rules, "security fixes cannot be shared privately with Trusted Stakeholders", and that fixes are often withheld until the public disclosure date because they "reveal enough information for a skilled attacker to re-construct the originally reported exploit." In practice, a device maker learns about an Mbed TLS vulnerability and its fix on the same day as everyone else, so the patching clock starts at release. The July 2026 batch shows the pattern: Mbed TLS 3.6.7, 4.1.1 and 4.2.0 were published together on 7 July 2026 on the Mbed TLS GitHub releases page, and the advisories index lists twenty advisories from that July 2026 batch.

wolfSSL publishes a single table on its security vulnerabilities page, listing CVE, severity, description, time to fix and the fixed release; it held 131 rated entries when read on 2026-11-12. The descriptions are unusually specific about configuration, often naming the exact macros and configure options that make a build affected. The same entries appear in the wolfSSL ChangeLog under each release's Vulnerabilities heading, with severity tags and the fixing pull request or commit. Release 5.9.4, dated 25 September 2026, is the newest release there.

Stay on a maintained Mbed TLS LTS. The Mbed TLS BRANCHES.md lists mbedtls-3.6 (released March 2024, maintained until March 2027) and mbedtls-4.1 (released March 2026, maintained until March 2029) as the supported LTS branches, with an 18-month LTS cycle and three-year support each. On LTS branches the project tries "to also maintain ABI compatibility" and to avoid "any increase in code size or RAM usage", which is what makes a patch release a drop-in update on a flash-constrained device. Moving from 3.6 to 4.x is a major-version change: crypto moves into TF-PSA-Crypto and the PSA Crypto API, and the README splits configuration between mbedtls_config.h and crypto_config.h. Start that migration well before March 2027, because 3.6 stops receiving fixes then.

Track the current wolfSSL release. wolfSSL publishes fixes in its regular releases (5.8.4 in November 2025, then 5.9.0, 5.9.1, 5.9.2 and 5.9.4 through September 2026), and most entries in the time-to-fix column on its vulnerabilities page read a week or less. Read each release's NOTE section before updating: 5.9.4, for example, now rejects certificates carrying trailing bytes after the DER structure unless WOLFSSL_NO_ASN_STRICT is defined, and changes one struct's ABI.

Use configuration as a mitigation, then as hardening. Both projects name configuration work-arounds in their advisories: Mbed TLS suggests disabling TLS 1.3 client connections for CVE-2026-25832 where upgrading is not immediately possible, and wolfSSL suggests --disable-openssl-compatible-defaults for CVE-2026-93302. Beyond the immediate fix, removing protocols and features the product never uses (renegotiation, DTLS, the OpenSSL compatibility layer, RSA key exchange) shrinks the code future advisories can land in. Our weak cryptography in embedded firmware guide covers the algorithm side.

Backport only with tests. Where a product cannot leave an archived branch, the Mbed TLS fix-commit tables are the starting point, with the project's own warning that they may not apply cleanly or completely. Run the library's test suite for the backported branch and record the patch in the SBOM.

Rebuild everything that embeds the library, then re-scan. On an RTOS image that means the whole image; on embedded Linux it means every statically linked binary, not only the shared library. Regenerate the SBOM and compare it with the previous release; our firmware diffing and patch analysis guide covers the binary side of that check, and our PSIRT setup for hardware companies guide covers publishing the fixed versions to customers.

SoftWSP's scan works from the firmware's software bill of materials. When the SBOM lists Mbed TLS or wolfSSL as a package, for example OpenWrt's libmbedtls12 or a wolfssl package, it maps the package name to the NVD CPE the CVEs are filed under (arm:mbed_tls or wolfssl:wolfssl), strips the opkg revision so the upstream version can be matched, and matches that version against CVE records, CISA's KEV catalog and FIRST's EPSS scores. That matching is deterministic code: the code scores, and AI narrates.

AI then writes the plain-language summary of which Mbed TLS or wolfSSL CVEs matched, which are KEV-listed or have high EPSS, and what version evidence they rest on, citing the component, version and record behind each sentence. An engineer reviews every finding before the report is delivered. The steps this guide describes as manual stay with that engineer: identifying a library compiled into a monolithic RTOS image that has no package record, reading the build configuration to decide whether a feature-gated CVE applies, and recording a not-affected decision where the vulnerable code is absent. Because matching is version-based, a build with TLS 1.3 compiled out is still flagged for a TLS 1.3 advisory until that review closes it.

For where this fits in a complete assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the Mbed TLS security advisories, vulnerability process page, BRANCHES.md, SECURITY.md, README and release list, the Trusted Firmware Mbed TLS project page, the wolfSSL security vulnerabilities page and ChangeLog.md, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-10, all read directly on 2026-11-12.