Summary
MessagePack: Nested arrays can blow past buffer length limits
Workarounds
Where possible, avoid deserializing untrusted data into System.Object, including object-typed members of otherwise strongly typed models. Use concrete, narrowly defined DTO types instead.
For ASP.NET Core SignalR applications, any of the following can prevent or reduce exposure:
- Replace
objectparameters in reachable hub methods with concrete types. - Disable the MessagePack hub protocol and use another protocol until a patched MessagePack-CSharp release is available.
- Restrict affected hub methods to trusted and authenticated callers.
- Apply rate limits and connection limits to reduce the ability to repeat malicious requests.
Reducing the maximum deserialization depth or transport message size may reduce the worst-case allocation, but should be treated only as defense in depth. It does not correct the allocate-before-depth-check behavior and is not a complete remediation.
Applications with advanced resolver configurations may use a custom formatter for object that enforces the depth limit before allocating arrays. Such a formatter should be carefully reviewed and tested against untrusted input.
Impact
MessagePack-CSharp is vulnerable to denial of service through excessive memory allocation when deserializing attacker-controlled data into System.Object.
When PrimitiveObjectFormatter encounters an array, it allocates an object[] using the declared array length before enforcing the configured maximum object-graph depth. A specially crafted payload containing deeply nested arrays can therefore keep many large arrays live simultaneously before deserialization is rejected for exceeding the depth limit.
Because the array-header validation uses the total unread byte count as evidence that the declared elements may be present, nested array headers can reuse the same trailing bytes for this validation. This permits a relatively small payload to cause disproportionately large managed-heap allocations. The reported example uses an approximately 31.5 KiB payload to allocate roughly 114.7 MiB of reference storage on x64, an amplification factor of approximately 3,800, before the depth exception is raised. Repeated requests may cause severe memory pressure, excessive garbage collection, process termination, or loss of service availability.
Applications are affected when they:
- Deserialize untrusted MessagePack data as
object, or otherwise use a resolver path that selectsPrimitiveObjectFormatter; and - Permit an attacker to submit such data repeatedly.
ASP.NET Core SignalR is one known way to expose the vulnerability remotely: an application that enables AddMessagePackProtocol() and has a reachable hub method with an object parameter may pass attacker-controlled arguments to the vulnerable MessagePack-CSharp formatter. However, the underlying vulnerability is in MessagePack-CSharp, not SignalR, and other applications that deserialize untrusted data through the same formatter may also be affected.
MessagePack-CSharp 2.5.302 is confirmed to contain the vulnerable code. Other releases containing the same allocate-before-depth-check behavior may also be affected. Authentication requirements depend on the application exposing the deserialization endpoint: exploitation requires no privileges for a publicly reachable endpoint, while protected endpoints retain their configured authorization requirements.
CVE-2026-92707 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.5.303, 3.1.9); upgrading removes the vulnerable code path.
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
MessagePack to 2.5.303 or later; MessagePack to 3.1.9 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-92707? CVE-2026-92707 is a medium-severity security vulnerability in MessagePack (nuget), affecting versions < 2.5.303. It is fixed in 2.5.303, 3.1.9.
- How severe is CVE-2026-92707? CVE-2026-92707 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of MessagePack are affected by CVE-2026-92707? MessagePack (nuget) versions < 2.5.303 is affected.
- Is there a fix for CVE-2026-92707? Yes. CVE-2026-92707 is fixed in 2.5.303, 3.1.9. Upgrade to this version or later.
- Is CVE-2026-92707 exploitable, and should I be worried? Whether CVE-2026-92707 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-92707 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-92707?
- Upgrade
MessagePackto 2.5.303 or later - Upgrade
MessagePackto 3.1.9 or later
- Upgrade