# CVE-2026-54522: MessagePack for Ruby use-after-free in MessagePack::Buffer#clear

Source: https://junglewise.ai/threats/cve-2026-54522-messagepack-for-ruby-use-after-free-in-messagepack-buffer-clear  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-07-30. Updated: 2026-07-30  
License: CC BY 4.0 with a link back

CVE-2026-54522 · Severity: medium · CVSS 4 · Published 2026-07-30

MessagePack for Ruby is a library used to serialize and deserialize data into a compact binary format. A security flaw in how the library manages its internal memory buffers allows data from one buffer to be leaked into or corrupted by another. In practice, this could allow an attacker to access sensitive information or corrupt data belonging to different parts of the same application process.

Vendors: [RubyGems](https://junglewise.ai/threats/vendors/rubygems).

## Quick answers

**Is CVE-2026-54522 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-54522 being exploited in the wild.

**How severe is CVE-2026-54522?** Medium severity, with a CVSS score of 4, published 30 July 2026.

**Which products and versions are affected?** msgpack (RubyGems) ECOSYSTEM:introduced=0,fixed=1.8.2.

**Is there a fix for CVE-2026-54522?** Yes. msgpack (RubyGems): upgrade to 1.8.2 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-54522 attacked?** It is attacked with local access, in a software library.

**Am I affected by CVE-2026-54522?** Check whether you run msgpack (RubyGems) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix

- msgpack (RubyGems): upgrade to 1.8.2 or later

  ```sh
  bundle update msgpack
  ```


## Technical details

A use-after-free (UAF) vulnerability exists in MessagePack::Buffer#clear within ext/msgpack/buffer.c. When the clear method is called, it returns memory pages to a shared pool but fails to reset internal rmem pointers (rmem_last, rmem_end, and rmem_owner). Consequently, a subsequent write operation may reuse a stale pointer to a freed page. If a second MessagePack::Buffer re-acquires that same page from the pool, both buffers will alias the same physical memory. This allows one buffer to read or overwrite the contents of the other. The issue is fixed in version 1.8.2 by ensuring pointers are properly reset when a buffer is emptied.

## Affected products

- msgpack MessagePack for Ruby < 1.8.2

## Identifiers

- CVE-2026-54522
- GHSA-4mrv-5p47-p938

## Timeline

- 2026-06-09: advisory: GitHub Security Advisory published
- 2026-07-30: disclosed: CVE published to NVD

## References

- [https://github.com/msgpack/msgpack-ruby/commit/5627d71606b565641d2dd501b82aae862f4abe90](https://github.com/msgpack/msgpack-ruby/commit/5627d71606b565641d2dd501b82aae862f4abe90)
- [https://github.com/msgpack/msgpack-ruby/security/advisories/GHSA-4mrv-5p47-p938](https://github.com/msgpack/msgpack-ruby/security/advisories/GHSA-4mrv-5p47-p938)

## Related threats

- [msgpack-ruby JRuby decoder uncapped memory allocation on malformed headers](https://junglewise.ai/threats/cve-2026-126366-msgpack-ruby-jruby-decoder-makes-uncapped-header-count)