# CVE-2026-126366: msgpack-ruby JRuby decoder uncapped memory allocation on malformed headers

Source: https://junglewise.ai/threats/cve-2026-126366-msgpack-ruby-jruby-decoder-makes-uncapped-header-count  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-11-13. Updated: 2026-11-12  
License: CC BY 4.0 with a link back

CVE-2026-126366 · Severity: high · CVSS 7.5 · Published 2026-11-13

msgpack-ruby is a serialization library used across JRuby-based services, APIs, and log pipelines. The Java implementation of the decoder pre-allocates arrays and buffers based on sizes declared in message headers without any upper bound, allowing a 5-byte crafted message to trigger multi-gigabyte memory allocation attempts or silent memory consumption. This causes the entire shared JVM process to run out of memory and crash, affecting all concurrent users and connections.

Vendors: [RubyGems](https://junglewise.ai/threats/vendors/rubygems).

## Quick answers

**Is CVE-2026-126366 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-126366 being exploited in the wild.

**How severe is CVE-2026-126366?** High severity, with a CVSS score of 7.5, published 13 November 2026.

**Which products and versions are affected?** Msgpack-Ruby 1.8.6 and earlier (Java platform only); msgpack (RubyGems) <= 1.8.6.

**Is there a fix for CVE-2026-126366?** No fixed version is recorded yet. Reject or filter msgpack payloads with array32/str32/bin32 headers declaring element counts or byte lengths in excess of expected message sizes before passing them to the unpacker. Alternatively, deploy JRuby applications with strictly constrained heap limits (-Xmx) to contain blast radius to individual processes rather than shared JVM instances. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.

**How is CVE-2026-126366 attacked?** It is attacked over the network, in a software library.

**Am I affected by CVE-2026-126366?** Check whether you run Msgpack-Ruby or msgpack (RubyGems) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix


Reject or filter msgpack payloads with array32/str32/bin32 headers declaring element counts or byte lengths in excess of expected message sizes before passing them to the unpacker. Alternatively, deploy JRuby applications with strictly constrained heap limits (-Xmx) to contain blast radius to individual processes rather than shared JVM instances.

## Technical details

The JRuby decoder in msgpack-ruby (ext/java/Decoder.java) allocates container arrays directly from header-declared element counts without any cap, unlike the C implementation which has bounded this since version 1.7.3 (SHRT_MAX) and further hardened it in 1.8.6 via byte-buffered limits. Three dispatch paths are vulnerable: array32 calls new IRubyObject[size] immediately, str32/bin32 call new byte[size], and all attempt allocation before reading any actual data. Attack vectors include OutOfMemoryError crashes on counts near 2^31, actual allocation attempts that exhaust heap on intermediate values, and silent memory retention (up to 78 MiB from a 5-byte message) below the crash threshold. The only guard is rejection of counts ≥2^31, leaving the entire positive range below that unprotected. Network attack vector, no authentication required, affects streaming unpackers common in socket-fed services sharing heap across connections.

## Affected products

- msgpack msgpack-ruby 1.8.6 and earlier (Java platform only)

## Identifiers

- CVE-2026-126366
- GHSA-73v3-wf97-vpgj

## Timeline

- 2026-11-12: disclosed

## Related threats

- [MessagePack for Ruby use-after-free in MessagePack::Buffer#clear](https://junglewise.ai/threats/cve-2026-54522-messagepack-for-ruby-use-after-free-in-messagepack-buffer-clear)