GHSA-W567-GJR2-HM5J

Vulnerability from github – Published: 2026-06-25 21:25 – Updated: 2026-06-25 21:25
VLAI
Summary
MessagePack-CSharp: Unity unsafe blit formatter allocates from unbounded byte length
Details

Summary

UnsafeBlitFormatterBase<T>.Deserialize reads an attacker-controlled byteLength from an extension payload and allocates an array based on that value before validating it against the extension header length or remaining payload bytes.

The outer extension header is bounded by available input, but that bound is not used to constrain the inner byteLength before allocation. A very small payload can therefore request a very large T[] allocation.

Impact

Applications are affected when they deserialize untrusted payloads using Unity blit resolvers such as UnityBlitResolver or UnityBlitWithPrimitiveArrayResolver.

This is especially relevant to Unity multiplayer clients or servers that use MessagePack-CSharp for networked values such as vectors, matrices, or primitive arrays. A hostile peer can send an extension payload with a large declared byte length and cause an out-of-memory exception or process termination on memory-constrained platforms.

The resolver is opt-in, but the vulnerable value is pure wire input and the allocation happens before the formatter verifies that the declared bytes are actually present in the extension body.

Affected components

  • Package: MessagePack.UnityClient
  • Resolvers: UnityBlitResolver, UnityBlitWithPrimitiveArrayResolver
  • API: UnsafeBlitFormatterBase<T>.Deserialize
  • Finding IDs: MESSAGEPACKCSHARP-080, duplicate/open variant MESSAGEPACKCSHARP-OPEN-010

Patches

Fixes are prepared and will be released in coordinated patch versions.

Upgrade guidance:

  1. Upgrade MessagePack.UnityClient to the patched version for your release line.
  2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.

The fix should validate byteLength before allocation. It should reject negative lengths, lengths greater than the extension body length after metadata, and lengths that are not a valid multiple of the element size.

Workarounds

Patching is recommended.

Until a patched version is available, do not use Unity blit resolvers on data received from untrusted peers. Use safer resolvers or explicitly validate and size-limit messages before deserialization.

Resources

  • MESSAGEPACKCSHARP-080: unsafe blit formatter allocation from unbounded byte length
  • MESSAGEPACKCSHARP-OPEN-010: duplicate/open finding for the same root cause
  • CWE-770: Allocation of Resources Without Limits or Throttling
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.301"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48514"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T21:25:21Z",
    "nvd_published_at": "2026-06-22T22:16:48Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`UnsafeBlitFormatterBase\u003cT\u003e.Deserialize` reads an attacker-controlled `byteLength` from an extension payload and allocates an array based on that value before validating it against the extension header length or remaining payload bytes.\n\nThe outer extension header is bounded by available input, but that bound is not used to constrain the inner `byteLength` before allocation. A very small payload can therefore request a very large `T[]` allocation.\n\n## Impact\n\nApplications are affected when they deserialize untrusted payloads using Unity blit resolvers such as `UnityBlitResolver` or `UnityBlitWithPrimitiveArrayResolver`.\n\nThis is especially relevant to Unity multiplayer clients or servers that use MessagePack-CSharp for networked values such as vectors, matrices, or primitive arrays. A hostile peer can send an extension payload with a large declared byte length and cause an out-of-memory exception or process termination on memory-constrained platforms.\n\nThe resolver is opt-in, but the vulnerable value is pure wire input and the allocation happens before the formatter verifies that the declared bytes are actually present in the extension body.\n\n## Affected components\n\n- Package: `MessagePack.UnityClient`\n- Resolvers: `UnityBlitResolver`, `UnityBlitWithPrimitiveArrayResolver`\n- API: `UnsafeBlitFormatterBase\u003cT\u003e.Deserialize`\n- Finding IDs: `MESSAGEPACKCSHARP-080`, duplicate/open variant `MESSAGEPACKCSHARP-OPEN-010`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack.UnityClient` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should validate `byteLength` before allocation. It should reject negative lengths, lengths greater than the extension body length after metadata, and lengths that are not a valid multiple of the element size.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, do not use Unity blit resolvers on data received from untrusted peers. Use safer resolvers or explicitly validate and size-limit messages before deserialization.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-080`: unsafe blit formatter allocation from unbounded byte length\n- `MESSAGEPACKCSHARP-OPEN-010`: duplicate/open finding for the same root cause\n- CWE-770: Allocation of Resources Without Limits or Throttling",
  "id": "GHSA-w567-gjr2-hm5j",
  "modified": "2026-06-25T21:25:21Z",
  "published": "2026-06-25T21:25:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-w567-gjr2-hm5j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48514"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack-CSharp: Unity unsafe blit formatter allocates from unbounded byte length"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…