Msgpack
Monthly
Denial of service in the msgpack-python serialization library (versions prior to 1.2.1) lets remote attackers crash a process via an out-of-bounds read when an application reuses an Unpacker instance after a previously raised error was caught. Sending malformed MessagePack data that triggers an error, then feeding further data to the same Unpacker, can drive the process to a SEGV. No public exploit has been identified at time of analysis, and EPSS data was not provided, but the CVSS 3.1 score of 7.5 (availability-only) reflects a straightforward, unauthenticated crash condition.
MessagePack for Java versions prior to 0.9.11 are vulnerable to denial-of-service attacks through malicious .msgpack files that exploit unbounded heap allocation when deserializing EXT32 objects. An unauthenticated attacker can craft a small payload with attacker-controlled extension lengths that causes the library to attempt allocating excessive memory, leading to JVM heap exhaustion and service unavailability. Public exploit code exists for this vulnerability; organizations using affected versions should update immediately.
Heap buffer overflow in msgpack-c through version 7.0.1 results from an integer overflow in msgpack_unpacker_expand_buffer, where unchecked size_t addition of the requested reservation size and current buffer usage wraps to near-zero on near-SIZE_MAX inputs, causing the allocator to receive a massively undersized target while the function falsely reports success to the caller. Integrations that pass attacker-controlled lengths to the msgpack_unpacker_reserve_buffer API - such as custom length-prefixed streaming transports - can trigger subsequent heap overwrites when the caller writes the full declared length into the undersized buffer. No public exploit code or CISA KEV listing exists at time of analysis; exploitation requires a specific non-default integration pattern not present in msgpack-c's own internal decode paths.
Cross-buffer memory aliasing in msgpack-ruby prior to 1.8.2 allows same-process code to read or corrupt data belonging to a separate MessagePack::Buffer instance via a use-after-free in the rmem slab allocator. MessagePack::Buffer#clear returns a 4 KiB rmem page to the shared pool but leaves rmem_last, rmem_end, and rmem_owner pointing into the freed page; a subsequent write on the cleared buffer and a concurrent second Buffer allocation can claim the same physical page, creating a memory alias that exposes the second buffer's serialized bytes. A PoC is included in the vendor advisory (GHSA-4mrv-5p47-p938); no public exploit identified at time of analysis beyond that PoC, and the CVE is not in CISA KEV.
Denial of service in the msgpack-python serialization library (versions prior to 1.2.1) lets remote attackers crash a process via an out-of-bounds read when an application reuses an Unpacker instance after a previously raised error was caught. Sending malformed MessagePack data that triggers an error, then feeding further data to the same Unpacker, can drive the process to a SEGV. No public exploit has been identified at time of analysis, and EPSS data was not provided, but the CVSS 3.1 score of 7.5 (availability-only) reflects a straightforward, unauthenticated crash condition.
MessagePack for Java versions prior to 0.9.11 are vulnerable to denial-of-service attacks through malicious .msgpack files that exploit unbounded heap allocation when deserializing EXT32 objects. An unauthenticated attacker can craft a small payload with attacker-controlled extension lengths that causes the library to attempt allocating excessive memory, leading to JVM heap exhaustion and service unavailability. Public exploit code exists for this vulnerability; organizations using affected versions should update immediately.
Heap buffer overflow in msgpack-c through version 7.0.1 results from an integer overflow in msgpack_unpacker_expand_buffer, where unchecked size_t addition of the requested reservation size and current buffer usage wraps to near-zero on near-SIZE_MAX inputs, causing the allocator to receive a massively undersized target while the function falsely reports success to the caller. Integrations that pass attacker-controlled lengths to the msgpack_unpacker_reserve_buffer API - such as custom length-prefixed streaming transports - can trigger subsequent heap overwrites when the caller writes the full declared length into the undersized buffer. No public exploit code or CISA KEV listing exists at time of analysis; exploitation requires a specific non-default integration pattern not present in msgpack-c's own internal decode paths.
Cross-buffer memory aliasing in msgpack-ruby prior to 1.8.2 allows same-process code to read or corrupt data belonging to a separate MessagePack::Buffer instance via a use-after-free in the rmem slab allocator. MessagePack::Buffer#clear returns a 4 KiB rmem page to the shared pool but leaves rmem_last, rmem_end, and rmem_owner pointing into the freed page; a subsequent write on the cleared buffer and a concurrent second Buffer allocation can claim the same physical page, creating a memory alias that exposes the second buffer's serialized bytes. A PoC is included in the vendor advisory (GHSA-4mrv-5p47-p938); no public exploit identified at time of analysis beyond that PoC, and the CVE is not in CISA KEV.