Msgpack
Monthly
Unbounded memory leak in the msgpack-python C extension (msgpack._cmsgpack) allows a remote attacker to exhaust process memory by repeatedly sending malformed MessagePack maps, with approximately 4 MiB retained per failed parse and roughly 100 MiB after 25 failed parses as measured by the reporter. The flaw is triggered when strict_map_key=True (the default) rejects a map key that is neither str nor bytes: the decoded value has already been constructed and is never released, affecting both unpackb() and the streaming Unpacker API in releases up to 1.2.2. No public exploit code or active exploitation is identified in the available data, but the CVSS of 7.5 is availability-only (C:N/I:N/A:H), so impact is limited to denial of service rather than data disclosure or code execution; a public proof-of-concept reference exists in the advisory, though it is not verified as working exploit code.
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.
Unbounded memory leak in the msgpack-python C extension (msgpack._cmsgpack) allows a remote attacker to exhaust process memory by repeatedly sending malformed MessagePack maps, with approximately 4 MiB retained per failed parse and roughly 100 MiB after 25 failed parses as measured by the reporter. The flaw is triggered when strict_map_key=True (the default) rejects a map key that is neither str nor bytes: the decoded value has already been constructed and is never released, affecting both unpackb() and the streaming Unpacker API in releases up to 1.2.2. No public exploit code or active exploitation is identified in the available data, but the CVSS of 7.5 is availability-only (C:N/I:N/A:H), so impact is limited to denial of service rather than data disclosure or code execution; a public proof-of-concept reference exists in the advisory, though it is not verified as working exploit code.
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.