CVE-2026-21452: About MessagePack for Java (7th Jan 2026)

Preface: Aerospike is a specific, high-performance NoSQL database, and benchmarks generally show it to be significantly faster than many other clustered NoSQL solutions like Cassandra and MongoDB.

The term “NoSQL” refers to a broad category of databases with varying performance characteristics, so a direct comparison is more nuanced than a simple yes/no answer.

Aerospike uses MessagePack as its default, internal serialization format for Lists and Maps (Collection Data Types or CDTs); it is not an optional configuration you need to enable in the core database itself.

Background: MessagePack is a compact binary serialization format designed to be more memory-efficient than text-based formats like JSON. For the Java implementation, its memory requirements depend on whether you are using the standard heap-based process or advanced off-heap optimizations.

The MessagePack serialization process primarily utilizes JVM Virtual Memory, which encompasses several different pools:

JVM Heap Memory, Off-Heap / Native Memory and OS Page Cache.

About EXT32?

•         In binary serialization formats (like Mashpack), EXT32 is a type identifier (byte 0xDD) indicating a subsequent 32-bit binary block or extension.

•         It’s used for efficiency, compacting data better than text formats (JSON, XML) by representing data directly as bytes.

Serialized EXT32 objects can require more memory in the JVM heap, primarily due to how standard Java MessagePack libraries manage large payloads during deserialization. While the MessagePack format itself is compact, the serialization and deserialization process in Java introduces specific memory overheads for the EXT32 type:

Large Payload Buffering (Heap Exhaustion) EXT32 is designed for large extension data, supporting payloads up to 4 GiB in size.

Vulnerability details: A known issue in msgpack-java (prior to v0.9.11) was that the library would trust the declared length in the EXT32 header and immediately attempt to allocate a matching byte array on the JVM heap.

Impact: If an EXT32 object declares a massive size, it can trigger rapid heap exhaustion or an OutOfMemoryError before the data is even fully read.

Official announcement: Please refer to the link for details.

https://www.tenable.com/cve/CVE-2026-21452

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.