Summary
MessagePack-CSharp: Denial of service vulnerabilities can swamp the CPU or crash the process with stack and heap overflows
MessagePackReader.ReadDateTime() can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed tokenSize includes the extension body length from the wire and is used in a stackalloc operation before the extension length is validated as one of the valid timestamp sizes.
A very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable StackOverflowException, terminating the host process.
Affected components
- Package:
MessagePack - API:
MessagePackReader.ReadDateTime - Data types:
DateTimeand formatter paths that callReadDateTime - Finding IDs:
MESSAGEPACKCSHARP-020, related stack allocation findingMESSAGEPACKCSHARP-CROW-MEM-001
Workarounds
Patching is recommended.
Until a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain DateTime or DateTimeOffset values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.
There is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.
Resources
MESSAGEPACKCSHARP-020:ReadDateTimestack allocation from attacker-controlled extension lengthMESSAGEPACKCSHARP-CROW-MEM-001: related attacker-controlled stack allocation finding inMessagePackReader- CWE-770: Allocation of Resources Without Limits or Throttling
CVE split rationale
This vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.
Impact
Applications are affected when they deserialize untrusted payloads into types containing DateTime values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.
MessagePackSecurity.UntrustedData and MaximumObjectGraphDepth do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.
An attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.
A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixes are prepared and will be released in coordinated patch versions.
Upgrade guidance:
- Upgrade
MessagePackto the patched version for your release line. - Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.
The fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.
Frequently Asked Questions
- What is CVE-2026-48502? CVE-2026-48502 is a high-severity out-of-bounds read vulnerability in MessagePack (nuget), affecting versions >= 3.0, < 3.1.7. It is fixed in 3.1.7. A read operation accesses a memory location beyond the intended buffer boundary.
- Which versions of MessagePack are affected by CVE-2026-48502? MessagePack (nuget) versions >= 3.0, < 3.1.7 is affected.
- Is there a fix for CVE-2026-48502? Yes. CVE-2026-48502 is fixed in 3.1.7. Upgrade to this version or later.
- Is CVE-2026-48502 exploitable, and should I be worried? Whether CVE-2026-48502 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-48502 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-48502? Upgrade
MessagePackto 3.1.7 or later.