Summary
MessagePack-CSharp: Unity unsafe blit formatter allocates from unbounded byte length
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.
Affected components
- Package:
MessagePack.UnityClient - Resolvers:
UnityBlitResolver,UnityBlitWithPrimitiveArrayResolver - API:
UnsafeBlitFormatterBase<T>.Deserialize - Finding IDs:
MESSAGEPACKCSHARP-080, duplicate/open variantMESSAGEPACKCSHARP-OPEN-010
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 lengthMESSAGEPACKCSHARP-OPEN-010: duplicate/open finding for the same root cause- CWE-770: Allocation of Resources Without Limits or Throttling
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.
The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.
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
Fixes are prepared and will be released in coordinated patch versions.
Upgrade guidance:
- Upgrade
MessagePack.UnityClientto the patched version for your release line. - 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.
Frequently Asked Questions
- What is CVE-2026-48514? CVE-2026-48514 is a medium-severity allocation of resources without limits or throttling vulnerability in MessagePack (nuget), affecting versions < 2.5.301. It is fixed in 2.5.301, 3.1.7. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
- Which versions of MessagePack are affected by CVE-2026-48514? MessagePack (nuget) versions < 2.5.301 is affected.
- Is there a fix for CVE-2026-48514? Yes. CVE-2026-48514 is fixed in 2.5.301, 3.1.7. Upgrade to this version or later.
- Is CVE-2026-48514 exploitable, and should I be worried? Whether CVE-2026-48514 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-48514 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-48514?
- Upgrade
MessagePackto 2.5.301 or later - Upgrade
MessagePackto 3.1.7 or later
- Upgrade