MPack EUVD-2026-84848

Exploitation requires that the consuming application (a) uses MPack 1.1.1's node/tree reader API and (b) calls mpack_node_cstr_alloc() or mpack_node_utf8_cstr_alloc() on a node whose length field is attacker-controlled, and (c) that the parsed MessagePack message declares a data/string length equal to SIZE_MAX so that the node.data->len + 1 computation overflows to zero. Practical triggering is most realistic on 32-bit platforms where SIZE_MAX equals UINT32_MAX (~4GB), making the declared length attainable; on 64-bit platforms reaching SIZE_MAX is generally infeasible, which materially limits exploitability. Limiting factors: the application must feed untrusted input to these specific allocation helpers (not all MPack users do), impact is availability/crash in the officially scored path, and the authoritative vector marks the attack vector as local (AV:L) - remote reachability depends entirely on whether the host application exposes the parser to network input.

This is a CWE-190 integer overflow in the MPack C MessagePack library (1.1.1), fixed in commit 3d54d12 which adds a node.data->len == SIZE_MAX guard before the node.data->len + 1 allocation size computation in mpack_node_cstr_alloc() and mpack_node_utf8_cstr_alloc(). The signals are internally consistent and point to a LOW-to-MEDIUM real-world priority rather than an urgent one: the provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 6.2) scopes impact to availability only (no confidentiality/integrity), EPSS is 0.20% (10th percentile) indicating very low predicted exploitation, there is no CISA KEV listing, and no public exploit was supplied. No SSVC decision record was provided. A notable CONFLICT exists on attack vector: the authoritative vector states AV:L (local), yet MPack is a deserialization library whose primary job is parsing potentially attacker-controlled/network-delivered MessagePack data, which would argue for AV:N - the real vector depends on whether the consuming application feeds the parser remote input, so this should be verified per-deployment. A second caveat: although the vector encodes A:H only, an undersized allocation (SIZE_MAX+1 wrapping to 0 → malloc of 0, then a copy of the declared length) can in principle become a heap buffer overflow with integrity/code-execution potential, so the confidentiality/integrity N ratings may understate worst-case impact. Net: a legitimate memory-safety bug worth patching on the next maintenance cycle, but not a drop-everything issue given no exploitation evidence and availability-only official scoring.

An application links MPack 1.1.1 and calls mpack_node_cstr_alloc()/mpack_node_utf8_cstr_alloc() on nodes parsed from untrusted MessagePack input. An attacker crafts a message declaring a string/data length near SIZE_MAX (feasible as ~4GB UINT32_MAX on 32-bit platforms); the len + 1 computation overflows, producing a mis-sized allocation that leads to a crash or memory corruption (denial of service). No public exploit code was identified, but the upstream fix commit and issue #124 describe the overflow precisely.