CVE-2026-21452: MessagePack Java DoS Vulnerability

CVE-2026-21452 Overview

MessagePack for Java is a popular serializer implementation for Java applications. A denial-of-service vulnerability exists in versions prior to 0.9.11 when deserializing .msgpack files containing EXT32 objects with attacker-controlled payload lengths. While MessagePack-Java parses extension headers lazily, it later trusts the declared EXT payload length when materializing the extension data. When ExtensionValue.getData() is invoked, the library attempts to allocate a byte array of the declared length without enforcing any upper bound.

A malicious .msgpack file of only a few bytes can therefore trigger unbounded heap allocation, resulting in JVM heap exhaustion, process termination, or service unavailability. This vulnerability is triggered during model loading/deserialization, making it a model format vulnerability suitable for remote exploitation.

Critical Impact

Remote denial-of-service attack against applications that deserialize untrusted .msgpack model files, leading to complete service unavailability through JVM heap exhaustion or OutOfMemoryError termination.

Affected Products

• MessagePack for Java versions prior to 0.9.11
• Applications deserializing untrusted .msgpack files using MessagePack-Java
• Model registries, inference services, CI/CD pipelines, and cloud-based model hosting platforms accepting .msgpack artifacts

Discovery Timeline

• 2026-01-02 - CVE CVE-2026-21452 published to NVD
• 2026-01-08 - Last updated in NVD database

Technical Details for CVE-2026-21452

Vulnerability Analysis

This vulnerability (CWE-400: Uncontrolled Resource Consumption) enables a remote denial-of-service attack against applications that deserialize untrusted .msgpack model files using MessagePack for Java. The attack exploits the library's trust in declared length metadata without proper bounds validation.

A specially crafted but syntactically valid .msgpack file containing an EXT32 object with an attacker-controlled, excessively large payload length can trigger unbounded memory allocation during deserialization. When the model file is loaded, the library trusts the declared length metadata and attempts to allocate a byte array of that size, leading to rapid heap exhaustion, excessive garbage collection, or immediate JVM termination with an OutOfMemoryError.

The attack requires no malformed bytes, user interaction, or elevated privileges and can be exploited remotely in real-world environments. Because the malicious file is extremely small yet syntactically valid, it can bypass basic validation and scanning mechanisms, resulting in complete service unavailability and potential cascading failures in production systems.

Root Cause

The root cause lies in the MessageUnpacker class which fails to enforce an upper bound on the declared EXT payload length before attempting memory allocation. When parsing EXT32 format objects, the library lazily reads the header but later trusts the attacker-controlled length value when materializing extension data via ExtensionValue.getData(). This trust-without-verification pattern allows malicious input to dictate arbitrary allocation sizes.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can craft a minimal .msgpack file (only a few bytes) containing an EXT32 header with an excessively large declared payload length. When a vulnerable application deserializes this file, the following sequence occurs:

1. The parser reads the EXT32 header containing the malicious length value
2. Upon calling ExtensionValue.getData(), the library attempts to allocate a byte array matching the declared length
3. The JVM attempts to fulfill the allocation request, causing rapid heap exhaustion
4. The application crashes with OutOfMemoryError or becomes unresponsive due to garbage collection pressure

The security patch adds bounds checking to prevent unbounded allocations:

 import java.io.Closeable;
 import java.io.IOException;
 import java.math.BigInteger;
+import java.util.ArrayList;
+import java.util.List;
 import java.nio.ByteBuffer;
 import java.nio.CharBuffer;
 import java.nio.charset.CharacterCodingException;

Source: GitHub Commit daa2ea6b

Detection Methods for CVE-2026-21452

Indicators of Compromise

• Unexpected OutOfMemoryError exceptions in Java applications processing .msgpack files
• Abnormally high memory consumption during deserialization operations
• JVM process termination without explicit shutdown commands
• Presence of .msgpack files with small file sizes but extremely large declared payload lengths in EXT32 headers

Detection Strategies

• Monitor JVM heap usage during .msgpack deserialization operations for sudden spikes
• Implement application-level logging to capture deserialization exceptions, particularly OutOfMemoryError
• Audit ingestion pipelines for .msgpack files originating from untrusted sources
• Scan dependency manifests to identify MessagePack for Java versions prior to 0.9.11

Monitoring Recommendations

• Configure JVM garbage collection logging to detect excessive GC activity indicative of memory pressure
• Implement resource quotas and memory limits for processes handling untrusted model files
• Set up alerts for application crashes with OutOfMemoryError exit codes
• Monitor model registry and inference service endpoints for unusual file upload patterns

How to Mitigate CVE-2026-21452

Immediate Actions Required

• Upgrade MessagePack for Java to version 0.9.11 or later immediately
• Audit all applications using MessagePack-Java for vulnerable version dependencies
• Restrict acceptance of .msgpack files from untrusted sources until patched
• Implement memory limits on processes handling potentially untrusted deserialization workloads

Patch Information

Version 0.9.11 of MessagePack for Java fixes this vulnerability by implementing bounds checking on EXT payload lengths before memory allocation. The fix is available via the GitHub Release v0.9.11. For complete technical details, refer to the GitHub Security Advisory GHSA-cw39-r4h6-8j3x.

Workarounds

• Validate .msgpack files at ingestion boundaries before passing to the MessagePack-Java deserializer
• Implement application-level checks on declared payload sizes before deserialization
• Run deserialization operations in sandboxed environments with strict memory limits
• Avoid processing .msgpack files from untrusted or unverified sources until the upgrade is complete

# Maven dependency update example
# Update pom.xml to use patched version:
# <dependency>
#   <groupId>org.msgpack</groupId>
#   <artifactId>msgpack-core</artifactId>
#   <version>0.9.11</version>
# </dependency>

# Verify installed version
mvn dependency:tree | grep msgpack