GHSA-QHRR-8Q5H-9Q3H

Vulnerability from github – Published: 2026-10-15 18:35 – Updated: 2026-10-15 18:35
VLAI
Summary
MessagePack: Nested arrays can blow past buffer length limits
Details

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.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.303"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T18:35:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "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\u2014an amplification factor of approximately 3,800\u2014before 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.",
  "id": "GHSA-qhrr-8q5h-9q3h",
  "modified": "2026-10-15T18:35:46Z",
  "published": "2026-10-15T18:35:46Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MessagePack: Nested arrays can blow past buffer length limits"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.