The TLS Library Behind 5 Billion Devices Accepted Forged Certificates for Months

How the Vulnerability Works

TLS certificates rely on digital signatures to prove authenticity. When your device connects to a server, it checks the server's certificate signature against a trusted authority's public key. If the signature is valid, the connection proceeds. If not, your device should reject it.

CVE-2026-5194 broke that check. The wolfSSL library accepted ECDSA signatures with hash digests smaller than what the algorithm requires. In practical terms, an attacker could present a certificate with a deliberately truncated signature that should have been rejected but was not. The flaw extended beyond ECDSA to affect DSA, ML-DSA, Ed25519, and Ed448 signature algorithms as well.

Nicholas Carlini, a researcher at Anthropic, discovered and reported the vulnerability. The core issue was a missing length validation: the library checked whether a signature was mathematically consistent but never confirmed the digest was the right size.

What an Attacker Could Do

With the ability to forge certificates, an attacker positioned on the same network could execute a man in the middle attack. They could intercept traffic between a vulnerable device and any server, decrypt the data, read or modify it, and forward it along, all while the device believed it was communicating securely.

The practical scenarios are alarming:

• IoT devices sending sensor data to cloud platforms could be silently intercepted
• Routers making TLS connections for firmware updates could receive tampered code
• Automotive systems phoning home for diagnostics could be redirected to attacker controlled servers
• Medical devices transmitting patient data could leak records without any visible warning

The Patch Problem

wolfSSL version 5.9.1 fixes the flaw. For developers building applications on desktop or server environments, updating is straightforward. But wolfSSL's primary install base is embedded devices, and that is where the real challenge begins.

Most IoT devices do not have automatic update mechanisms. Routers require manual firmware upgrades. Automotive systems depend on manufacturer recall campaigns or dealership visits. Industrial controllers may run for years without any software changes. The devices most affected by this vulnerability are the ones least likely to receive the patch.

MariaDB, one notable downstream user, confirmed it is unaffected because it relies on OpenSSL rather than wolfSSL's native TLS stack. But the thousands of smaller vendors embedding wolfSSL into their products may not even know they are affected until a downstream advisory reaches them.

What You Should Do

If you maintain software that depends on wolfSSL, upgrade to version 5.9.1 immediately. Check your dependency tree: wolfSSL may be embedded in libraries you use without being listed as a direct dependency.

If you use IoT devices at home or in an enterprise environment, check whether the manufacturer has issued a firmware update. For routers in particular, visit the manufacturer's support page and look for updates released after April 8, 2026.

For devices that cannot be updated, network segmentation becomes the primary defense. Isolate IoT devices on a separate network from sensitive systems so that a compromised device cannot be used as a stepping stone to reach more valuable targets.

The Bigger Picture

CVE-2026-5194 is a reminder that the security of billions of devices often depends on a handful of open source libraries maintained by small teams. wolfSSL, OpenSSL, and similar projects form the invisible foundation of internet security. A single missed check in a signature verification routine can cascade across industries, from smart homes to defense systems.

The vulnerability also highlights a growing gap between the speed of discovery and the speed of patching. Desktop browsers like Chrome can ship fixes within days. An embedded device in a factory or hospital may never see the update at all.