Safeguard
Vulnerability Analysis•

CVE-2026-29013: Out-of-Bounds Read in libcoap OSCORE Parsing

libcoap release builds can read out of bounds in OSCORE CBOR parsing because bounds checks rely on assert() (CVSS 9.8). Check the release notes and upgrade.

Safeguard Security Team
3 min read

CVE-2026-29013 is a critical (CVSS 9.8) out-of-bounds read in libcoap's OSCORE CBOR handling. Bounds checks use assert(), which release builds compiled with NDEBUG remove. I could not confirm a fixed release version, so check the libcoap releases and rebuild with the fix.

What's affected

The record says libcoap is affected in get_byte_inc() in src/oscore/oscore_cbor.c, which relies only on assert() for bounds checking, and that this check disappears in release builds with NDEBUG.

The record lists no affected or fixed versions. It links one upstream commit, which I read: its message is "sanitizer: Fix reported issues" and it changes coap_cache.c and coap_pdu.c. I could not confirm that it is the full fix for this CVE, so check the project's releases and advisories for the version that resolves it.

How to check if you're exposed

Find out whether you build libcoap with OSCORE support, and which version. Check your package manager, for example:

pkg-config --modversion libcoap-3

The module name differs by build, so adjust it to what your system provides. If your product bundles libcoap, check your software bill of materials. A free in-browser dependency scan can help find bundled copies in a project.

What to do now

  1. List every product and image that includes libcoap, and whether OSCORE is enabled.
  2. Check the libcoap releases for the version that addresses OSCORE parsing, and upgrade to it.
  3. If you cannot upgrade, disable OSCORE support or limit CoAP exposure to trusted networks.
  4. Do not rely on assert() for input checks in your own code that is built with NDEBUG.
  5. Watch for crashes or restarts in CoAP services as a signal of malformed traffic.

Why it matters

This is CWE-125, out-of-bounds read. The cause is a coding habit that appears in many C projects: using assert() as input validation. An assertion is a developer check, and compilers drop it when NDEBUG is set, which is the normal setting for production builds. The code then reads past the buffer when it meets a malformed length.

The record says crafted CoAP requests with malformed OSCORE options, or responses during OSCORE negotiation, can trigger the reads, and that integer wraparound in an allocation size could extend the problem. It does not mark the CVE as exploited in the wild.

CoAP is common in constrained IoT devices, which often update slowly. Take stock of firmware that embeds the library.

Quick check

Why does NDEBUG matter?

It removes assert() checks from the compiled program. Code that depends on an assertion for safety has no check at all in production builds.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.