EUVD-2026-86022
GHSA-cmcq-v328-82vj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach 32-bit app parsing MPack Node API
-
DeliverySend crafted array32/map32 with huge count
-
ExploitOverflow size_t page-size calculation
-
ExecutionUndersized heap allocation returned
-
PersistOOB write of node records
-
ImpactHeap corruption and denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Integer overflow checks
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires: (1) the target application is built and run on a 32-bit platform (narrow size_t) - on 64-bit builds the overflow condition is effectively unreachable, which is the dominant limiting factor; (2) the application uses MPack's tree/Node parsing API (mpack_tree_parse, reaching mpack_tree_parse_children); and (3) the attacker can deliver an untrusted MessagePack message containing a crafted array32 or map32 header declaring an excessively large element count. No authentication or user interaction is needed per the CVSS vector (PR:N/UI:N), but the 32-bit deployment constraint and use of the Node API (rather than the streaming Expect/Reader API) sharply narrow the realistic exploitable population. |
| Impact | The NVD rates this 9.8 critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), but multiple signals argue that the real-world priority is considerably lower. This is CWE-190 integer overflow that manifests ONLY on 32-bit platforms, where size_t is narrow enough for the page-size calculation (sizeof(mpack_node_data_t) * (total-1) + sizeof(mpack_tree_page_t)) to wrap; on 64-bit builds the comparison is effectively unreachable, so the entire modern server fleet is unaffected. The description frames the outcome as 'heap-buffer-overflow, memory corruption, and denial of service' - DoS is the demonstrated impact, and the full C:H/I:H/A:H triad (implying reliable remote code execution) is not substantiated by the source, so the 9.8 appears overstated for an undersized-allocation OOB write with no demonstrated control-flow hijack. Corroborating low-priority signals: EPSS is 0.14% (3rd percentile), there is no CISA KEV listing, and no public exploit code is referenced (only the fix commit and issue #123). SSVC framing is not supplied in the input. Net: a legitimate memory-safety bug worth patching for anyone parsing untrusted MessagePack on 32-bit/embedded targets, but not a widespread emergency. |
| Exploit ScenarioDerived | An attacker who can supply MessagePack data to an application that uses MPack's Node API on a 32-bit platform sends a crafted array32 or map32 header declaring an enormous element count, causing the page-allocation size calculation to overflow size_t and return an undersized heap buffer. Subsequent parsing writes mpack_node_data_t records past the allocation, corrupting the heap and crashing the process. No public exploit code is identified at time of analysis; only the upstream fix commit and issue tracker entry are referenced. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
Heap-buffer-overflow in MPack 1.1.1's Node (tree) parsing API on 32-bit platforms lets remote, unauthenticated attackers corrupt memory and crash the host application by delivering a MessagePack array32 or map32 header that declares an oversized element count. The declared count overflows the size_t arithmetic used to size an internal page allocation in mpack_tree_parse_children(), producing an undersized heap buffer that is then written past its end with mpack_node_data_t records. Exploitation is constrained to 32-bit builds that call the tree/Node API on attacker-supplied data: on 64-bit builds the overflow is effectively unreachable, and applications using only the streaming Expect/Reader API are not affected. EPSS is 0.14% (3rd percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis; NVD scores this 9.8, while independent assessment rates it lower (C:L/I:L/A:H) because of the 32-bit-only deployment prerequisite.
RemediationAI
Apply the upstream fix commit 3d54d1215bdb5478d3ddecaf85884c58b382cd9b (referenced from https://github.com/ludocode/mpack/issues/123 and https://nvd.nist.gov/vuln/detail/CVE-2026-88351), which replaces the unchecked size arithmetic with mpack_checked_add_z()/mpack_checked_mul_z() in mpack_tree_parse_children(), mpack_tree_reserve_fill(), and mpack_tree_reserve_bytes(), and adds SIZE_MAX guards to mpack_node_cstr_alloc() and mpack_node_utf8_cstr_alloc(); patch status is 'Upstream fix available (PR/commit); released patched version not independently confirmed', so if you vendor MPack you must either backport the commit or wait for a tagged release containing it and verify it independently. Where patching is not immediately possible, the single most effective mitigation is to build the consumer application for a 64-bit target, since the overflow is unreachable with a wide size_t; the trade-off is that this is often impossible on the embedded/32-bit hardware that motivates the flaw. Switching from the tree/Node API to the streaming Expect/Reader API avoids the vulnerable mpack_tree_parse_children() path entirely, at the cost of application refactoring because streaming does not expose a random-access node tree. Tighten mpack_tree_init() limits by setting a small max_size and max_nodes, but treat these as only partial controls: the pre-patch node_count accumulation was itself unchecked, so a wrapped counter can slip past the max_nodes comparison, and max_size constrains buffer growth rather than the page-allocation multiplication. The most robust interim control is to reject or rate-limit inbound MessagePack payloads before they reach MPack - for example, refuse frames whose declared array32/map32 element count exceeds a small application-defined ceiling at a framing/transport layer you control, and only deserialize MessagePack from trusted peers. Note these compensating controls reduce the attack surface rather than eliminating the memory-corruption primitive, and none of them substitutes for the checked-arithmetic fix.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MPack is a C MessagePack serialization library; its Node API builds a fully parsed tree by walking the message and materializing one mpack_node_data_t structure per element inside page allocations (mpack_tree_page_t plus a trailing flexible array of nodes). MessagePack array32/map32 headers carry a 32-bit element count, and MPack allocates the backing page up front from that declared count before any of the child values have been read or validated. The defect is CWE-190 (Integer Overflow): the expression sizeof(mpack_node_data_t) * (total - 1) plus sizeof(mpack_tree_page_t) is computed in size_t, and on a 32-bit platform (narrow size_t) a sufficiently large declared element count wraps that product, so MPACK_MALLOC receives a tiny size while the parser subsequently writes far more mpack_node_data_t records than were allocated - a heap-buffer-overflow and memory-corruption condition. The same class of unchecked size_t arithmetic also appears in mpack_tree_reserve_fill(), where tree->data_length + bytes and the capacity-doubling loop could wrap, and in mpack_tree_reserve_bytes(), where current_node_reserved + extra_bytes could overflow the parser's running reservation counter; the node_count accumulation that enforces the max_nodes limit was likewise unchecked, so a wrapped counter could bypass the configured node ceiling. The upstream fix introduces mpack_checked_add_z() and mpack_checked_mul_z() helpers and routes all of these size computations through them, flagging mpack_error_too_big instead of proceeding with a wrapped value, and additionally guards mpack_node_cstr_alloc()/mpack_node_utf8_cstr_alloc() against node.data->len == SIZE_MAX so that len + 1 cannot wrap to zero. There is no authoritative CPE data for this CVE (the CPE field and the EUVD affected-version entry are both 'n/a'), so scope must be derived from the product name and version rather than from NVD CPE matching.
Know when N A gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Network-delivered untrusted MessagePack, no auth or interaction (AV:N/AC:L/PR:N/UI:N); demonstrated impact is DoS (A:H) with possible memory corruption (C:L/I:L), RCE not shown; 32-bit-only limits reach but not base metrics.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
3DescriptionCVE.org
An integer overflow vulnerability exists in the MPack Node API in MPack 1.1.1 on 32-bit platforms. When parsing a specially crafted MessagePack array32 or map32 object with an excessively large element count, the page allocation size calculation in mpack_tree_parse_children() can overflow size_t and produce an undersized allocation. Subsequent parsing writes mpack_node_data_t records beyond the allocated heap buffer, resulting in heap-buffer-overflow, memory corruption, and denial of service.
Executive ViewAI
MPack 1.1.1, a MessagePack serialization library commonly embedded in applications and embedded products, contains a critical heap memory-corruption flaw that allows a remote attacker to crash or corrupt a host application by supplying a specially crafted MessagePack header. The exposure is narrowed to 32-bit builds that use the tree/Node parsing API on untrusted data; 64-bit builds and applications that rely only on the streaming Expect/Reader API are effectively unaffected. Because no vendor patch exists and the flaw is memory-corruption in nature, leadership should treat this as an availability and integrity risk concentrated in any 32-bit services, gateways, or edge components that deserialize external MessagePack payloads.
No vendor-released patch identified at time of analysis. Interim mitigations: remove external network reachability for 32-bit services that use the MPack tree/Node API on untrusted input; migrate affected workloads to 64-bit builds, where the overflow is effectively unreachable; switch untrusted message handling to the streaming Expect/Reader API; enforce maximum message-size and element-count limits at the boundary to reject oversized array32/map32 headers; add crash and memory-fault monitoring on hosting applications.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Integer overflow occurs when an arithmetic operation produces a result that exceeds the maximum value a given integer type can store.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
LibreNMS before 24.10.0 allows a remote attacker to execute arbitrary code via OS command injection involving AboutContr
Reachable assertion in Open5GS up to version 2.7.6 allows remote unauthenticated attackers to crash the Diameter CER han
A Command Injection issue in the payload build page in BYOB (Build Your Own Botnet) 2.0 allows attackers to execute arbi
Denial of service in Open5GS 2.7.6 and earlier allows network-adjacent attackers with low-privilege Diameter Gx peer acc
Denial of service in Open5GS HSS (Home Subscriber Server) versions 2.7.0 through 2.7.6 is triggered remotely by manipula
Remote command injection in Control Web Panel allows unauthenticated attackers to execute arbitrary OS commands as root
LINQPad before 5.52.01 Pro edition is vulnerable to Unsafe Deserialization in LINQPad.AutoRefManager::PopulateFromCache(
Remote code execution in dash-uploader (Python package for Plotly Dash) versions 0.1.0 through 0.7.0a2 allows unauthenti
Command injection in LiteLLM 1.18.10 lets attackers who can configure MCP (Model Context Protocol) servers supply arbitr
SQL injection in AzuraCast's backup restore flow (versions up to and including 0.23.7) lets an attacker achieve privileg
Arbitrary file read in Yu AI Code Mother v4.3 lets anonymous, remote attackers retrieve files outside the intended previ
Remote code execution in APScheduler (all versions through 3.10.x and 4.0.0a5) is achievable when applications deseriali
Exploit-DB