CVE-2026-48510
Analyzed Analyzed - Analysis Complete

MessagePack-CSharp LZ4 Deserialization Buffer Overflow

Vulnerability report for CVE-2026-48510, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-06-22

Last updated on: 2026-06-25

Assigner: GitHub, Inc.

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-06-22
Last Modified
2026-06-25
Generated
2026-07-13
AI Q&A
2026-06-23
EPSS Evaluated
2026-07-11
NVD
EUVD

Affected Vendors & Products

Showing 2 associated CPEs
Vendor Product Version / Range
messagepack messagepack to 2.5.301 (exc)
messagepack messagepack From 3.0.3 (inc) to 3.1.7 (exc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-409 The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
CWE-770 The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability exists in MessagePack for C#, a serializer for C#. Before versions 2.5.301 and 3.1.7, when decompressing Lz4Block or Lz4BlockArray payloads, the software reads the declared uncompressed length from the data stream and allocates memory buffers based on that length without first validating the compressed data or checking if the declared size is reasonable.

An attacker can exploit this by sending a small compressed payload that falsely claims a very large uncompressed size, causing the program to allocate a large amount of memory unnecessarily before decompression begins.

Impact Analysis

The vulnerability can lead to excessive memory allocation, which may cause denial of service (DoS) conditions by exhausting system memory resources.

This can degrade system performance or cause the application to crash, potentially disrupting services that rely on MessagePack for C#.

Mitigation Strategies

To mitigate this vulnerability, update MessagePack for C# to version 2.5.301 or later, or 3.1.7 or later, where the issue has been fixed.

Compliance Impact

This vulnerability primarily impacts system availability by causing excessive memory allocation and potential process termination when decompressing untrusted MessagePack payloads. It does not directly involve unauthorized access, data disclosure, or modification.

Since the issue relates to resource exhaustion and denial of service rather than data confidentiality or integrity, its effect on compliance with standards like GDPR or HIPAA is indirect and limited to availability requirements.

Organizations relying on MessagePack-CSharp for deserialization should consider the risk of service disruption, which could impact availability controls mandated by such regulations, but there is no explicit mention of data breach or privacy violations in the provided information.

Detection Guidance

This vulnerability occurs when MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads with untrusted input that declares excessively large uncompressed lengths, leading to large memory allocations. Detection involves monitoring for unusually large memory allocations or out-of-memory exceptions during MessagePack deserialization.

Since the vulnerability is triggered by attacker-controlled MessagePack payloads using LZ4 compression, you can detect suspicious activity by inspecting network traffic for MessagePack payloads with Lz4Block or Lz4BlockArray compression and checking the declared uncompressed lengths.

There are no specific commands provided in the resources, but general approaches include:

  • Using network packet capture tools (e.g., tcpdump, Wireshark) to capture and analyze MessagePack payloads for suspiciously large declared uncompressed lengths.
  • Monitoring application logs and system metrics for out-of-memory errors or process crashes related to MessagePack deserialization.
  • Implementing custom instrumentation or debugging in the application to log decompressed length values before allocation.

Until patched, a workaround is to avoid using MessagePack-CSharp's built-in LZ4 compression modes for untrusted inputs or enforce strict size limits externally before deserialization.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-48510. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart