CVE-2026-92707: MessagePack-CSharp memory exhaustion in nested array deserialization

CVE-2026-92707 · Severity: medium · CVSS 5.3 · Published 2026-10-15

MessagePack-CSharp, a serialization library used in .NET applications including ASP.NET Core SignalR, is vulnerable to denial of service through uncontrolled memory allocation. An attacker can send a specially crafted payload that forces the application to allocate massive amounts of memory (up to 3,800 times larger than the payload itself), potentially causing the service to crash or become unresponsive.

Technologies: MessagePack (NuGet). Vendors: NuGet.

Quick answers

Is CVE-2026-92707 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-92707 being exploited in the wild.
How severe is CVE-2026-92707?
Medium severity, with a CVSS score of 5.3, published 15 October 2026.
Which products and versions are affected?
MessagePack-CSharp 2.5.302 and potentially others; MessagePack (NuGet) < 2.5.303, ECOSYSTEM:introduced=0,fixed=2.5.303.
Is there a fix for CVE-2026-92707?
Yes. MessagePack (NuGet): upgrade to 2.5.303 or later. Until then: Avoid deserializing untrusted data into System.Object; use concrete DTO types instead. For ASP.NET Core SignalR, replace object parameters with concrete types, disable the MessagePack protocol until patched, restrict hub methods to authenticated callers, or apply rate and connection limits. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-92707 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-92707?
Check whether you run MessagePack-CSharp or MessagePack (NuGet) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • MessagePack (NuGet): upgrade to 2.5.303 or later
    dotnet add package MessagePack --version 2.5.303

Avoid deserializing untrusted data into System.Object; use concrete DTO types instead. For ASP.NET Core SignalR, replace object parameters with concrete types, disable the MessagePack protocol until patched, restrict hub methods to authenticated callers, or apply rate and connection limits.

Technical details

The vulnerability exists in PrimitiveObjectFormatter, which allocates an object array based on the declared array length before enforcing the configured maximum object-graph depth limit. Nested array headers reuse trailing bytes for validation, allowing a small payload to trigger disproportionately large allocations. The attack requires the ability to deserialize untrusted data into System.Object, typically through ASP.NET Core SignalR hub methods accepting object parameters, and can be repeated to cause severe memory pressure.

Affected products

  • MessagePack MessagePack-CSharp 2.5.302 and potentially others

Identifiers

  • CVE-2026-92707
  • GHSA-qhrr-8q5h-9q3h

Timeline

  • 2026-10-15: disclosed

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.