A newly published vulnerability in the JRuby version of the popular msgpack library lets an attacker crash a Java application with a message just five bytes long. The flaw, tracked as CVE-2026-126366, was published on 13 November 2026 and is rated High, with a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, meaning it can be exploited over a network with low complexity and no privileges or user interaction.

MessagePack for Ruby is an implementation of the MessagePack binary serialisation format. The flaw affects the Java-platform msgpack gem used on JRuby, in versions before 1.8.7. According to the CVE record, the Java decoder allocates arrays and byte buffers directly from attacker-controlled counts declared in a message header, before checking whether the corresponding data is actually present.

How a five-byte message exhausts memory

The GitHub security advisory for the flaw, GHSA-73v3-wf97-vpgj, explains the mechanism in detail. The JRuby decoder sizes containers from the element count written in the message header, with no cap at all. An array32 header declaring 0x7FFFFFFF elements causes the decoder to attempt an array of about eight gigabytes of reference slots immediately, producing an OutOfMemoryError. A count of 500 million against a 512 MiB heap produces a real allocation attempt that also ends in an OutOfMemoryError.

Smaller counts cause a quieter problem. The researchers measured that a single array32 header declaring 20 million elements, sent as five wire bytes with no elements at all, grew used heap by 78 MiB immediately, with no exception raised. The footprint stayed elevated after the unpacker was reset and full garbage collection ran, because the memory had already been spent on the header-declared allocation.

The same unchecked allocation applies to str32 and bin32 headers, which declare a byte length and trigger an immediate byte array allocation of that size. Only map32 headers are safe, because the decoder grows those containers one element at a time, and counts of 2^31 or above are cleanly refused. The advisory was verified on the released msgpack 1.8.6 Java gem running on JRuby 9.4.12 with OpenJDK 25.

Why the impact is worse on the JVM

The flaw is classified under CWE-770, allocation of resources without limits or throttling, and CWE-1325, improper control of sequential memory allocation. Its impact is on availability only: there is no confidentiality or integrity impact and no code execution, according to the advisory.

The researchers note that the danger is greater on the JVM than in the equivalent CRuby code, because long-lived JRuby servers share one heap across all threads and connections. A single crafted message can therefore destabilise or kill the whole Java process, not just one request. The CRuby unpacker already caps container sizes, a protection added in version 1.7.3 and strengthened in 1.8.6, but the Java decoder had neither generation of that cap.

The advisory also states that Fluentd is not affected, because Fluentd ships CRuby only. The flaw affects any JRuby application that feeds untrusted MessagePack data to MessagePack.unpack or MessagePack::Unpacker, including JRuby-based services and log or remote procedure call pipelines.

Fix available in version 1.8.7

The issue is fixed in msgpack gem version 1.8.7. Users should upgrade the Java-platform gem to 1.8.7 or later and, as general practice, validate untrusted input before decoding it. The fix mirrors the CRuby approach: cap the initial allocation by the bytes actually buffered and grow containers as data arrives, and read strings in bounded chunks instead of allocating the declared length up front.

Administrators running JRuby services that accept MessagePack from untrusted sources should treat this as a priority update, since exploitation needs only a tiny crafted message and no authentication.