Update dependency org.msgpack:msgpack-core to v0.9.11 [SECURITY] #36
+2
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.8.13→0.9.11GitHub Vulnerability Alerts
CVE-2026-21452
Summary
Affected Components:
A denial-of-service vulnerability exists in MessagePack for Java 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.
PoC
Download dependency: curl -LO https://repo1.maven.org/maven2/org/msgpack/msgpack-core/0.9.8/msgpack-core-0.9.8.jar Java Reproducer
Compile
Run (with limited heap)
Observed Result:
Run:
A remotely hosted model file on Hugging Face can cause denial of service when loaded by a Java-based consumer.
Resolution
This issue is addressed in msgpack/msgpack-java@daa2ea6 by gradually allocating memory for large inputs, for both EXT32/BIN32 data types. This patch is released in msgpack-java 0.9.11 https://github.com/msgpack/msgpack-java/releases/tag/v0.9.11
Impact
This vulnerability enables a remote denial-of-service attack against applications that deserialize untrusted .msgpack model files using MessagePack for Java. 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 such as model registries, inference services, CI/CD pipelines, and cloud-based model hosting platforms that accept or fetch .msgpack artifacts. Because the malicious file is extremely small yet valid, it can bypass basic validation and scanning mechanisms, resulting in complete service unavailability and potential cascading failures in production systems.
Release Notes
msgpack/msgpack-java (org.msgpack:msgpack-core)
v0.9.11Compare Source
What's Changed
🐛 Bug Fixes
daa2ea6(Address CVE-2026-21452)🔗 Dependency Updates
🛠 Internal Updates
Full Changelog: msgpack/msgpack-java@v0.9.10...v0.9.11
v0.9.10Compare Source
What's Changed
🔥 Breaking Changes
🚀 Features
🐛 Bug Fixes
🔗 Dependency Updates
🛠 Internal Updates
📚 Docs
Other Changes
New Contributors
Full Changelog: msgpack/msgpack-java@v0.9.9...v0.9.10
v0.9.9Compare Source
What's Changed
🔗 Dependency Updates
jackson-databindby @komamitsu in #858🛠 Internal Updates
java.net.URLconstructor by @xuwei-k in #853Other Changes
jackson-dataformat-msgpackby @komamitsu in #866Full Changelog: msgpack/msgpack-java@v0.9.8...v0.9.9
v0.9.8Compare Source
What's Changed
🔥 Breaking Changes
🐛 Bug Fixes
🔗 Dependency Updates
🛠 Internal Updates
Full Changelog: msgpack/msgpack-java@v0.9.7...v0.9.8
v0.9.7Compare Source
What's Changed
🐛 Bug Fixes
🔗 Dependency Updates
🛠 Internal Updates
dependabot.ymlfor GitHub Actions update by @xuwei-k in #776setup-javainstead of deprecatedolafurpg/setup-scalaby @xuwei-k in #770📚 Docs
New Contributors
Full Changelog: msgpack/msgpack-java@v0.9.6...v0.9.7
v0.9.6Compare Source
What's Changed
🔥 Breaking Changes
Important: If you need to use DirectByteBuffer (raw memory access) in JDK17 or later, specify two JVM options to allow access to native memory:
🔗 Dependency Updates
🛠 Internal Updates
📚 Docs
New Contributors
Full Changelog: msgpack/msgpack-java@v0.9.5...v0.9.6
v0.9.5Compare Source
What's Changed
🐛 Bug Fixes
🔗 Dependency Updates
🛠 Internal Updates
Full Changelog: msgpack/msgpack-java@v0.9.4...v0.9.5
v0.9.4Compare Source
What's Changed
🔥 Breaking Changes
🚀 Features
MessagePackMapper#handleBigDecimalAsString@komamitsu (#745)🔗 Dependency Updates
🛠 Internal Updates
📚 Docs
MessagePackMapper#handleBigDecimalAsString@komamitsu (#745)Full Changelog: msgpack/msgpack-java@v0.9.3...v0.9.4
v0.9.3Compare Source
This version supports JDK17 #660.
Important: If you need to use DirectByteBuffer (raw memory access) in JDK17 or later, specify two JVM options to allow accessing
native memory:
Internal updates:
v0.9.2Compare Source
Internal updates:
v0.9.1Compare Source
Bug fixes and improvements:
Internal updates:
Known issues:
v0.9.0Compare Source
This version support reading and writing Timestamp values.
Packer and unpacker interfaces added pack/unpackTimestamp methods.
Timestamp value in MessagePack is an extension type value whose code is -1. You can read TimestampValue object with MessgageUnapcker.unpackValue method.
If you are using low-level unpack methods (e.g., unpackInt, unpackExtension, etc.),
you need to read unpackExtensionHeader first, and if extHeader.isTimestampType() is true, call unpackTimestamp(extHeader).
Timestamp values are represented with java.time.Instant objects.
You can extract the unixtime value with Instant.getEpochSecond(), unixtime with milliseconds resolution with Instant.toEpochMilli(), and nano-resolution time with Instant.getNano().
As TimestampValue is just a sub class of ExtensionValue, no change requierd in your code that are traversing MessagePack data with MessageUnpacker.unpackValue method.
reading timestamp values.
Dependency updates:
Internal updates:
v0.8.24Compare Source
v0.8.23Compare Source
Intenral changes:
v0.8.22Compare Source
v0.8.21Compare Source
v0.8.20Compare Source
v0.8.19Compare Source
v0.8.18Compare Source
v0.8.17Compare Source
v0.8.16Compare Source
v0.8.15Compare Source
test-onlycommand withtestOnly#445v0.8.14Compare Source
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.