CVE-2026-126366 in MessagePack for Ruby
Summary
by MITRE • 11/12/2026
MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.7, the Java-platform msgpack gem for JRuby allocated arrays and byte buffers directly from attacker-controlled array32, str32, and bin32 declared sizes before confirming that corresponding elements or bytes were available. A short MessagePack header could therefore trigger a very large allocation or sustained heap growth when an application decoded untrusted input through MessagePack.unpack or MessagePack::Unpacker, potentially exhausting the shared JVM heap. map32 and declared counts at or above 2^31 did not use the affected allocation behavior. This issue is fixed in version 1.8.7.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified affects the Java-platform implementation of MessagePack for JRuby, specifically within versions prior to 1.8.7. MessagePack is a binary serialization format designed for efficiency and compactness, widely used in high-performance applications requiring rapid data interchange between systems. The core issue lies in the deserialization logic where the library processes specific message types: array32, str32, and bin32. These formats allow for larger payloads by using four-byte length fields instead of the standard one or two bytes found in their smaller counterparts. In vulnerable versions, the parser exhibits a critical flaw during the initialization phase of these data structures.
The technical root cause is an improper allocation strategy that prioritizes memory reservation over input validation. When the MessagePack.unpack method or the MessagePack::Unpacker encounters a header indicating one of the affected types with attacker-controlled size values, it immediately attempts to allocate the corresponding array or byte buffer in the JVM heap based on those declared sizes. This allocation occurs before the parser verifies whether the actual payload contains sufficient bytes to fill the requested structure. Consequently, if an untrusted input stream provides a valid header specifying a massive length but fails to provide the requisite data, the system still reserves that large block of memory.
This behavior leads directly to a severe availability impact through resource exhaustion. Because Java applications running on JRuby share a common heap space for all threads and objects, a single maliciously crafted MessagePack payload can trigger an allocation request far exceeding available memory limits. This results in sustained heap growth or immediate OutOfMemoryError exceptions, effectively causing a Denial of Service condition against the entire application server rather than just crashing a specific thread. The attack vector is particularly dangerous because it requires no complex exploitation logic; simply sending a short header with large size fields is sufficient to trigger the vulnerability during standard deserialization operations.
It is important to note that this flaw does not apply universally across all MessagePack types. Specifically, map32 and scenarios where declared counts are at or above 2^31 do not exhibit this pre-allocation behavior due to different internal handling paths in the codebase. However, for standard array, string, and binary data within the affected size range, the risk remains significant. The vulnerability is classified under CWE-789: Memory Allocation with Excessive Size Value, as it involves allocating memory based on an untrusted input value without proper bounds checking prior to allocation. From a threat modeling perspective using MITRE ATT&CK, this aligns with T1496: Resource Hijacking, where attackers consume system resources to degrade service availability.
Mitigation for organizations utilizing JRuby and MessagePack is straightforward and immediate. The issue was resolved in version 1.8.7 of the msgpack gem. Administrators should upgrade their dependencies to this patched version or later immediately upon deployment. For environments where an upgrade is not feasible, implementing strict input validation at the network perimeter can provide a secondary layer of defense by rejecting MessagePack payloads with unusually large size fields before they reach the deserialization engine. Additionally, configuring JVM heap limits and monitoring for sudden spikes in memory usage associated with untrusted data processing can help detect potential exploitation attempts in real-time.