MessagePack-CSharp EUVD-2026-102315

Exploitable only when an application deserializes attacker-controlled MessagePack into System.Object (or an object-typed member) via a resolver path that selects PrimitiveObjectFormatter, AND lets an attacker submit such payloads repeatedly. The named concrete exposure is an ASP.NET Core SignalR application with AddMessagePackProtocol() enabled and a reachable hub method taking an object parameter. Limiting factors: applications that deserialize only into concrete, narrowly-typed DTOs are not affected; endpoints behind authentication retain their configured authorization (PR:N applies only to publicly reachable endpoints); single requests cause transient pressure, so meaningful DoS requires sustained repeated submissions; and the workaround (avoid object/System.Object deserialization) neutralizes the path without upgrading.

This is a genuine but moderate-severity availability issue, not a top-tier emergency. The NVD CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, 5.3 Medium) is internally consistent with the description: network-reachable, no privileges, no user interaction, and impact limited to availability (C:N/I:N) via memory-exhaustion DoS (CWE-1325, incorrect calculation of buffer size, with the fix test also tagging CWE-789/CWE-190). The signals mostly agree that this is a lower real-world priority than a code-execution flaw: there is no CISA KEV listing and no EPSS score in the provided data, and no public exploit code is referenced - though the GHSA advisory does publish a concrete reproduction concept (a ~31.5 KiB payload amplifying to ~114.7 MiB, a ~3,800x factor), which meaningfully lowers the bar to weaponization even absent a drop-in PoC. The main caveat is a mismatch between the raw CVSS 'AV:N/AC:L/PR:N' framing and the stated exploitation reality: the vulnerability only matters when an application deserializes untrusted data into System.Object through PrimitiveObjectFormatter AND permits repeated attacker submissions, so the network/unauth framing holds only for apps that happen to expose such a path (e.g. a SignalR hub with an object parameter and AddMessagePackProtocol()). Where that path is not exposed, real risk is effectively nil regardless of the 5.3 score. Note the input 'Information Disclosure' tag conflicts with the CVSS impact metrics (C:N/I:N) and should be read as a mislabel - this is a denial-of-service, not a disclosure, issue.

An attacker locates a .NET application that deserializes untrusted MessagePack into object - for example an ASP.NET Core SignalR hub method with an object parameter and AddMessagePackProtocol() enabled - and repeatedly sends a small (~31.5 KiB) payload of nested array headers that reuse the same trailing bytes to pass per-header length validation. Each request forces allocation of many large object[] buffers (~114.7 MiB per the advisory) before the object-graph depth limit rejects the input, and sustained repetition drives severe managed-heap pressure, excessive GC, and eventual process termination or loss of service. No public exploit code is referenced, but the advisory documents the amplification technique in detail.