EUVD-2026-51235
GHSA-4mrv-5p47-p938
Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:L for same-process local constraint; PR:N because no special OS privileges needed; I:L added because the advisory explicitly documents write-corruption alongside disclosure.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.2, MessagePack::Buffer#clear in ext/msgpack/buffer.c leaves rmem_last, rmem_end, and rmem_owner stale after _msgpack_buffer_shift_chunk returns an rmem page to the shared pool, allowing a subsequent Buffer#write and a second MessagePack::Buffer to alias the page and disclose or corrupt cross-buffer data. This issue is fixed in version 1.8.2.
AnalysisAI
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.
Technical ContextAI
The vulnerability is in ext/msgpack/buffer.c of the CRuby (MRI) C extension for msgpack-ruby (CPE: cpe:2.3:a:msgpack:msgpack-ruby:*:*:*:*:*:*:*:*). The rmem subsystem (ext/msgpack/rmem.h) recycles fixed-size 4 KiB memory pages using a bitmask slab, not system malloc/free. When _msgpack_buffer_shift_chunk (buffer.c:128) calls msgpack_rmem_free to return a page to the pool, it correctly updates tail_buffer_end and read_buffer but leaves three cursor fields - rmem_last, rmem_end, and rmem_owner - pointing into the now-freed page. A subsequent Buffer#write triggers the _msgpack_buffer_chunk_malloc reuse branch (buffer.c:363), which returns b->rmem_last as a valid write destination even though that address belongs to the pool's free list. A second MessagePack::Buffer allocating its first chunk via msgpack_rmem_alloc then reclaims that same physical page, aliasing the two buffers in memory. CWE-416 (Use After Free) is the correct root cause classification; however, because rmem recycles via bitmask and not system allocator free, standard AddressSanitizer builds do not abort on the access - the cross-buffer data disclosure is the only observable symptom in a non-instrumented environment.
RemediationAI
Upgrade msgpack-ruby to version 1.8.2, which is confirmed fixed by the vendor advisory (GHSA-4mrv-5p47-p938) and the patch commit at https://github.com/msgpack/msgpack-ruby/commit/5627d71606b565641d2dd501b82aae862f4abe90. The fix adds three NULL assignments (rmem_end = NULL, rmem_last = NULL, rmem_owner = NULL) in _msgpack_buffer_shift_chunk immediately after returning the page to the pool, eliminating the stale-pointer condition with no functional trade-offs. If an immediate upgrade is not possible, isolate sensitive buffer operations by ensuring that MessagePack::Buffer instances carrying confidential data (e.g., session tokens, PII) complete their full lifecycle - including any Buffer#clear calls - in a code path that does not interleave with concurrent buffer allocations in the same process thread or fiber. Switching to a forked process-per-request model (e.g., Unicorn instead of Puma in cluster mode) eliminates the shared rmem pool across requests, removing the aliasing window at the cost of higher per-process memory overhead.
Same weakness CWE-416 – Use After Free
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today