CVE-2026-48510

MessagePack-CSharp: LZ4 decompression allocates from unbounded declared output lengths

Published Jun 22, 2026 CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Description
MessagePack for C# is a MessagePack serializer for C#. Prior to 2.5.301 and 3.1.7, when MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable. A small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins. This vulnerability is fixed in 2.5.301 and 3.1.7.

Analysis

AI-generated

Technical impact

The reported vulnerability lies in the LZ4 decompression path of the MessagePack-CSharp library. A small compressed payload with a large claimed uncompressed length can force an allocator to reserve a huge buffer before the data is validated, causing a memory exhaustion that crashes or slows the running process. This buffer allocation based on untrusted data corresponds to CWE‑409 and CWE‑770.

Affected Systems

The issue affects the MessagePack-CSharp library, versions prior to 2.5.301 in the 2.x line and prior to 3.1.7 in the 3.x line. Any application that deserializes LZ4‑compressed MessagePack data using these library versions is vulnerable.

Risk and Exploitability

The CVSS score of 6.3 indicates moderate severity, and the vulnerability is not listed in the CISA KEV catalog. No EPSS score is available, so the exploitation probability is unknown, but the flaw can be triggered with any LZ4 payload, making an attack straightforward. The likely vector is network or file‑based, targeting any system that accepts LZ4 input from an external source. The attacker requires no elevated privileges; the application using the library is the only necessary context.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade MessagePack-CSharp to version 2.5.301 or newer, or to 3.1.7 or newer, ensuring the library deallocates after successful validation.
  • Replace or patch existing code to load the updated library in all affected application deployments.
  • If an upgrade path is not immediately possible, implement a defensive check that verifies the claimed uncompressed length does not exceed a reasonable bound before allocating memory, or reject the payload entirely.

Generated by OpenCVE AI on June 22, 2026 at 23:26 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Github GHSA Github GHSA GHSA-v72x-2h86-7f8m MessagePack-CSharp: LZ4 decompression allocates from unbounded declared output lengths
History
Type Values Removed Values Added
First Time appeared Messagepack
Messagepack messagepack-csharp
Vendors & Products Messagepack
Messagepack messagepack-csharp
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Description MessagePack for C# is a MessagePack serializer for C#. Prior to 2.5.301 and 3.1.7, when MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable. A small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins. This vulnerability is fixed in 2.5.301 and 3.1.7.
Title MessagePack-CSharp: LZ4 decompression allocates from unbounded declared output lengths
Weaknesses CWE-409
CWE-770
References
Metrics cvssV4_0

{'score': 6.3, 'vector': 'CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N'}

Weaknesses
  • CWE-409

    Improper Handling of Highly Compressed Data (Data Amplification)

  • CWE-770

    Allocation of Resources Without Limits or Throttling

Sources

Status
PUBLISHED
Assigner
GitHub_M
Published
Updated
Jun 25, 2026, 3:05 PM
Reserved
May 21, 2026, 4:18 PM
Status
Analyzed
Published
Jun 22, 2026, 10:16 PM
Modified
Jun 25, 2026, 4:16 PM