CVE-2026-48510: MessagePack for C# LZ4 Decompression Memory Exhaustion DoS

Technical summary

The vulnerability exists in MessagePack-CSharp's LZ4 decompression routines (Lz4Block and Lz4BlockArray). The library reads an uncompressed length field from untrusted wire data and immediately allocates an output buffer sized to that value—before performing LZ4 format validation or sanity-checking the expansion ratio. A crafted payload with a small wire footprint but a declared uncompressed length in the gigabyte range will trigger a large heap allocation. Subsequent LZ4 decoding may fail, but the memory has already been reserved, causing denial of service. This is a classic allocation-before-validation pattern (CWE-409: Improper Resource Validation; CWE-770: Allocation of Resources Without Limits or Throttling).

Business impact

Applications using MessagePack-CSharp to deserialize untrusted data are vulnerable to remote denial of service. An attacker can send crafted messages from the network, causing the application process to consume excessive memory and become unresponsive or crash. This affects service availability but does not compromise data confidentiality or integrity. In multi-tenant or shared infrastructure scenarios, this could impact other workloads on the same host.

Affected systems

MessagePack for C# versions before 2.5.301 (2.x branch) and before 3.1.7 (3.x branch) are vulnerable. Any C# application using these libraries to deserialize data from untrusted sources—particularly web services, message brokers, or APIs—is at risk if it processes LZ4-compressed MessagePack payloads.

Exploitability

Exploitation requires no authentication, no special privileges, and no user interaction. An attacker simply crafts a malicious MessagePack message with inflated uncompressed length metadata and sends it over the network to a vulnerable application. The network vector and low complexity (AC:L) make this easily exploitable by remote attackers. The vulnerability is rated HIGH (CVSS 7.5) because the impact is limited to availability, but the ease of exploitation is significant.

Remediation

Upgrade MessagePack for C# to version 2.5.301 or later (for the 2.x branch) or 3.1.7 or later (for the 3.x branch). These versions add validation of the declared uncompressed length before buffer allocation, preventing excessive memory consumption. Test the upgrade in a non-production environment to ensure compatibility with your application before deploying to production.

Patch guidance

Check your project dependencies to confirm your current MessagePack version. Use your NuGet package manager to update to the patched versions: 2.5.301+ or 3.1.7+. Verify the update resolves the vulnerability by consulting the official MessagePack GitHub repository or advisory. If you cannot patch immediately, implement network-level controls to restrict who can send MessagePack data to your application, and monitor for sudden memory spikes that may indicate exploitation attempts.

Detection guidance

Monitor application memory usage for unexplained spikes, particularly if your service deserializes MessagePack data from external sources. Enable verbose logging in MessagePack if available. Look for failed decompression events or exceptions during LZ4 decoding. In network telemetry, watch for small payloads followed by large memory allocations in processes running MessagePack-CSharp. Application performance monitoring (APM) tools can alert on sudden OutOfMemoryException or similar resource exhaustion errors.

Why prioritize this

This is a network-accessible denial-of-service vulnerability with high exploitability and no exploitation barriers. Any internet-facing or internal API using MessagePack-CSharp should be patched urgently. However, it does not lead to data breach or code execution, so it ranks below critical in most risk frameworks. Prioritize based on whether your application deserializes untrusted MessagePack data and the cost of availability loss in your environment.

Risk score, explained

CVSS 7.5 (HIGH) reflects an easily exploitable remote vulnerability with significant impact on service availability but no data compromise. The score correctly penalizes the absence of authentication and user interaction requirements (AV:N/AC:L/PR:N/UI:N), and the clear availability impact (A:H) against confidentiality and integrity (both N). Organizations should treat this as moderately urgent depending on deployment context and tolerance for brief outages.

Frequently asked questions