CVE-2026-48502: MessagePack-CSharp ReadDateTime Stack Overflow via Oversized Extension Length
Sending a MessagePack timestamp extension header with a bogus body length causes MessagePack-CSharp to stack-allocate a massive buffer before validating the input, crashing the host process with an un
The problem
MessagePackReader.ReadDateTime() enters a slow path when reading timestamp extension data. In that slow path, it computes a tokenSize that includes the attacker-supplied extension body length from the wire, then calls stackalloc with that size before checking whether the length is valid.
Valid MessagePack timestamp body lengths are exactly 4, 8, or 12 bytes. Any other declared length is malformed, but the pre-patch code allocates first and validates later. An attacker sending a single crafted message can terminate the host process. No special serializer options, LZ4 compression, typeless mode, or authentication are required, and MessagePackSecurity.UntrustedData does not help because the crash happens in one stack frame before any graph-depth check runs.
Proof of concept
# ext8 format: 0xC7 = ext8 opcode, 0xFF = body length (255, invalid for timestamp),
# 0xFF = type code -1 (timestamp), then zero actual body bytes.
# The reader enters the slow path, computes tokenSize = header + 255,
# calls stackalloc byte[tokenSize], and crashes before throwing a catchable exception.
payload = bytes([
0xC7, # ext8 opcode
0xFF, # declared body length = 255 (not 4, 8, or 12 -- forces slow path, huge stackalloc)
0xFF, # extension type = -1 (timestamp, signed)
# zero body bytes follow -- the process crashes before reading them
])
# Feed to any endpoint that deserializes into a type containing DateTime:
import msgpack # or any transport
socket.send(payload)The root cause is CWE-789: allocation size is taken directly from untrusted wire data with no bounds check ahead of the stackalloc call. The patch commit 26d4e74 adds an early rejection of any extension body length that is not one of the three valid timestamp sizes (4, 8, 12), so the slow path and its stackalloc are never reached for malformed input.
The fix converts what was an uncatchable process-terminating crash into an ordinary catchable MessagePackSerializationException. No special configuration or attacker privilege is needed; any network endpoint that deserializes DateTime values is exposed.
The fix
Upgrade MessagePack (NuGet) to 3.1.7 (v3.x line) or 2.5.301 (v2.x line). Both releases include commit 26d4e74 which validates the timestamp extension body length before any stack allocation. If an immediate upgrade is not possible, avoid deserializing untrusted input into schemas that include DateTime or DateTimeOffset fields, and enforce strict maximum message sizes at the transport layer.