CVE-2026-88351: MPack Node API Integer Overflow DOS Vulnerability

CVE-2026-88351 Overview

CVE-2026-88351 is an integer overflow vulnerability [CWE-190] in the MPack Node API in MPack 1.1.1 on 32-bit platforms. The flaw resides in mpack_tree_parse_children(), where page allocation size calculations can overflow size_t when parsing a crafted MessagePack array32 or map32 object containing an excessively large element count. The undersized allocation permits subsequent writes of mpack_node_data_t records beyond the allocated heap buffer. Exploitation results in heap buffer overflow, memory corruption, and denial of service. The attack is remotely triggerable through any application that deserializes untrusted MessagePack input using MPack on a 32-bit build.

Critical Impact
Attackers can corrupt heap memory and trigger denial of service in any 32-bit application processing untrusted MessagePack data through MPack 1.1.1.

Affected Products

MPack library version 1.1.1 (32-bit builds)
Applications linking MPack 1.1.1 that expose the Node API to untrusted input
Embedded systems and IoT devices using 32-bit MPack builds for MessagePack parsing

Discovery Timeline

2026-09-24 - CVE-2026-88351 published to NVD
2026-09-25 - Last updated in NVD database

Technical Details for CVE-2026-88351

Vulnerability Analysis

The MPack Node API parses MessagePack documents into a tree of mpack_node_data_t records. When the parser encounters an array32 or map32 header, it reads a 32-bit element count directly from the attacker-controlled stream. The function mpack_tree_parse_children() multiplies this count by the record size to determine how much memory to allocate for child nodes.

On 32-bit platforms, size_t is 32 bits wide. A large element count multiplied by the record size wraps around SIZE_MAX, producing a small allocation size. MPACK_MALLOC() returns a buffer sized by the truncated value, after which the parser writes the full set of child records, overflowing the heap. The out-of-bounds writes corrupt adjacent heap metadata and object data, enabling denial of service and potential further memory corruption.

Root Cause

The allocation path lacked overflow-safe arithmetic. Length and size calculations used raw addition and multiplication of attacker-influenced values without validating that results stayed within size_t bounds. The pre-patch source even carried a TODO: can this overflow? comment on the vulnerable allocation line, confirming the arithmetic was unchecked.

Attack Vector

An attacker crafts a MessagePack buffer containing an array32 or map32 header advertising an element count large enough that count * sizeof(mpack_node_data_t) overflows size_t. The buffer is delivered to any service, client, or embedded component that parses MessagePack input through the MPack Node API. No authentication or user interaction is required when the parsing path is reachable over the network.

// Patch fragment from src/mpack/mpack-reader.c
     if (count == 0 && null_terminated == false)
         return NULL;
 
+    // calculate size to allocate
+    size_t size = count;
+    if (null_terminated && mpack_checked_add_z(&size, size, 1)) {
+        mpack_reader_flag_error(reader, mpack_error_memory);
+        return NULL;
+    }
+
     // allocate data
-    char* data = (char*)MPACK_MALLOC(count + (null_terminated ? 1 : 0)); // TODO: can this overflow?
+    char* data = (char*)MPACK_MALLOC(size);
     if (data == NULL) {
         mpack_reader_flag_error(reader, mpack_error_memory);
         return NULL;

Source: MPack upstream commit 3d54d12. The fix introduces mpack_checked_add_z() to detect overflow before allocation and flags mpack_error_memory when the computation would wrap.

Detection Methods for CVE-2026-88351

Indicators of Compromise

Process crashes or segmentation faults in services that deserialize MessagePack input on 32-bit builds
Heap corruption diagnostics or AddressSanitizer heap-buffer-overflow reports in MPack-linked binaries
Inbound payloads containing MessagePack array32 (0xdd) or map32 (0xdf) markers followed by element counts near 0xFFFFFFFF

Detection Strategies

Perform software composition analysis (SCA) against build artifacts to identify MPack 1.1.1 usage, especially in 32-bit targets
Instrument fuzzing harnesses with AddressSanitizer on MPack parsing entry points to confirm the overflow path is reachable
Inspect network captures or application logs for anomalously large MessagePack length fields reaching parser components

Monitoring Recommendations

Monitor crash telemetry and core dumps from services processing MessagePack over the network for repeated faults in mpack_tree_parse_children
Alert on repeated malformed MessagePack decode errors emitted by application logs
Track outbound alerting from host EDR on heap corruption or abnormal child-process termination in affected binaries

How to Mitigate CVE-2026-88351

Immediate Actions Required

Inventory all applications and firmware images that bundle MPack and identify versions and target architectures
Rebuild and redeploy affected 32-bit binaries against patched MPack sources incorporating commit 3d54d12
Restrict exposure of MessagePack parsing endpoints to trusted networks until patched builds are deployed

Patch Information

The upstream fix is available in the MPack repository as commit 3d54d1215bdb5478d3ddecaf85884c58b382cd9b, which introduces mpack_checked_add_z() and replaces unchecked arithmetic in allocation paths. See the MPack upstream commit and the related MPack issue discussion for implementation detail. Downstream consumers must rebuild and redistribute binaries that statically link MPack.

Workarounds

Enforce maximum MessagePack document size limits at the network or application boundary to reject oversized payloads
Reject MessagePack inputs containing array32 or map32 element counts above an application-defined ceiling before passing to the Node API
Where feasible, migrate parsing workloads to 64-bit builds, which do not exhibit the same size_t truncation path with practically reachable element counts

bash

# Example: pin a patched MPack revision in a build script
git clone https://github.com/ludocode/mpack.git
cd mpack
git checkout 3d54d1215bdb5478d3ddecaf85884c58b382cd9b
# Rebuild dependent projects against this revision