CVE-2026-48510 Overview
CVE-2026-48510 affects MessagePack for C#, a widely deployed MessagePack serializer used in .NET applications. The vulnerability resides in how the library handles Lz4Block and Lz4BlockArray payloads during decompression. The library reads a declared uncompressed length from the wire and allocates an output buffer based on that value before validating the compressed data or the declared expansion ratio. A small malicious payload can claim a very large uncompressed length and force a large memory allocation. The issue is tracked under [CWE-409] Improper Handling of Highly Compressed Data (Data Amplification) and is fixed in versions 2.5.301 and 3.1.7.
Critical Impact
Remote attackers can trigger excessive memory allocation through crafted LZ4 payloads, leading to denial of service on applications that deserialize untrusted MessagePack data.
Affected Products
- MessagePack-CSharp versions prior to 2.5.301
- MessagePack-CSharp 3.x versions prior to 3.1.7
- .NET applications consuming untrusted MessagePack input via Lz4Block or Lz4BlockArray compression modes
Discovery Timeline
- 2026-06-22 - CVE-2026-48510 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-48510
Vulnerability Analysis
The vulnerability is a data amplification flaw in the LZ4 decompression path of MessagePack-CSharp. MessagePack supports two compression modes, Lz4Block and Lz4BlockArray, where each compressed block carries a length prefix indicating the size of the uncompressed output. The deserializer trusts this declared length and allocates a buffer of that size before performing LZ4 decoding. An attacker controlling the serialized payload can advertise an uncompressed length far exceeding the actual data size. The runtime then attempts to allocate the requested buffer, exhausting available memory.
Root Cause
The root cause is missing validation between the declared uncompressed length and the actual compressed payload size. The decompression routine does not enforce a maximum expansion ratio or cap the allocation size. It also does not stream-decode the LZ4 data to verify the declared length before committing memory. This violates the principle of validating untrusted size fields prior to resource allocation.
Attack Vector
Exploitation requires the target application to deserialize attacker-controlled MessagePack data using LZ4 compression. Common scenarios include web APIs, message queues, gRPC services, and inter-process communication channels that accept MessagePack payloads. The attacker sends a small payload, often only a few bytes, that declares an uncompressed length in the gigabyte range. The deserializer allocates the buffer before LZ4 decoding begins, triggering an OutOfMemoryException or system-level memory pressure. No authentication is required when the deserialization endpoint is publicly reachable.
No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-v72x-2h86-7f8m for vendor-provided technical details.
Detection Methods for CVE-2026-48510
Indicators of Compromise
- Repeated OutOfMemoryException events originating from MessagePack.LZ4MessagePackSerializer or related decompression call stacks
- Sudden spikes in managed heap size or working set memory on services that accept MessagePack input
- Small inbound payloads followed by abnormal Large Object Heap growth in .NET process telemetry
Detection Strategies
- Inspect application logs for unhandled OutOfMemoryException traces referencing MessagePack deserialization frames
- Monitor inbound MessagePack messages for an unusually high ratio between declared uncompressed length and on-wire payload size
- Audit dependency manifests (packages.config, .csproj, paket.dependencies) for MessagePack versions below 2.5.301 or 3.1.7
Monitoring Recommendations
- Instrument deserialization endpoints with metrics on payload size, allocation size, and exception rates
- Forward .NET runtime crash dumps and GC pressure events to a centralized log platform for correlation
- Alert on process restarts or container OOM kills affecting services that handle external MessagePack traffic
How to Mitigate CVE-2026-48510
Immediate Actions Required
- Upgrade MessagePack-CSharp to version 2.5.301 on the 2.x branch or 3.1.7 on the 3.x branch
- Identify all services that accept MessagePack input from untrusted sources and prioritize them for patching
- Apply request size limits at the gateway, proxy, or framework layer to constrain inbound payload size
Patch Information
The vendor released fixes in MessagePack-CSharp 2.5.301 and 3.1.7. The patches add validation of the declared uncompressed length against the compressed payload size and impose bounds before allocation. Refer to the MessagePack-CSharp Security Advisory GHSA-v72x-2h86-7f8m for fix details and upgrade guidance.
Workarounds
- Disable LZ4 compression modes by avoiding Lz4BlockArray and Lz4Block resolvers when deserializing untrusted input
- Wrap deserialization calls with strict input size limits enforced before the call to MessagePackSerializer.Deserialize
- Place a reverse proxy or API gateway in front of affected services to cap request body size to a known-safe value
# Configuration example: upgrade via dotnet CLI
dotnet add package MessagePack --version 3.1.7
# or for the 2.x branch
dotnet add package MessagePack --version 2.5.301
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
