CVE-2026-54522: 
Ruby vulnerability analysis and mitigation

CVE-2026-54522 is a use-after-free (UAF) vulnerability in MessagePack for Ruby (msgpack-ruby) that enables same-process cross-buffer information disclosure and data corruption. The flaw exists in MessagePack::Buffer#clear within ext/msgpack/buffer.c, where stale rmem cursor pointers (rmem_last, rmem_end, rmem_owner) are left pointing into a freed memory page after it is returned to the shared pool. All versions up to and including 1.8.1 are affected; the issue is fixed in version 1.8.2. It carries a CVSS v4.0 base score of 2.1 (Low), reflecting its local attack vector and limited confidentiality impact (Github Advisory, Ruby Advisory DB).

The root cause is a use-after-free (CWE-416) in msgpack_buffer_clear(), which calls _msgpack_buffer_shift_chunk() to destroy all chunks and return their 4 KiB rmem pages to the shared slab pool via msgpack_rmem_free, but fails to reset rmem_last, rmem_end, and rmem_owner to NULL. On the next Buffer#write, the _msgpack_buffer_chunk_malloc() reuse branch returns b->rmem_last — a pointer into the already-freed page. If a second MessagePack::Buffer is subsequently allocated, msgpack_rmem_alloc() hands it the same physical page, causing both buffers to alias the same memory region. Because rmem uses a slab bitmask rather than free(), standard AddressSanitizer builds do not abort on this condition, making the bug subtle; a public PoC script demonstrating the cross-buffer disclosure is included in the advisory (Github Advisory, Patch Commit).

Successful exploitation results in same-process cross-buffer information disclosure, where one MessagePack::Buffer can read data belonging to a second buffer — potentially exposing serialized data from a different request or tenant in multi-tenant or concurrent Ruby applications. The symmetric write-corruption path also allows an attacker to overwrite another buffer's contents, threatening data integrity. Availability is not directly impacted, and the vulnerability does not cross process boundaries or enable remote code execution. Exploitation is limited to scenarios where the MessagePack::Buffer API is used directly with a clear/reuse lifecycle pattern; it is not reachable via a plain unpack byte stream (Github Advisory).

1. Identify target application: Confirm the target Ruby application uses the MessagePack::Buffer API directly with a clear/reuse lifecycle (e.g., a performance-oriented serialization pipeline), and that it runs msgpack-ruby version ≤ 1.8.1.
2. Set up exploit environment: Obtain or build msgpack-ruby 1.8.1 from RubyGems. Optionally compile with AddressSanitizer flags (-fsanitize=address) to observe the UAF without crashes, as the slab allocator does not trigger standard ASAN aborts.
3. Trigger the use-after-free: Create a MessagePack::Buffer (b1) with write_reference_threshold: 256, write sufficient data to fill an rmem page (e.g., 1000 + 200 + 1000 bytes), then call b1.clear. This returns the rmem page to the shared pool but leaves rmem_last/rmem_end/rmem_owner stale.
4. Write to the freed page: Call b1.write('C' * 128). The _msgpack_buffer_chunk_malloc() reuse branch returns the stale rmem_last pointer, writing into the already-freed page.
5. Alias the page with a second buffer: Create a second MessagePack::Buffer (b2) with write_reference_threshold: 4096 and write secret data. msgpack_rmem_alloc() returns the same physical page to b2, causing both buffers to alias the same memory.
6. Read disclosed data: Call b1.read_all. The returned bytes will contain data written by b2 rather than only the 128 'C' bytes, confirming cross-buffer information disclosure. The cross_buffer_match output will be true (Github Advisory, Patch Commit).

Upgrade msgpack-ruby to version 1.8.2 or later, which fixes the issue by resetting rmem_end, rmem_last, and rmem_owner to NULL in _msgpack_buffer_shift_chunk() when the buffer is fully emptied. The patch is a minimal three-line change in ext/msgpack/buffer.c (Patch Commit). No configuration-based workaround is available; the only mitigation short of upgrading is to avoid calling Buffer#clear followed by Buffer#write in performance-sensitive code paths that reuse buffers. Applications using only the high-level MessagePack.pack/MessagePack.unpack API are not affected (Github Advisory).

The vulnerability was discovered and reported by Pranjali Thakur of depthfirst.com and was published by maintainer byroot on June 9, 2026, with the GitHub Advisory Database entry updated on July 30, 2026. The advisory characterizes the real-world severity as "Low–Medium" given the narrow exploitation preconditions (direct Buffer API usage with clear/reuse lifecycle). No significant broader media coverage or notable community debate has been observed beyond the advisory and standard vulnerability aggregator entries (Github Advisory).