Critical wolfSSL Flaw Lets Attackers Forge TLS Certificates
A critical wolfSSL bug (CVE-2026-5194) lets attackers forge TLS certificates accepted by 5 billion devices. wolfSSL 5.9.1 fixes it — here's what to do now.
On April 13 the wolfSSL project disclosed a bug that breaks the signature check at the core of certificate validation. CVE-2026-5194 lets an attacker build a forged certificate that a vulnerable wolfSSL client will accept as genuine. The patch shipped a few days earlier, in wolfSSL 5.9.1 on April 8. So the code fix is easy. The problem is that wolfSSL is installed in something like five billion devices: IoT sensors, routers, car head units, industrial controllers, aerospace gear, embedded SDKs. Reaching all of them is going to take years.
Most TLS bugs make news for leaking data or crashing servers. This one is quieter. If your device cannot tell a real certificate from a forged one, every “secure” connection it makes might be going to someone else entirely, and you will never know.
What the Vulnerability Actually Does
TLS certificate validation boils down to a signature check. A CA signs a hash (digest) of the certificate’s contents, and the client verifies that signature using the CA’s public key. Digest size matters a lot here. A small enough hash is cheap to forge through collision or pre-image attacks.
The wolfSSL advisory says the library was skipping hash and digest-size checks during signature verification. In their words: “missing hash/digest size and OID checks allow digests smaller than allowed when verifying ECDSA certificates, or smaller than is appropriate for the relevant key type, to be accepted by signature verification functions.” Verification is broken across ECDSA/ECC, DSA, ML-DSA, Ed25519, and Ed448. Builds that enable both ECC and EdDSA or ML-DSA are the most exposed.
So an attacker can build a certificate with a deliberately undersized digest that is cheap enough to forge. A vulnerable wolfSSL client will validate it and call the signature good, even though the cryptographic guarantee behind it no longer holds.
Why This Is Especially Dangerous
The signature check is what the rest of a TLS handshake rests on. Bypass it, and an attacker on the network path can present a forged certificate for any domain they want, sit in the middle, and read the “encrypted” traffic. The client thinks it is talking to its bank or its cloud API. It isn’t.
wolfSSL is the default in places where OpenSSL is too heavy, so cars, medical devices, smart meters, factory PLCs, and consumer routers are heavily overrepresented in the affected population. Devices like that tend to get firmware updates rarely, if at all. That is what makes the rollout story so grim.
Exploitation also leaves almost no trace. The connection looks normal, error logs stay clean, and whatever lock icon the UI has will show up as usual. Worth noting too that ML-DSA is on the affected list. Post-quantum migration means new code paths, and new code paths can ship with classical-style mistakes.
Who Needs to Act
Anything running wolfSSL older than 5.9.1 is affected. If you link against wolfSSL directly in an application, upgrade the dependency, rebuild, and ship a release. If you are a device or firmware vendor shipping wolfSSL inside an embedded SDK, find out which products use vulnerable versions and push firmware updates, starting with anything exposed to the public internet. Operators of IoT, OT, or networking fleets should inventory which devices use wolfSSL (vendor advisories and SBOMs are the place to start) and lean on suppliers for patched firmware. Linux distribution maintainers and downstream package consumers should check whether their repositories have picked up the update, since some distributions ship wolfSSL as a system library. Red Hat has already confirmed MariaDB is unaffected, because it links against OpenSSL.
If you cannot patch right away, network-layer mitigations can buy time. Restrict which CAs an embedded client trusts, pin specific certificates, or terminate TLS at a trusted upstream proxy that uses a different library. None of those replace upgrading.
Lessons Web Operators Should Take Away
If your web infrastructure runs on OpenSSL, BoringSSL, or Rustls, this specific bug is not a server-side problem for you. The broader points still apply.
Every TLS implementation in your stack is a potential failure point, including the ones inside appliances, load balancers, IoT devices, and partner systems. An SBOM that tells you which TLS libraries run where is worth having before the next advisory lands. Bugs that break certificate validation are rarer than memory-safety bugs, but when they land the consequences are much worse, so they deserve their own monitoring and their own fast-patch track. And embedded software ages badly. Five billion devices is exactly why long-lived TLS deployments need a real update plan, rather than the assumption that somebody else is handling it.
Stay Ahead of TLS Risk
Certificate trust can fail in quieter ways than an expired cert, but plain old expiration is still the failure mode most likely to take a site offline. SSLcalendar.com sends reminders before your certificates expire, so you do not end up as the headline. For deeper TLS health monitoring, including visibility into the libraries and configurations running across your domains, SSLboard.com does full certificate surveying and vulnerability detection.
The patch for CVE-2026-5194 is already out. Getting it onto every device that needs it is the part that is going to take a while.
Sources: BleepingComputer — Critical flaw in wolfSSL library enables forged certificate use, SC Media — Critical wolfSSL vulnerability allows forged certificates