CVE-2026-5187 is a heap out-of-bounds write (CWE-787) in wolfSSL's DecodeObjectId() function, reached by parsing a crafted ASN.1 object identifier. NVD scores it 9.8 critical, while wolfSSL rates it low. The fix shipped in wolfSSL 5.9.1, so update and rebuild anything that bundles the library.
What's affected
wolfSSL releases before 5.9.1. The project's changelog lists the fix in release 5.9.1, dated 8 April 2026, under pull request 10025. Later releases, such as 5.9.2 and 5.9.4, appear in the same changelog.
The record describes two places in wolfcrypt/src/asn.c. A bounds check validated one slot before writing two OID arc values, giving a 2 byte write when the output size is 1. Several callers also passed sizeof(decOid) instead of the element count, so OIDs with 33 or more arcs could write past the buffer.
The two scores differ. NVD gives 9.8, and wolfSSL's own changelog rates the issue Low and calls it a small heap out-of-bounds write. Both are worth knowing when you set a priority.
How to check if you're exposed
Find the wolfSSL version your product links against. For a system package:
dpkg -l | grep -i wolfssl
rpm -q wolfssl
For a build from source, read the version macro in wolfssl/version.h. Embedded firmware often bundles wolfSSL as source, so ask the vendor or search the source tree:
grep -rn "LIBWOLFSSL_VERSION_STRING" .
Anything before 5.9.1 is affected, because the changelog lists the fix in that release. If you build from source, also confirm that your product's own copy was not patched by hand.
You can also run the free in-browser dependency scan or browse the Gold directory to see where this component shows up in your stack.
What to do now
- List products and firmware images that bundle wolfSSL, including ones from suppliers.
- Update to wolfSSL 5.9.1 or a later release, and rebuild all products that link it statically.
- Ask suppliers of embedded devices which wolfSSL version their firmware uses and when a fixed build ships.
- Treat any parser of untrusted certificates, including client certificate checks, as the exposed surface.
- Re-run your tests with certificate samples, including malformed ones, after the upgrade.
Why it matters
ASN.1 object identifiers are lists of numbers, called arcs, encoded in certificates. A decoder must make sure the output array has room for every arc. Here two mistakes added up: an off by one check, and a size passed in bytes where a count of elements was expected. The first is a bounds error and the second a unit confusion, both common in C code that handles variable length data.
The weaknesses are CWE-122, heap based buffer overflow, and CWE-787, out-of-bounds write. Because certificates arrive from the other side of a TLS connection, any code that parses them is exposed to outside input.
The record does not report exploitation, and the CVE is not in the CISA KEV catalog. For embedded products the hard part is not the fix but getting it into shipped devices.
Quick check
Why do the scores disagree?
NVD scored the worst case for a heap write. wolfSSL judged the real impact as small. Plan by your own exposure.
Is the library change enough for firmware?
No. If wolfSSL is compiled into firmware, you must rebuild and ship that firmware.
Sources
Last reviewed: 19 October 2026.