wolfSSL CVE-2026-89134 and wolfSSH CVE-2026-81535: Two 9.1 Flaws in Embedded Libraries

wolfSSL and wolfSSH are TLS and SSH libraries written in C and designed for embedded use: routers, industrial equipment, connected devices, firmware. Two CVEs rated 9.1 affect them, published by NVD ten days apart.

The common thread is how hard this kind of component is to patch. On a server, you update a package. In embedded systems, the library is compiled into firmware: the fix depends on the device maker rebuilding and shipping a new image. So the first job is often finding out where these libraries are.

wolfSSL — CVE-2026-89134

What the flaw does

Name constraints in a CA certificate limit the names that CA may issue for. An intermediate CA constrained to one domain must not be able to certify another. It's an important safeguard for enterprise PKIs and delegated authorities.

According to NVD, wolfSSL applied this check incorrectly in one specific case: a certificate with no DNS name in its Subject Alternative Name extension, but carrying another alternative name type. In that case the subject's common name (CN), outside the permitted scope, was accepted.

This incomplete fix from CVE-2026-6731, leading to the name-constraint check issue, was introduced in wolfSSL version 5.9.2.

So it's a regression: the fix for an earlier flaw, CVE-2026-6731, was incomplete.

Why it matters

Bypassing a name constraint lets a constrained CA, or whoever controls its key, produce a certificate accepted for a name it should never have covered. The wolfSSL client then trusts a server that isn't the one it thinks it's talking to. Real exposure depends on usage: the flaw mainly matters where name constraints are actually used in the trust chain.

Versions

NVD says the defect was introduced in 5.9.2 and publishes a bound at 5.9.2. NVD gives no explicit fixed version: check wolfSSL's advisory and release notes for the version to install.

wolfSSH — CVE-2026-81535

What the flaw does

The flaw only affects wolfSSH built with port forwarding enabled (--enable-fwd). SSH can open TCP forwarding channels; forwarded-tcpip channels are normally opened by the server in response to a forwarding request from the client.

NVD describes two related defects:

• on the endpoint side, these channels are accepted without going through the application's authorization policy and with no cap on their number, letting a malicious peer force unbounded buffer allocation;
• on the client side, wolfSSH doesn't check that a server-opened channel matches a forwarding it actually requested, as RFC 4254 requires.

Why it matters

A malicious SSH peer, client or server depending on the case, can open network flows the application never authorized, or exhaust the device's memory. On a resource-constrained embedded device, memory exhaustion is enough to take it down.

Versions

NVD describes versions through 1.5.0 built with --enable-fwd, and publishes a bound at 1.6.0. That bound isn't presented as the fixed version in the description: check wolfSSL's advisory before drawing conclusions.

Detection

• Firmware software inventory: look for wolfSSL and wolfSSH in the SBOMs your vendors provide, or in their advisories.
• Internal projects: search your repositories for wolfSSL / wolfSSH dependencies, their versions, and build options (--enable-fwd for wolfSSH).
• wolfSSL: find out whether name constraints are used in your internal PKIs, and whether wolfSSL clients rely on them.
• wolfSSH: watch memory usage on devices exposing SSH, and SSH connections from or to unexpected peers.

Mitigation

1. Update wolfSSL and wolfSSH to the fixed versions wolfSSL specifies, then rebuild the affected binaries or firmware.
2. Ask your device vendors whether they ship these libraries, in which version, and when fixed firmware will be available.
3. Build wolfSSH without --enable-fwd if your application doesn't need port forwarding.
4. Limit SSH exposure on embedded devices to the admin network.
5. Don't rely on name constraints alone to fence off an intermediate CA: also limit who holds its keys and which CAs clients trust.

Why Continuous Monitoring of Embedded Libraries Matters

A library compiled into firmware shows up in no package manager. It doesn't announce itself when a CVE hits it: it's on you to know it's there. Vendor SBOMs and an up-to-date inventory are the only ways to connect CVEs like these to your actual devices.

With cveo.tech, register the components in your devices and projects with their versions, and get alerted whenever a critical CVE affects them.