CVE-2026-48514 Overview
CVE-2026-48514 affects MessagePack for C#, a widely used MessagePack serializer for the .NET ecosystem. The vulnerability exists in UnsafeBlitFormatterBase<T>.Deserialize, which reads an attacker-controlled byteLength from an extension payload. The deserializer allocates an array based on that value before validating it against the extension header length or remaining payload bytes. A very small malicious payload can therefore request a very large T[] allocation, leading to resource exhaustion. The issue is fixed in versions 2.5.301 and 3.1.7. The vulnerability is tracked under CWE-770: Allocation of Resources Without Limits or Throttling.
Critical Impact
A remote attacker can submit a small crafted MessagePack payload to force allocation of an oversized array, exhausting memory and causing denial of service in applications that deserialize untrusted input.
Affected Products
- MessagePack for C# versions prior to 2.5.301
- MessagePack for C# 3.x versions prior to 3.1.7
- .NET applications using UnsafeBlitFormatterBase<T> to deserialize untrusted MessagePack data
Discovery Timeline
- 2026-06-22 - CVE-2026-48514 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-48514
Vulnerability Analysis
The flaw resides in UnsafeBlitFormatterBase<T>.Deserialize within the MessagePack for C# library. The deserializer processes an extension payload that carries a byteLength field describing the size of the embedded array. Before the fix, the code allocated a T[] array sized by this attacker-controlled value without cross-checking it against the bounded extension header length or the bytes actually remaining in the input stream.
The outer extension header is constrained by available input, but that constraint was never propagated to the inner byteLength comparison. A malicious payload only needs a few bytes on the wire to declare a byteLength that triggers an allocation of hundreds of megabytes or more. The result is excessive memory consumption, garbage collector pressure, and potential OutOfMemoryException conditions that crash the host process.
Root Cause
The root cause is missing input validation between two related size fields. The deserializer trusted the inner byteLength value rather than clamping it to the outer extension length and remaining stream length. This is a classic CWE-770 resource allocation flaw, where a small input drives a disproportionately large allocation.
Attack Vector
The vulnerability is reachable over the network whenever an application deserializes MessagePack data from untrusted sources. Typical attack surfaces include RPC endpoints, message queues, cache layers, and any HTTP API that accepts MessagePack-encoded request bodies. The attacker does not need authentication. They only need the ability to deliver a crafted byte sequence that the application passes to a vulnerable UnsafeBlitFormatterBase<T> deserialization path.
No verified public exploit code is available for CVE-2026-48514. Refer to the GitHub Security Advisory GHSA-w567-gjr2-hm5j for vendor-supplied technical detail.
Detection Methods for CVE-2026-48514
Indicators of Compromise
- Sudden spikes in process memory usage immediately following MessagePack deserialization calls.
- OutOfMemoryException or process termination events in .NET services that accept MessagePack input.
- Small inbound payloads correlated with disproportionately large managed heap growth.
Detection Strategies
- Inventory all .NET projects and dependencies that reference MessagePack package versions prior to 2.5.301 or 3.1.7 using software composition analysis tooling.
- Add runtime telemetry around deserialization entry points to capture input size, allocated array size, and the calling assembly.
- Hunt for repeated OutOfMemoryException events in application logs originating from MessagePack.Formatters.UnsafeBlitFormatterBase call frames.
Monitoring Recommendations
- Track Gen2 garbage collection frequency and large object heap allocations on services exposed to untrusted MessagePack input.
- Alert on HTTP or RPC endpoints whose request-to-allocated-memory ratio exceeds an established baseline.
- Monitor crash dumps and Windows Error Reporting events for managed allocation failures in deserialization stacks.
How to Mitigate CVE-2026-48514
Immediate Actions Required
- Upgrade the MessagePack for C# package to version 2.5.301 (2.x branch) or 3.1.7 (3.x branch) across all projects.
- Identify any service that accepts MessagePack data from external clients and prioritize patching those first.
- Review SBOMs and CI pipelines to block builds that pin to vulnerable versions of MessagePack.
Patch Information
The maintainers fixed the issue by validating byteLength against the bounded extension header and the remaining payload before any array allocation. The fix is available in MessagePack for C# 2.5.301 and 3.1.7. Full remediation details are in the GitHub Security Advisory GHSA-w567-gjr2-hm5j.
Workarounds
- Enforce strict request size limits at the reverse proxy or API gateway to cap the maximum MessagePack payload accepted.
- Reject or sandbox deserialization of MessagePack data originating from untrusted or unauthenticated clients until patches are deployed.
- Configure process-level memory limits in container orchestrators so an exploitation attempt cannot exhaust host memory.
# Configuration example: upgrade MessagePack via the .NET CLI
dotnet add package MessagePack --version 3.1.7
# For projects pinned to the 2.x line:
dotnet add package MessagePack --version 2.5.301
# Verify resolved versions across the solution:
dotnet list package --vulnerable --include-transitive
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
