CVE-2026-92707: MessagePack Nested Arrays Can Blow Past Vulnerability

MODERATE
Advisory Identifier: GHSA-qhrr-8q5h-9q3h
CVSS 5.3
CWE-1325
Published
Advisory Summary

CVE-2026-92707 is a MODERATE (CVSS 5.3) nested arrays can blow past vulnerability (CWE-1325: Improperly Controlled Sequential Memory Allocation) affecting MessagePack libraries in the NuGet ecosystem. The issue involves nested arrays can blow past buffer length limits. Remediation is available by upgrading affected packages to version 3.1.9, 2.5.303.

CVE-2026-92707 at a Glance

CVE Identifier CVE-2026-92707
GHSA Identifier GHSA-qhrr-8q5h-9q3h
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-1325: Improperly Controlled Sequential Memory Allocation
Affected Product MessagePack
Package Ecosystem NuGet
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix CVE-2026-92707

To remediate this vulnerability, upgrade all affected MessagePack dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

MessagePack fixed: 3.1.9
Upgrade MessagePack to 3.1.9
MessagePack fixed: 2.5.303
Upgrade MessagePack to 2.5.303
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for MessagePack

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-92707, inspect your project dependencies for MessagePack:

inspect dependencies for MessagePack

Analyze the terminal output to locate any version of MessagePack in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.1.9), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-1325: Improperly Controlled Sequential Memory Allocation, where the product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects. In MessagePack, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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 selects `PrimitiveObjectFormatter`; 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. ### 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 `object` parameters 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.

CVE-2026-92707 Affected MessagePack Versions

2 component(s)
Fixed Versions:
3.1.92.5.303
Product / Package Ecosystem Affected Versions Fixed Version
MessagePack
NuGet
≥ 3.0.0
< 3.1.9
3.1.9
MessagePack
NuGet
< 2.5.303
2.5.303

References

Frequently Asked Questions

What is CVE-2026-92707?
CVE-2026-92707 is a security vulnerability in MessagePack involving Nested arrays can blow past buffer length limits under CWE-1325: Improperly Controlled Sequential Memory Allocation.
Which MessagePack versions are affected?
Affected versions include releases prior to 3.1.9, 2.5.303 across affected packages: MessagePack.
What version fixes CVE-2026-92707?
Upgrading to 3.1.9, 2.5.303 (or the latest patched release for your respective branch) resolves the vulnerability.
Is MessagePack affected?
Yes, MessagePack is affected in releases prior to 3.1.9, 2.5.303. Upgrade your dependency to 3.1.9, 2.5.303 or later.
What is the CVSS score of CVE-2026-92707?
CVE-2026-92707 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with CVE-2026-92707?
CVE-2026-92707 is classified under CWE-1325: Improperly Controlled Sequential Memory Allocation (The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.).
How can I check NuGet dependencies for CVE-2026-92707?
Run the dependency tree command: 'inspect dependencies for MessagePack'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-qhrr-8q5h-9q3h",
  "modified" : "2026-10-15T18:35:46Z",
  "published" : "2026-10-15T18:35:46Z",
  "aliases" : [ "CVE-2026-92707" ],
  "summary" : "MessagePack: Nested arrays can blow past buffer length limits",
  "details" : "### Impact\n\nMessagePack-CSharp is vulnerable to denial of service through excessive memory allocation when deserializing attacker-controlled data into `System.Object`.\n\nWhen `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.\n\nBecause 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.\n\nApplications are affected when they:\n\n- Deserialize untrusted MessagePack data as `object`, or otherwise use a resolver path that selects `PrimitiveObjectFormatter`; and\n- Permit an attacker to submit such data repeatedly.\n\nASP.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.\n\nMessagePack-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.\n\n### Workarounds\n\nWhere possible, avoid deserializing untrusted data into `System.Object`, including `object`-typed members of otherwise strongly typed models. Use concrete, narrowly defined DTO types instead.\n\nFor ASP.NET Core SignalR applications, any of the following can prevent or reduce exposure:\n\n- Replace `object` parameters in reachable hub methods with concrete types.\n- Disable the MessagePack hub protocol and use another protocol until a patched MessagePack-CSharp release is available.\n- Restrict affected hub methods to trusted and authenticated callers.\n- Apply rate limits and connection limits to reduce the ability to repeat malicious requests.\n\nReducing 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.\n\nApplications 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "MessagePack"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.5.303"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "MessagePack"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.0.0"
      }, {
        "fixed" : "3.1.9"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-qhrr-8q5h-9q3h"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/MessagePack-CSharp/MessagePack-CSharp/commit/7fd78bbf3476e03beae8b0f7a521125525a8a64a"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/MessagePack-CSharp/MessagePack-CSharp/commit/95b63fca4f7097d3cac12d1a95286af4b4bbf02c"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/MessagePack-CSharp/MessagePack-CSharp/releases/tag/v2.5.303"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/MessagePack-CSharp/MessagePack-CSharp/releases/tag/v3.1.9"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1325" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-15T18:35:46Z",
    "nvd_published_at" : null
  }
}