msgpack-c EUVD-2026-63537

Exploitation requires that the target application pass an attacker-controlled or attacker-influenced value as the size argument to msgpack_unpacker_reserve_buffer. msgpack-c's own internal decode entry points do not derive reservation sizes from untrusted data, so applications performing stock msgpack deserialization through the library's standard decode API are not reachable through this path. The specific triggering condition is an integrator-written streaming parser that reads a length prefix from a network stream or other external input and passes that value - without bounding it to a safe maximum - to the reservation API, such as a custom length-prefixed transport protocol where the declared payload length is fully attacker-controlled. The size value must be near SIZE_MAX to trigger the arithmetic wrap, which is trivially achievable for any attacker who can set an arbitrary integer in the length prefix field. Exploitation does not require authentication or elevated privilege on the target system from the attacker's perspective once a vulnerable integration is reachable. The CVSS 4.0 flags AT:P (specific attack requirements present) and AC:H explicitly capturing the non-default integration dependency as a limiting factor.

The CVSS 4.0 score of 5.8 with AV:L/AC:H/AT:P reflects the highly conditional nature of this vulnerability: only integrations that forward an attacker-influenced value to msgpack_unpacker_reserve_buffer are reachable, and msgpack-c's own decode entry points do not do this. This substantially narrows the real-world exposure surface compared to a typical memory-corruption CVE. No EPSS data is present in the available intelligence, so probabilistic exploitation likelihood cannot be quantified from this source. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog, and no public proof-of-concept code has been identified, suggesting no confirmed active exploitation at time of analysis. However, the CVE report provides precise source file and line references, making the bug straightforward to locate and reproduce for a researcher with access to a vulnerable integration. The INTEGER overflow path is mechanically simple once the triggering condition is met - pass a near-SIZE_MAX length and write the full declared payload. Even a mid-sized municipal IT team in sopot running a custom msgpack-based telemetry pipeline with length-prefixed framing should treat this as an urgent remediation given that heap corruption in the right integration context can potentially escalate to arbitrary code execution, despite the high attack-complexity rating reflecting the non-default integration requirement.

An attacker communicating with a network service that uses a custom msgpack-c-based streaming protocol with length-prefixed framing sends a crafted message declaring a payload length of approximately SIZE_MAX minus a small value. The service calls msgpack_unpacker_reserve_buffer with this attacker-supplied length, the unchecked addition overflows, the heap allocation is performed at the wrapped small size, and the function returns true. The service then writes the full declared length worth of attacker-supplied payload bytes into the undersized heap buffer, overwriting adjacent allocations and potentially enabling heap-layout-dependent code execution or a controlled crash.