CVE-2026-21452: 
Java vulnerability analysis and mitigation

CVE-2026-21452 is a denial-of-service vulnerability in MessagePack for Java (msgpack-java) that allows unauthenticated remote attackers to exhaust JVM heap memory by supplying a malicious .msgpack file containing an EXT32 object with an attacker-controlled, excessively large payload length. It affects all versions prior to 0.9.11 (specifically confirmed on 0.9.10). The vulnerability was disclosed on January 2, 2026, with the patch released the same day in version 0.9.11. It carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, GitHub Security Advisory).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-789 (Memory Allocation with Excessive Size Value). The affected components — org.msgpack.core.MessageUnpacker.readPayload(), MessageUnpacker.unpackValue(), and ExtensionValue.getData() — parse EXT32 extension headers lazily but then unconditionally trust the declared 4-byte payload length field when materializing the extension data, allocating a byte[] of that declared size without any upper-bound check. An attacker can craft a syntactically valid .msgpack file of just a few bytes (EXT32 format byte 0xC9 + 4-byte length + 1-byte type + 1 byte of actual data) with a declared length of hundreds of megabytes or gigabytes, triggering an immediate OutOfMemoryError on deserialization. The fix in commit daa2ea6 introduces a gradual allocation strategy for payloads exceeding 64 MB, verifying that actual data exists before completing allocation (GitHub Security Advisory, Patch Commit).

Successful exploitation results in complete availability loss of the affected Java application — the JVM terminates with an OutOfMemoryError or becomes unresponsive due to heap exhaustion and excessive garbage collection. There is no confidentiality or integrity impact. The attack surface is broad, encompassing model registries, ML inference services, CI/CD pipelines, and cloud-based platforms that accept or fetch .msgpack artifacts; because the malicious file is extremely small and syntactically valid, it can bypass basic file validation and scanning mechanisms, potentially causing cascading failures across dependent services (Github Advisory).

1. Craft the malicious file: Use the published Python PoC to generate a minimal .msgpack file with an EXT32 header (0xC9) followed by a 4-byte big-endian declared length (e.g., 470,000,001 bytes), a 1-byte extension type (0x01), and only 1 byte of actual payload (A). The resulting file is only 7 bytes on disk.
2. Deliver the payload: Upload the crafted .msgpack file to a location the target application fetches from — such as a model registry (e.g., Hugging Face), an S3 bucket, a CI/CD artifact store, or submit it directly via an API endpoint that accepts .msgpack input.
3. Trigger deserialization: Cause the target Java application to deserialize the file, for example by triggering a model load, inference request, or data processing job that calls MessageUnpacker.unpackValue() or ExtensionValue.getData() on the malicious file.
4. Achieve DoS: The library reads the EXT32 header, trusts the declared length, and attempts to allocate a byte[] of that size. With insufficient heap (e.g., -Xmx256m), the JVM immediately throws java.lang.OutOfMemoryError: Java heap space, terminating the process or rendering the service unavailable (GitHub Security Advisory).

• Logs: JVM crash logs or application logs containing java.lang.OutOfMemoryError: Java heap space with stack traces referencing org.msgpack.core.MessageUnpacker.readPayload, org.msgpack.core.MessageUnpacker.unpackValue, or org.msgpack.value.ExtensionValue.getData.
• File System: Presence of unusually small .msgpack files (under 20 bytes) in model artifact directories, upload staging areas, or CI/CD artifact stores that contain EXT32 headers (0xC9 as the first byte) with large declared lengths.
• Network: Inbound HTTP requests delivering tiny .msgpack files to model loading or deserialization endpoints; outbound requests fetching .msgpack artifacts from unexpected or newly registered external hosts (e.g., Hugging Face repositories not previously accessed).
• Process/Runtime: Sudden JVM heap exhaustion events, repeated full GC cycles, or abrupt process termination in Java services that process .msgpack data, particularly correlated with ingestion of externally sourced model files (GitHub Security Advisory).

Upgrade msgpack-java (Maven artifact org.msgpack:msgpack-core) to version 0.9.11 or later, which introduces gradual memory allocation for payloads exceeding 64 MB, preventing unbounded heap allocation (v0.9.11 Release, Patch Commit). As interim mitigations where upgrading is not immediately possible: restrict deserialization of .msgpack files to trusted, verified sources only; implement application-level file size limits before passing data to the unpacker; and configure JVM heap limits combined with process restart policies to reduce blast radius. Monitor JVM memory metrics for anomalous allocation spikes during deserialization operations.

The vulnerability was reported by researcher HyperPS and disclosed by the msgpack-java maintainer (xerial) via GitHub Security Advisory on January 2, 2026, with the patch released simultaneously (GitHub Security Advisory). Oracle included it in their April 2026 Critical Patch Update (Oracle CPU). Red Hat and INCIBE also published advisories tracking the vulnerability. Community coverage was noted on security aggregators including Vulners, CVEFeed, and The Hacker Wire shortly after disclosure, reflecting moderate industry attention given the straightforward PoC and broad applicability to ML/AI serving infrastructure.