CVE-2026-48502: MessagePack for C# DOS Vulnerability

CVE-2026-48502 Overview

CVE-2026-48502 is a stack memory allocation vulnerability in MessagePack for C#, a widely used MessagePack serializer for the .NET ecosystem. The flaw resides in MessagePackReader.ReadDateTime(), where the slow path for timestamp extension parsing performs a stackalloc operation using an attacker-controlled extension body length before validating that length. A small, malformed payload can claim a large timestamp extension body, triggering an uncatchable StackOverflowException that terminates the host process. The issue affects versions prior to 2.5.301 and 3.1.7. The maintainers fixed the vulnerability in releases 2.5.301 and 3.1.7.

Critical Impact
A remote attacker can crash any .NET service that deserializes untrusted MessagePack input, producing an unrecoverable denial-of-service condition.

Affected Products

MessagePack for C# versions prior to 2.5.301 (2.x branch)
MessagePack for C# versions prior to 3.1.7 (3.x branch)
Any .NET application or service that deserializes attacker-influenced MessagePack data using the vulnerable MessagePackReader.ReadDateTime() code path

Discovery Timeline

2026-06-22 - CVE-2026-48502 published to NVD
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-48502

Vulnerability Analysis

The vulnerability is classified as [CWE-125] Out-of-Bounds Read, but manifests as a stack exhaustion denial-of-service condition. MessagePack encodes timestamps using an extension type whose body length is declared on the wire. When MessagePackReader.ReadDateTime() enters its slow path, it computes a tokenSize value that incorporates the attacker-supplied extension body length. That tokenSize is then passed to stackalloc, allocating memory on the thread's stack before the length is validated against the legal timestamp encoding sizes of 4, 8, or 12 bytes.

Because stackalloc allocates linearly on the call stack, a multi-megabyte claimed length immediately exceeds the thread's stack limit. The resulting StackOverflowException cannot be caught in managed code and tears down the entire .NET process. A malicious payload requires only a few bytes on the wire to declare an arbitrarily large extension body, making the attack highly asymmetric.

Root Cause

The root cause is missing input validation prior to a stack allocation. The timestamp extension length must be 4, 8, or 12 bytes per the MessagePack specification, but the slow-path parser executes stackalloc based on the unvalidated wire-supplied size. Validation occurs only after the allocation, allowing oversized values to reach the allocator.

Attack Vector

The attack vector is network-based and unauthenticated. Any endpoint that accepts MessagePack-encoded data, such as a gRPC service, SignalR hub, MagicOnion server, Redis cache consumer, or message broker subscriber, can be targeted. The attacker crafts a MessagePack stream containing an extension type marker for timestamps along with a length field declaring an oversized body. Sending this stream once is sufficient to terminate the receiving process.

No verified public exploit code is available. The vulnerability mechanism is documented in the MessagePack for C# GitHub Security Advisory GHSA-382j-8mxh-c7x2.

Detection Methods for CVE-2026-48502

Indicators of Compromise

Abrupt termination of .NET worker processes without a managed exception being logged to application telemetry.
Windows Event Log entries showing EventID 1000 application crashes referencing clr.dll or coreclr.dll with exception code 0xC00000FD (stack overflow).
Repeated process restarts on services exposing MessagePack, gRPC, MagicOnion, or SignalR endpoints shortly after receiving inbound traffic.

Detection Strategies

Inventory all .NET applications and identify those referencing the MessagePack NuGet package at versions below 2.5.301 or 3.1.7 using SBOM tooling or dotnet list package --vulnerable.
Monitor process lifecycle telemetry for unhandled StackOverflowException terminations correlated with inbound network activity on MessagePack-consuming services.
Inspect network traffic for MessagePack extension type -1 (timestamp) frames declaring body lengths other than 4, 8, or 12 bytes.

Monitoring Recommendations

Alert on process exit codes consistent with stack overflow (0xC00000FD on Windows, SIGSEGV with stack signature on Linux) for services that deserialize MessagePack.
Track abnormal restart cadence for orchestrated workloads such as Kubernetes pods or systemd services hosting .NET applications.
Correlate crash events with source IPs of inbound MessagePack traffic to identify probing or active exploitation attempts.

How to Mitigate CVE-2026-48502

Immediate Actions Required

Upgrade the MessagePack NuGet package to version 2.5.301 for the 2.x branch or 3.1.7 for the 3.x branch on all affected projects.
Rebuild and redeploy all downstream applications, including transitive consumers such as MagicOnion, SignalR with MessagePack protocol, and custom serialization layers.
Restrict network exposure of MessagePack-consuming endpoints to authenticated and trusted clients where feasible until patches are deployed.

Patch Information

The maintainers fixed CVE-2026-48502 in MessagePack for C# releases 2.5.301 and 3.1.7. The fix validates the timestamp extension body length against the permitted values of 4, 8, or 12 bytes before performing any stack allocation. Patch details and release notes are available in the GHSA-382j-8mxh-c7x2 advisory.

Workarounds

Place a validating proxy or gateway in front of MessagePack endpoints to reject frames containing timestamp extension types with non-conforming length fields.
Limit accepted payload sizes at the transport layer to reduce the surface area for malformed extension declarations.
Where MessagePack is optional, switch deserialization to an alternate format such as JSON or Protobuf until the upgrade can be completed.

bash

# Upgrade MessagePack to a fixed version
dotnet add package MessagePack --version 3.1.7

# Verify resolved versions across the solution
dotnet list package --include-transitive | grep -i MessagePack