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

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.

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

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.