msgpack-ruby EUVD-2026-51235

Exploitation requires same-process code execution in a CRuby (MRI) application using the msgpack-ruby C extension (version <= 1.8.1). The specific sequence is: (1) a MessagePack::Buffer is written to and then explicitly cleared via Buffer#clear, which causes its rmem page to be returned to the shared slab pool with rmem_last/rmem_end/rmem_owner left stale; and (2) a second MessagePack::Buffer is allocated within the same process - concurrently or immediately after - reclaiming that same physical page from the pool. Exploitation is limited to actors who can execute Ruby code within the target process, which in practice means a bug or injection in multi-tenant application logic, a malicious gem, or a co-located tenant in a shared-worker deployment. Pure-Ruby builds and JRuby are not affected. The rmem bitmask slab design means standard ASAN instrumentation does not detect the access, making it harder to detect passively. What limits exploitation: the attacker cannot trigger this from outside the process (no network-only path); the AT:P metric confirms special timing/sequence conditions must align.

The official CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N) scores 2.1, reflecting local attack scope and low confidentiality impact with no integrity or availability effect. The AT:P metric confirms a specific exploitation precondition must be satisfied. No EPSS data was provided in the intelligence; KEV status is not listed. A PoC script demonstrating the cross-buffer disclosure is embedded in the vendor advisory (GHSA-4mrv-5p47-p938), which elevates practical risk slightly above what the raw score implies. Notably, the vendor advisory explicitly mentions 'the symmetric write-corruption' alongside the information disclosure, suggesting an integrity impact that the official VI:N metric does not capture - this discrepancy should be noted when scoring internally. Real-world risk is bounded tightly by the same-process constraint: a remote network attacker cannot exploit this without already executing Ruby code in the target process. Multi-tenant Rack or Sidekiq worker processes that handle multiple tenants in a single MRI process represent the realistic threat boundary.

A PoC demonstrating the disclosure is provided in GHSA-4mrv-5p47-p938. In a multi-tenant Puma or Sidekiq worker process, an attacker's request triggers Buffer#clear on a msgpack buffer after writing data into it; a concurrent request in the same process worker then allocates a new MessagePack::Buffer that reclaims the exact same 4 KiB rmem page. When the attacker's buffer is subsequently read, it returns bytes from the second request's serialized payload - such as session tokens or personal data - constituting a cross-tenant information disclosure within the same Ruby process.