CVE-2026-21452: Remote DoS via Allocation-Before-Validation in msgpack-java

MessagePack is a binary serialization format designed for efficiency and speed, often used as a replacement for JSON in high-performance microservices and data pipelines. The vulnerability, CVE-2026-21452, impacts the msgpack-java library's handling of large binary data types (BIN32) and extension types (EXT32). These formats include a 4-byte length header indicating the size of the subsequent payload.

The core issue lies in the library's eager allocation strategy. When the deserializer encounters a header declaring a large payload (e.g., 2 GB), it immediately allocates a byte array of that size on the JVM heap. This allocation occurs before the library attempts to read the actual payload bytes from the network stream. Consequently, an attacker does not need to send 2 GB of traffic to consume 2 GB of memory on the target server. They simply need to send the header declaring that size.

This creates an asymmetric denial-of-service condition. A packet smaller than 10 bytes can force the server to allocate gigabytes of memory. If the allocation request exceeds the available heap space, the JVM throws a java.lang.OutOfMemoryError, typically causing the application container or the entire service process to terminate abruptly.

The vulnerability is a classic instance of CWE-789: Memory Allocation with Excessive Size Value. It resides in the MessageUnpacker class, specifically in the methods responsible for reading payload bodies, such as readPayload(int length). In vulnerable versions, the logic blindly trusts the length integer extracted from the MessagePack header.

The Vulnerable Logic

When unpackValue() or readPayload() is called for a BIN32 or EXT32 type, the code performs the following sequence:

1. Read Header: Reads the format byte (e.g., 0xC6 for BIN32) and the subsequent 4-byte length integer.
2. Allocate: Immediately executes new byte[length]. If length is Integer.MAX_VALUE (approx. 2.14 GB), the JVM attempts to find a contiguous block of heap memory of that size.
3. Read Body: Only after allocation does the code attempt to fill the array from the input stream.

This sequence is flawed because it lacks a "check-then-act" mechanism. It acts (allocates) based on untrusted input before verifying that the input stream actually contains the claimed amount of data. This violates the principle that resources should only be allocated proportional to the data actually received or validated.

The flaw is particularly dangerous because msgpack-java is often used in public-facing APIs and high-throughput data ingestion services where untrusted input is common. The lack of an upper bound check or a stream-availability check makes this trivial to exploit.

The remediation involves shifting from an eager allocation strategy to a gradual allocation strategy for large payloads. The fix was implemented in commit daa2ea6b2f11f500e22c70a22f689f7a9debdeae.

Vulnerable Code Pattern (Before)

The original implementation optimized for speed by allocating the buffer in one operation. This is efficient for trusted data but catastrophic for untrusted input.

// org.msgpack.core.MessageUnpacker
public byte[] readPayload(int length) throws IOException {
    // DANGER: Unconditional allocation based on untrusted 'length'
    byte[] newArray = new byte[length];
    readPayload(newArray);
    return newArray;
}

Patched Code Pattern (After)

The fix introduces a threshold (GRADUAL_ALLOCATION_THRESHOLD, set to 64 MB). Payloads smaller than this threshold are still allocated eagerly to maintain performance. Payloads larger than the threshold are allocated gradually as data is read from the stream.

// org.msgpack.core.MessageUnpacker
private static final int GRADUAL_ALLOCATION_THRESHOLD = 64 * 1024 * 1024; // 64MB
 
public byte[] readPayload(int length) throws IOException {
    if (length < 0) {
        throw new MessageSizeException("Invalid payload size: " + length, length);
    }
 
    // FIX: If length is massive, use gradual allocation to prevent OOM bombs
    if (length > GRADUAL_ALLOCATION_THRESHOLD) {
        return readPayloadGradually(length);
    }
    
    // Fast path for small payloads
    byte[] newArray = new byte[length];
    readPayload(newArray);
    return newArray;
}
 
private byte[] readPayloadGradually(int length) throws IOException {
    byte[] buffer = new byte[length];
    int totalRead = 0;
    while (totalRead < length) {
        // Read in chunks (e.g., 8KB or available bytes)
        // If EOF is reached before 'length' is met, throw exception
        // preventing the full allocation if data is missing.
        // ... implementation details ...
    }
    return buffer;
}

By reading gradually, the system ensures that memory is only consumed if the attacker actually transmits the data. This neutralizes the "MessagePack Bomb" because sending 2 GB of actual data is a network bandwidth attack, not a protocol logic exploit, and is handled by standard timeouts and rate limits.

Exploiting CVE-2026-21452 requires sending a malformed MessagePack structure to a vulnerable endpoint. The attack does not require authentication or complex chaining. The attacker simply acts as a client submitting data.

The "MessagePack Bomb"

The payload relies on the BIN32 (Binary 32-bit) format code 0xC6 or EXT32 (Extension 32-bit) format code 0xC9.

1. Construct Header: The attacker creates a byte sequence starting with 0xC6.
2. Define Length: The next 4 bytes define the length. The attacker sets this to 0x7F 0xFF 0xFF 0xFF (Maximum signed 32-bit integer, ~2.14 GB).
3. Final Payload: The total payload is just 5 bytes: C6 7F FF FF FF.

Attack Flow

If the server has a large heap (e.g., 8 GB) and does not crash immediately, the attack still degrades performance significantly. The thread handling the request holds a 2 GB array alive, triggering massive Garbage Collection (GC) pauses. Multiple concurrent requests of this type will quickly exhaust even the largest heaps.

The primary impact of this vulnerability is Denial of Service (DoS). The severity is High (CVSS 7.5) because it can be exploited remotely by an unauthenticated attacker with minimal resources.

Operational Impact

• Service Instability: The OutOfMemoryError is an Error type in Java, not an Exception. It is often unrecoverable at the request level and frequently causes the JVM to terminate or enter a zombie state where it cannot process new requests.
• Resource Starvation: Even if the process does not crash, the sudden allocation of gigabytes of memory forces the Garbage Collector into a "Stop-the-World" pause, freezing the application for all users.
• Scaling Failure: In auto-scaling environments (like Kubernetes), this exploit can cause a crash loop. As new pods start up, the attacker can crash them immediately, preventing the service from ever stabilizing.

Scope of Compromise

This vulnerability does not lead to:

• Remote Code Execution (RCE)
• Information Disclosure (Memory Leak)
• Data Corruption (beyond the interrupted transaction)

The scope is strictly limited to availability, but for critical infrastructure or high-availability APIs, the loss of availability is a catastrophic failure mode.