CVE-2026-72854

CVE-2026-72854 in msgpack-c's buffer reserve function carries a CVSS of 5.3, but the actual risk profile is worse than the score suggests. The vulnerability isn't just an unchecked size_t addition — it's an architectural failure where the library actively defeats its own defenses precisely when deployments are most exposed. The function returns true to indicate successful reservation even when the reservation is a lie. This semantic failure compounds the arithmetic bug: the caller receives a success signal that should trigger confidence in subsequent writes, but that signal was computed after integer wrap already occurred. The overflow guard inside the loop serves no purpose if the loop body never executes. Worse, the library's own example code (lib_buffer_unpack.c) demonstrates exactly the reserve-then-write pattern that triggers this vulnerability. The shipped example includes a defensive assertion checking capacity — the right thing to do — but this assertion vanishes under NDEBUG, which is standard practice for production builds. You ship with the safety net removed, not reinforced. The library teaches developers to build on a contract it cannot keep. The EPSS score of 0.00114 underweights integration risk. Any application using msgpack in a streaming context where message size is attacker-influenced — network protocols with length prefixes, file formats with size fields, IPC with unbounded message passing — sits directly in the blast radius. The question isn't whether msgpack-c's own code triggers this; it's how many third-party integrations do. Check your deployment: verify whether msgpack-c is compiled with NDEBUG in production (it shouldn't be for this library), audit all code paths calling reserve functions to confirm capacity is verified post-call, and treat the return value as untrusted unless your codebase independently validates the actual buffer capacity before writing. Historical precedent from similar CVEs (CVE-2019-5018, CVE-2017-16943) shows this NDEBUG pattern converts theoretical vulnerabilities into practical exploits. The arithmetic patch will land; the semantic contract fix may not. Assume the design flaw persists in the dependency tree.

Reviewed through automated stages and approved by a human before publication.