MessagePack

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.

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.

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.

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.

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.

Summary

MessagePack-CSharp's typeless deserialization includes MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed(Type) as a safety check for dangerous types. The default implementation checks the outer type name, but it does not recursively inspect array element types or generic type arguments.

As a result, a type that would be blocked directly can be wrapped inside an array or constructed generic type and pass the outer type check. The formatter machinery can then materialize formatters for the inner blocked type.

Impact

Applications are affected when they deserialize untrusted payloads using typeless serialization features such as MessagePackSerializer.Typeless, TypelessObjectResolver, or related typeless resolver options.

Typeless deserialization is already a high-risk feature for untrusted data, but the presence of a disallowed-type hook creates an expectation that blocked types remain blocked. This issue weakens that mitigation because the check is not applied structurally to nested type components. An attacker who can supply typeless ext-100 payloads may bypass exact outer-type blocklist checks by naming wrapper types such as arrays or generic containers.

The consequence depends on which type is reached and what the application allows typeless deserialization to instantiate. The original findings describe bypasses involving blocked or user-blocklisted gadget types.

Affected components

• Package: MessagePack
• Feature: typeless deserialization
• APIs: MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed, TypelessFormatter
• Finding IDs: MESSAGEPACKCSHARP-030, duplicate/open variant MESSAGEPACKCSHARP-OPEN-007

Patches

Fixes are available via versions 2.5.301 and 3.1.7.

Upgrade guidance:

1. Upgrade MessagePack 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 apply type-disallow checks recursively to array element types, pointer/byref element types where applicable, nullable underlying types, and constructed generic type arguments. Formatter paths that materialize types supplied by the wire should not instantiate inner types that fail the configured policy.

Workarounds

Patching is recommended.

Avoid typeless deserialization for untrusted data. If typeless support is unavoidable, configure an explicit allowlist that rejects any type not approved by the application and ensure the allowlist recursively validates array elements and generic arguments. Do not rely on exact outer-type blocklists as a complete security boundary.

Resources

• MESSAGEPACKCSHARP-030: typeless disallowed-type check is not recursive
• MESSAGEPACKCSHARP-OPEN-007: duplicate/open finding for typeless blocklist gaps
• CWE-502: Deserialization of Untrusted Data
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code

CVE split rationale

This vulnerability is independently fixable in typeless type-policy enforcement. It is separate from MVC default options, collection allocation, LZ4 decoding, and recursion-depth issues.

Summary

InterfaceLookupFormatter<TKey,TElement> constructs an internal Dictionary<TKey, IGrouping<TKey,TElement>> with the default equality comparer instead of the security-aware comparer supplied by options.Security.GetEqualityComparer<TKey>().

Other hash-based collection formatters use the security-aware comparer when MessagePackSecurity.UntrustedData is configured. This formatter omission allows hash-collision CPU denial of service against ILookup<TKey,TElement> even when the application has opted into the untrusted-data security posture.

Impact

Applications are affected when they deserialize untrusted payloads into schemas containing ILookup<TKey,TElement> with a key type for which attacker-controlled hash collisions are feasible.

Under the default comparer, many colliding keys can degrade dictionary insertion from amortized constant time to quadratic behavior. A payload of colliding keys can consume CPU for a disproportionate amount of time. This bypasses the mitigation that developers intentionally enabled by using MessagePackSecurity.UntrustedData.

Affected components

• Package: MessagePack
• API: InterfaceLookupFormatter<TKey,TElement>.Create
• Data type: ILookup<TKey,TElement>
• Finding ID: MESSAGEPACKCSHARP-041

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 create the internal dictionary with options.Security.GetEqualityComparer<TKey>(), matching the sibling dictionary and lookup formatter behavior.

Workarounds

Patching is recommended.

Until a patched version is available, avoid exposing ILookup<TKey,TElement> in DTOs that deserialize untrusted data. Use collection shapes that are already protected by the security-aware comparer path, or validate and cap collection sizes at the transport boundary.

Resources

• MESSAGEPACKCSHARP-041: InterfaceLookupFormatter missing security comparer
• CWE-407: Inefficient Algorithmic Complexity

Summary

MessagePack-CSharp's multi-dimensional array formatters read dimension lengths directly from the payload and allocate T[,], T[,,], or T[,,,] before validating that the dimension product matches the encoded element count.

The formatter reads a guarded element array header, but allocation of the target multi-dimensional array happens before the dimensions are checked against that element count. A small payload can therefore declare large dimensions, provide an empty or tiny inner array, and cause a large heap allocation before element data is validated.

Impact

Applications are affected when they deserialize untrusted MessagePack payloads into models containing multi-dimensional arrays such as T[,], T[,,], or T[,,,].

An attacker can encode large dimension integers and a small guarded element array. The formatter allocates the target array from the dimensions before confirming that the product of dimensions is consistent with the element count.

The result can be out-of-memory exceptions, container termination on memory-constrained hosts, large object heap pressure, or severe CPU cost from zero-initializing oversized arrays. MessagePackSecurity.UntrustedData does not provide a general allocation cap for this path.

Affected components

• Package: MessagePack
• APIs: TwoDimensionalArrayFormatter<T>.Deserialize, ThreeDimensionalArrayFormatter<T>.Deserialize, FourDimensionalArrayFormatter<T>.Deserialize
• Data shapes: T[,], T[,,], and T[,,,]
• Finding IDs: MESSAGEPACKCSHARP-040, duplicate/open variant MESSAGEPACKCSHARP-OPEN-003

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 dimensions before allocation. Dimension values should be non-negative, their checked product should match the encoded element count, and the product should be bounded by the available payload and any configured security limits before new T[...] is executed.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted payloads into schemas containing multi-dimensional arrays. Prefer schema shapes that can be validated before allocation, such as bounded lists, dictionaries with application-level count limits, or jagged arrays with application-level limits.

Message-size limits reduce the blast radius but do not fully address allocation amplification where a small payload can encode disproportionate array dimensions.

Resources

• MESSAGEPACKCSHARP-040: unchecked multi-dimensional array dimensions
• MESSAGEPACKCSHARP-OPEN-003: duplicate/open finding for the multi-dimensional array issue
• CWE-770: Allocation of Resources Without Limits or Throttling

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

Summary

Runtime-generated union deserializers emitted by DynamicUnionResolver do not call MessagePackSecurity.DepthStep(ref reader) and do not decrement reader.Depth around recursive deserialization and skip paths.

This means union deserialization does not consistently participate in the maximum object graph depth enforcement that protects other recursive formatter paths. For unknown union keys, the emitted deserializer calls reader.Skip() on attacker-controlled data without an enclosing depth step.

Impact

Applications are affected when they deserialize untrusted payloads into object graphs containing [Union]-decorated interfaces or abstract classes handled by DynamicUnionResolver.

An attacker can provide a union payload with an unknown key and a deeply nested value. Because the generated union formatter does not enter the depth accounting scope before skipping or recursively processing the value, configured depth limits can be bypassed. In combination with recursive skip behavior, this can terminate the process with an uncatchable StackOverflowException.

This issue is narrower than the general TrySkip() recursion issue because it specifically concerns a formatter-generation path that fails to count union nesting. It remains independently fixable because the emitted IL should mirror the depth-step behavior used by source-generated union formatters and dynamic object formatters.

Affected components

• Package: MessagePack
• API: DynamicUnionResolver.BuildDeserialize
• Data types: [Union]-decorated interface and abstract class hierarchies handled by the dynamic resolver
• Finding ID: MESSAGEPACKCSHARP-070

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 emit DepthStep and matching reader.Depth-- cleanup in dynamic union deserializers, consistent with other recursive formatter implementations.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted payloads into dynamically resolved [Union] types. Prefer source-generated formatters that include depth checks, where applicable, and enforce outer message-size and schema constraints.

Resources

• MESSAGEPACKCSHARP-070: dynamic union deserializer missing depth-step enforcement
• CWE-674: Uncontrolled Recursion

Summary

MessagePack-CSharp's JSON conversion helpers contain multiple recursion paths that do not consistently enforce a depth limit. These paths are in the JSON conversion component rather than normal typed MessagePack deserialization.

Three related issues are covered by this advisory:

1. MessagePackSerializer.ConvertFromJson recursively processes nested JSON arrays and objects in FromJsonCore() without consulting MessagePackSecurity.MaximumObjectGraphDepth.
2. TinyJsonReader.ReadNextToken() recursively consumes comma and colon separator characters, allowing even malformed JSON with long separator runs to consume one stack frame per character.
3. MessagePackSerializer.ConvertToJson applies depth checks to arrays and maps, but the typeless extension branch for ext-100 recursively calls ToJsonCore() without applying MessagePackSecurity.DepthStep(ref reader).

Each path can allow attacker-controlled input to exhaust the process stack and trigger an uncatchable StackOverflowException instead of failing with a catchable parse or serialization exception.

Impact

Applications are affected when they call MessagePack-CSharp JSON conversion APIs on attacker-controlled data. This includes gateways, diagnostics endpoints, migration tools, logging paths, and services that convert between external JSON and MessagePack payloads.

For JSON-to-MessagePack conversion, deeply nested JSON arrays or objects can recurse through FromJsonCore() without applying the configured object graph depth limit. Separately, long runs of comma or colon separator characters can recurse through TinyJsonReader.ReadNextToken() before normal structural validation rejects the input.

For MessagePack-to-JSON conversion, nested typeless extension wrappers can recurse through ToJsonCore() without the depth guard that the same function applies to arrays and maps.

MessagePackSecurity.UntrustedData does not fully mitigate these conversion paths because the missing checks occur inside JSON conversion and tokenization branches that do not consistently use the configured depth policy.

Affected components

• Package: MessagePack
• APIs: MessagePackSerializer.ConvertFromJson, MessagePackSerializer.ConvertToJson
• Internal routines: FromJsonCore, ToJsonCore, TinyJsonReader.ReadNextToken
• Data shapes: deeply nested JSON arrays/objects, long JSON separator runs, and nested typeless MessagePack extension values converted to JSON
• Finding IDs: MESSAGEPACKCSHARP-090, MESSAGEPACKCSHARP-091, MESSAGEPACKCSHARP-092

Patches

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

Upgrade guidance:

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

The JSON-to-MessagePack fix should add explicit JSON nesting-depth accounting to FromJsonCore, using the configured maximum object graph depth or an equivalent limit, or rewrite the conversion to use an iterative bounded stack.

The tokenizer fix should replace separator self-recursion in TinyJsonReader.ReadNextToken() with an iterative loop so consecutive commas, colons, and whitespace do not consume stack frames.

The MessagePack-to-JSON fix should apply DepthStep and matching reader.Depth-- cleanup around recursive ToJsonCore() calls made from the typeless extension branch, consistent with the existing array and map conversion branches.

Workarounds

Patching is recommended.

Until a patched version is available, do not pass untrusted JSON directly to ConvertFromJson, and do not call ConvertToJson on untrusted MessagePack payloads that may contain typeless extension values. Validate JSON nesting depth with a parser that enforces depth limits before calling MessagePack-CSharp, reject malformed JSON before conversion, and apply strict input-size limits.

Input-size limits reduce exposure but do not remove the recursive behavior in affected versions.

References

• MESSAGEPACKCSHARP-090: ConvertFromJson unbounded structural recursion
• MESSAGEPACKCSHARP-091: TinyJsonReader.ReadNextToken separator self-recursion
• MESSAGEPACKCSHARP-092: ConvertToJson ext-100 branch missing depth enforcement
• CWE-674: Uncontrolled Recursion

CVE split rationale

These issues are grouped because they affect the same JSON conversion feature area and share the same failure mode: recursive conversion/tokenization paths do not consistently enforce depth or iteration bounds for attacker-controlled input. They are distinct from normal binary MessagePack skip recursion, dynamic union formatter depth accounting, DateTime stack allocation, and allocation-oriented denial-of-service issues.

Summary

ExpandoObjectFormatter.Deserialize populates System.Dynamic.ExpandoObject by calling IDictionary<string, object>.Add for each map entry. ExpandoObject internally maintains member names in array-like structures, so inserting many distinct keys can require repeated linear scans and array copies.

For large attacker-controlled maps, this produces quadratic CPU and allocation behavior. The issue is especially surprising because ExpandoObjectResolver.Options is configured with MessagePackSecurity.UntrustedData, but collision-resistant dictionary comparers cannot protect ExpandoObject insertion internals.

Impact

Applications are affected when they deserialize untrusted MessagePack maps into ExpandoObject using ExpandoObjectResolver or related resolver options.

A hostile payload containing many distinct keys can cause CPU exhaustion and allocation churn disproportionate to the input size. This can make a server unresponsive or exhaust memory under concurrent request load.

This is not a hash-collision attack against a configurable dictionary comparer. The super-linear behavior comes from ExpandoObject's insertion model, so MessagePackSecurity.UntrustedData does not eliminate the cost.

Affected components

• Package: MessagePack
• APIs: ExpandoObjectFormatter.Deserialize, ExpandoObjectResolver
• Data type: System.Dynamic.ExpandoObject
• Finding ID: MESSAGEPACKCSHARP-102

Patches

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

Upgrade guidance:

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

Potential fixes include applying a map-entry count limit for ExpandoObject under untrusted-data settings, buffering into a security-aware dictionary before materializing a bounded ExpandoObject, or otherwise rejecting maps large enough to trigger quadratic behavior.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted payloads into ExpandoObject. Prefer strongly typed DTOs or dictionaries with security-aware comparers and explicit count limits. Enforce request-size and map-entry limits at the transport or application layer.

Resources

• MESSAGEPACKCSHARP-102: ExpandoObjectFormatter quadratic insertion behavior
• CWE-407: Inefficient Algorithmic Complexity

Summary

When MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable.

A small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins.

Impact

Applications are affected when they deserialize attacker-controlled MessagePack payloads with MessagePackCompression.Lz4Block or MessagePackCompression.Lz4BlockArray enabled.

In the Lz4Block case, an attacker-controlled integer is used to request the destination span. In the Lz4BlockArray case, per-block uncompressed lengths and their aggregate can be attacker-controlled. Without a cap, the declared output size can be disproportionate to the input size, producing out-of-memory exceptions, process termination on constrained hosts, or severe memory pressure.

This advisory is about unbounded allocation from declared decompressed sizes. It is separate from the LZ4 source-buffer over-read issue, which concerns unsafe decoder reads beyond the compressed input buffer.

Affected components

• Package: MessagePack
• Feature: LZ4 compressed MessagePack payloads
• APIs: MessagePackSerializer with WithCompression(MessagePackCompression.Lz4Block) or WithCompression(MessagePackCompression.Lz4BlockArray)
• Internal routine: MessagePackSerializer.TryDecompress
• Finding ID: MESSAGEPACKCSHARP-OPEN-004

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 reject negative and excessive uncompressed lengths before allocation. It should also cap aggregate decompressed size for block arrays and expose or honor an appropriate maximum decompressed length policy.

Workarounds

Patching is recommended.

Until a patched version is available, do not enable MessagePack-CSharp's built-in LZ4 compression modes for untrusted inputs. If compression is required, enforce strict compressed and decompressed size limits outside MessagePack-CSharp before deserialization.

Resources

• MESSAGEPACKCSHARP-OPEN-004: LZ4 decompression allocation from unbounded uncompressed length
• MESSAGEPACKCSHARP-011: duplicate decompression-bomb finding
• CWE-409: Improper Handling of Highly Compressed Data
• CWE-770: Allocation of Resources Without Limits or Throttling

Summary

The parameterless MessagePackInputFormatter() constructor uses default serializer options, which resolve to MessagePackSerializerOptions.Standard with MessagePackSecurity.TrustedData. The formatter is designed for ASP.NET Core MVC request bodies, which commonly cross an HTTP trust boundary.

This insecure default can expose applications to denial-of-service attacks that MessagePackSecurity.UntrustedData is intended to mitigate, such as hash-collision attacks against dictionary-like model properties.

Impact

Applications are affected when they register new MessagePackInputFormatter() without explicitly passing serializer options configured for untrusted data.

An unauthenticated or otherwise untrusted HTTP client can send MessagePack request bodies that are deserialized using the trusted-data posture. For models containing hash-based collections, this can enable algorithmic complexity attacks using colliding keys. The default constructor makes the unsafe posture easy to use at the exact boundary where request bodies should be treated as untrusted.

Affected components

• Package: MessagePack.AspNetCoreMvcFormatter
• API: MessagePackInputFormatter() parameterless constructor
• Scenario: ASP.NET Core MVC model binding from HTTP request bodies
• Finding IDs: MESSAGEPACKCSHARP-OPEN-009, duplicate MESSAGEPACKCSHARP-095

Patches

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

Upgrade guidance:

1. Upgrade MessagePack.AspNetCoreMvcFormatter 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 default the parameterless constructor to MessagePackSerializerOptions.Standard.WithSecurity(MessagePackSecurity.UntrustedData), or require callers to pass explicit options so the trust posture is deliberate.

Workarounds

Do not use the parameterless constructor on affected versions. Register the formatter with explicit untrusted-data options, for example:

options.InputFormatters.Add(
    new MessagePackInputFormatter(
        MessagePackSerializerOptions.Standard.WithSecurity(MessagePackSecurity.UntrustedData)));

Also apply normal HTTP request-size limits and model validation appropriate for your service.

Resources

• MESSAGEPACKCSHARP-OPEN-009: MVC input formatter defaults to trusted-data security posture
• MESSAGEPACKCSHARP-095: duplicate finding for the same root cause
• CWE-1188: Initialization of a Resource with an Insecure Default

Summary

MessagePackReader.TrySkip() recursively descends into nested arrays and maps without incrementing the reader depth or calling the configured depth checks. This bypasses MessagePackSecurity.MaximumObjectGraphDepth, the library's documented protection against deeply nested object graphs.

Many generated and dynamic formatters call reader.Skip() when they encounter unknown map keys, unknown array members, ignored fields, or data that should be skipped for forward compatibility. A deeply nested value in one of these skipped positions can therefore cause unbounded recursion and an uncatchable StackOverflowException.

Impact

Applications that deserialize untrusted MessagePack payloads are affected when a formatter skips attacker-controlled values. This is a broad deserialization path and can be reached during normal object deserialization when an input includes an unknown member or extra value.

The attacker does not need to target a special resolver or compression mode. A payload containing many nested single-element arrays or maps in a skipped location can exhaust the process stack. Because StackOverflowException is not catchable in normal .NET execution, this terminates the host process and can deny service to other users of the same process.

MessagePackSecurity.UntrustedData does not mitigate this issue because the skip path does not participate in depth accounting.

Affected components

• Package: MessagePack
• APIs: MessagePackReader.Skip, MessagePackReader.TrySkip, and formatter paths that skip unknown or ignored values
• Finding IDs: MESSAGEPACKCSHARP-021, duplicate/open variant MESSAGEPACKCSHARP-OPEN-001

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 either make skip traversal iterative or apply the existing depth accounting to arrays and maps encountered by TrySkip(). Any exceeded depth limit should result in a catchable serialization exception instead of process stack exhaustion.

Workarounds

Patching is recommended.

There is no complete workaround for applications that deserialize untrusted MessagePack payloads with affected versions. Reducing accepted message sizes can raise the cost of exploitation but does not remove the recursive skip behavior. Strict schema validation outside MessagePack-CSharp may help only if it rejects unknown or skipped fields before the serializer sees them.

Resources

• MESSAGEPACKCSHARP-021: unbounded recursion in TrySkip()
• MESSAGEPACKCSHARP-OPEN-001: duplicate/open finding for the same root cause
• CWE-674: Uncontrolled Recursion

CVE split rationale

This vulnerability is independently fixable in the skip traversal implementation. It should be tracked separately from formatter-specific missing depth checks, JSON conversion recursion, and non-recursion allocation bugs.

Impact

A vulnerability exists in the optional LZ4 decompression path used by MessagePack compression modes Lz4Block and Lz4BlockArray.

The decoder implementation is based on a deprecated fast-decompression algorithm that does not take a source-length bound. A remote attacker can send a crafted MessagePack payload with manipulated LZ4 token/length fields to force out-of-bounds reads from the compressed input buffer. In affected environments, this can trigger an AccessViolationException during decompression, causing process termination (denial of service). Under some conditions, limited unintended memory disclosure from over-read data may also be possible before failure.

This issue affects applications that deserialize untrusted data while LZ4 compression is enabled.

Patches

The v2 versions are patched as of 2.5.301. The v3 versions are patched as of 3.1.7.

Workarounds

Instead of upgrading, an application may take the following precautions:

1. Disable LZ4 compression for untrusted input paths (Lz4Block, Lz4BlockArray).
2. Only accept compressed payloads from strongly trusted producers.
3. Isolate deserialization in a separate process/container with restart supervision to limit availability impact.

Resources

• MESSAGEPACKCSHARP-010

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.

Summary

MessagePack-CSharp's typeless deserialization includes MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed(Type) as a safety check for dangerous types. The default implementation checks the outer type name, but it does not recursively inspect array element types or generic type arguments.

As a result, a type that would be blocked directly can be wrapped inside an array or constructed generic type and pass the outer type check. The formatter machinery can then materialize formatters for the inner blocked type.

Impact

Applications are affected when they deserialize untrusted payloads using typeless serialization features such as MessagePackSerializer.Typeless, TypelessObjectResolver, or related typeless resolver options.

Typeless deserialization is already a high-risk feature for untrusted data, but the presence of a disallowed-type hook creates an expectation that blocked types remain blocked. This issue weakens that mitigation because the check is not applied structurally to nested type components. An attacker who can supply typeless ext-100 payloads may bypass exact outer-type blocklist checks by naming wrapper types such as arrays or generic containers.

The consequence depends on which type is reached and what the application allows typeless deserialization to instantiate. The original findings describe bypasses involving blocked or user-blocklisted gadget types.

Affected components

• Package: MessagePack
• Feature: typeless deserialization
• APIs: MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed, TypelessFormatter
• Finding IDs: MESSAGEPACKCSHARP-030, duplicate/open variant MESSAGEPACKCSHARP-OPEN-007

Patches

Fixes are available via versions 2.5.301 and 3.1.7.

Upgrade guidance:

1. Upgrade MessagePack 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 apply type-disallow checks recursively to array element types, pointer/byref element types where applicable, nullable underlying types, and constructed generic type arguments. Formatter paths that materialize types supplied by the wire should not instantiate inner types that fail the configured policy.

Workarounds

Patching is recommended.

Avoid typeless deserialization for untrusted data. If typeless support is unavoidable, configure an explicit allowlist that rejects any type not approved by the application and ensure the allowlist recursively validates array elements and generic arguments. Do not rely on exact outer-type blocklists as a complete security boundary.

Resources

• MESSAGEPACKCSHARP-030: typeless disallowed-type check is not recursive
• MESSAGEPACKCSHARP-OPEN-007: duplicate/open finding for typeless blocklist gaps
• CWE-502: Deserialization of Untrusted Data
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code

CVE split rationale

This vulnerability is independently fixable in typeless type-policy enforcement. It is separate from MVC default options, collection allocation, LZ4 decoding, and recursion-depth issues.

Summary

InterfaceLookupFormatter<TKey,TElement> constructs an internal Dictionary<TKey, IGrouping<TKey,TElement>> with the default equality comparer instead of the security-aware comparer supplied by options.Security.GetEqualityComparer<TKey>().

Other hash-based collection formatters use the security-aware comparer when MessagePackSecurity.UntrustedData is configured. This formatter omission allows hash-collision CPU denial of service against ILookup<TKey,TElement> even when the application has opted into the untrusted-data security posture.

Impact

Applications are affected when they deserialize untrusted payloads into schemas containing ILookup<TKey,TElement> with a key type for which attacker-controlled hash collisions are feasible.

Under the default comparer, many colliding keys can degrade dictionary insertion from amortized constant time to quadratic behavior. A payload of colliding keys can consume CPU for a disproportionate amount of time. This bypasses the mitigation that developers intentionally enabled by using MessagePackSecurity.UntrustedData.

Affected components

• Package: MessagePack
• API: InterfaceLookupFormatter<TKey,TElement>.Create
• Data type: ILookup<TKey,TElement>
• Finding ID: MESSAGEPACKCSHARP-041

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 create the internal dictionary with options.Security.GetEqualityComparer<TKey>(), matching the sibling dictionary and lookup formatter behavior.

Workarounds

Patching is recommended.

Until a patched version is available, avoid exposing ILookup<TKey,TElement> in DTOs that deserialize untrusted data. Use collection shapes that are already protected by the security-aware comparer path, or validate and cap collection sizes at the transport boundary.

Resources

• MESSAGEPACKCSHARP-041: InterfaceLookupFormatter missing security comparer
• CWE-407: Inefficient Algorithmic Complexity

Summary

MessagePack-CSharp's multi-dimensional array formatters read dimension lengths directly from the payload and allocate T[,], T[,,], or T[,,,] before validating that the dimension product matches the encoded element count.

The formatter reads a guarded element array header, but allocation of the target multi-dimensional array happens before the dimensions are checked against that element count. A small payload can therefore declare large dimensions, provide an empty or tiny inner array, and cause a large heap allocation before element data is validated.

Impact

Applications are affected when they deserialize untrusted MessagePack payloads into models containing multi-dimensional arrays such as T[,], T[,,], or T[,,,].

An attacker can encode large dimension integers and a small guarded element array. The formatter allocates the target array from the dimensions before confirming that the product of dimensions is consistent with the element count.

The result can be out-of-memory exceptions, container termination on memory-constrained hosts, large object heap pressure, or severe CPU cost from zero-initializing oversized arrays. MessagePackSecurity.UntrustedData does not provide a general allocation cap for this path.

Affected components

• Package: MessagePack
• APIs: TwoDimensionalArrayFormatter<T>.Deserialize, ThreeDimensionalArrayFormatter<T>.Deserialize, FourDimensionalArrayFormatter<T>.Deserialize
• Data shapes: T[,], T[,,], and T[,,,]
• Finding IDs: MESSAGEPACKCSHARP-040, duplicate/open variant MESSAGEPACKCSHARP-OPEN-003

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 dimensions before allocation. Dimension values should be non-negative, their checked product should match the encoded element count, and the product should be bounded by the available payload and any configured security limits before new T[...] is executed.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted payloads into schemas containing multi-dimensional arrays. Prefer schema shapes that can be validated before allocation, such as bounded lists, dictionaries with application-level count limits, or jagged arrays with application-level limits.

Message-size limits reduce the blast radius but do not fully address allocation amplification where a small payload can encode disproportionate array dimensions.

Resources

• MESSAGEPACKCSHARP-040: unchecked multi-dimensional array dimensions
• MESSAGEPACKCSHARP-OPEN-003: duplicate/open finding for the multi-dimensional array issue
• CWE-770: Allocation of Resources Without Limits or Throttling

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

Summary

Runtime-generated union deserializers emitted by DynamicUnionResolver do not call MessagePackSecurity.DepthStep(ref reader) and do not decrement reader.Depth around recursive deserialization and skip paths.

This means union deserialization does not consistently participate in the maximum object graph depth enforcement that protects other recursive formatter paths. For unknown union keys, the emitted deserializer calls reader.Skip() on attacker-controlled data without an enclosing depth step.

Impact

Applications are affected when they deserialize untrusted payloads into object graphs containing [Union]-decorated interfaces or abstract classes handled by DynamicUnionResolver.

An attacker can provide a union payload with an unknown key and a deeply nested value. Because the generated union formatter does not enter the depth accounting scope before skipping or recursively processing the value, configured depth limits can be bypassed. In combination with recursive skip behavior, this can terminate the process with an uncatchable StackOverflowException.

This issue is narrower than the general TrySkip() recursion issue because it specifically concerns a formatter-generation path that fails to count union nesting. It remains independently fixable because the emitted IL should mirror the depth-step behavior used by source-generated union formatters and dynamic object formatters.

Affected components

• Package: MessagePack
• API: DynamicUnionResolver.BuildDeserialize
• Data types: [Union]-decorated interface and abstract class hierarchies handled by the dynamic resolver
• Finding ID: MESSAGEPACKCSHARP-070

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 emit DepthStep and matching reader.Depth-- cleanup in dynamic union deserializers, consistent with other recursive formatter implementations.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted payloads into dynamically resolved [Union] types. Prefer source-generated formatters that include depth checks, where applicable, and enforce outer message-size and schema constraints.

Resources

• MESSAGEPACKCSHARP-070: dynamic union deserializer missing depth-step enforcement
• CWE-674: Uncontrolled Recursion

Summary

MessagePack-CSharp's JSON conversion helpers contain multiple recursion paths that do not consistently enforce a depth limit. These paths are in the JSON conversion component rather than normal typed MessagePack deserialization.

Three related issues are covered by this advisory:

1. MessagePackSerializer.ConvertFromJson recursively processes nested JSON arrays and objects in FromJsonCore() without consulting MessagePackSecurity.MaximumObjectGraphDepth.
2. TinyJsonReader.ReadNextToken() recursively consumes comma and colon separator characters, allowing even malformed JSON with long separator runs to consume one stack frame per character.
3. MessagePackSerializer.ConvertToJson applies depth checks to arrays and maps, but the typeless extension branch for ext-100 recursively calls ToJsonCore() without applying MessagePackSecurity.DepthStep(ref reader).

Each path can allow attacker-controlled input to exhaust the process stack and trigger an uncatchable StackOverflowException instead of failing with a catchable parse or serialization exception.

Impact

Applications are affected when they call MessagePack-CSharp JSON conversion APIs on attacker-controlled data. This includes gateways, diagnostics endpoints, migration tools, logging paths, and services that convert between external JSON and MessagePack payloads.

For JSON-to-MessagePack conversion, deeply nested JSON arrays or objects can recurse through FromJsonCore() without applying the configured object graph depth limit. Separately, long runs of comma or colon separator characters can recurse through TinyJsonReader.ReadNextToken() before normal structural validation rejects the input.

For MessagePack-to-JSON conversion, nested typeless extension wrappers can recurse through ToJsonCore() without the depth guard that the same function applies to arrays and maps.

MessagePackSecurity.UntrustedData does not fully mitigate these conversion paths because the missing checks occur inside JSON conversion and tokenization branches that do not consistently use the configured depth policy.

Affected components

• Package: MessagePack
• APIs: MessagePackSerializer.ConvertFromJson, MessagePackSerializer.ConvertToJson
• Internal routines: FromJsonCore, ToJsonCore, TinyJsonReader.ReadNextToken
• Data shapes: deeply nested JSON arrays/objects, long JSON separator runs, and nested typeless MessagePack extension values converted to JSON
• Finding IDs: MESSAGEPACKCSHARP-090, MESSAGEPACKCSHARP-091, MESSAGEPACKCSHARP-092

Patches

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

Upgrade guidance:

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

The JSON-to-MessagePack fix should add explicit JSON nesting-depth accounting to FromJsonCore, using the configured maximum object graph depth or an equivalent limit, or rewrite the conversion to use an iterative bounded stack.

The tokenizer fix should replace separator self-recursion in TinyJsonReader.ReadNextToken() with an iterative loop so consecutive commas, colons, and whitespace do not consume stack frames.

The MessagePack-to-JSON fix should apply DepthStep and matching reader.Depth-- cleanup around recursive ToJsonCore() calls made from the typeless extension branch, consistent with the existing array and map conversion branches.

Workarounds

Patching is recommended.

Until a patched version is available, do not pass untrusted JSON directly to ConvertFromJson, and do not call ConvertToJson on untrusted MessagePack payloads that may contain typeless extension values. Validate JSON nesting depth with a parser that enforces depth limits before calling MessagePack-CSharp, reject malformed JSON before conversion, and apply strict input-size limits.

Input-size limits reduce exposure but do not remove the recursive behavior in affected versions.

References

• MESSAGEPACKCSHARP-090: ConvertFromJson unbounded structural recursion
• MESSAGEPACKCSHARP-091: TinyJsonReader.ReadNextToken separator self-recursion
• MESSAGEPACKCSHARP-092: ConvertToJson ext-100 branch missing depth enforcement
• CWE-674: Uncontrolled Recursion

CVE split rationale

These issues are grouped because they affect the same JSON conversion feature area and share the same failure mode: recursive conversion/tokenization paths do not consistently enforce depth or iteration bounds for attacker-controlled input. They are distinct from normal binary MessagePack skip recursion, dynamic union formatter depth accounting, DateTime stack allocation, and allocation-oriented denial-of-service issues.

Summary

ExpandoObjectFormatter.Deserialize populates System.Dynamic.ExpandoObject by calling IDictionary<string, object>.Add for each map entry. ExpandoObject internally maintains member names in array-like structures, so inserting many distinct keys can require repeated linear scans and array copies.

For large attacker-controlled maps, this produces quadratic CPU and allocation behavior. The issue is especially surprising because ExpandoObjectResolver.Options is configured with MessagePackSecurity.UntrustedData, but collision-resistant dictionary comparers cannot protect ExpandoObject insertion internals.

Impact

Applications are affected when they deserialize untrusted MessagePack maps into ExpandoObject using ExpandoObjectResolver or related resolver options.

A hostile payload containing many distinct keys can cause CPU exhaustion and allocation churn disproportionate to the input size. This can make a server unresponsive or exhaust memory under concurrent request load.

This is not a hash-collision attack against a configurable dictionary comparer. The super-linear behavior comes from ExpandoObject's insertion model, so MessagePackSecurity.UntrustedData does not eliminate the cost.

Affected components

• Package: MessagePack
• APIs: ExpandoObjectFormatter.Deserialize, ExpandoObjectResolver
• Data type: System.Dynamic.ExpandoObject
• Finding ID: MESSAGEPACKCSHARP-102

Patches

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

Upgrade guidance:

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

Potential fixes include applying a map-entry count limit for ExpandoObject under untrusted-data settings, buffering into a security-aware dictionary before materializing a bounded ExpandoObject, or otherwise rejecting maps large enough to trigger quadratic behavior.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted payloads into ExpandoObject. Prefer strongly typed DTOs or dictionaries with security-aware comparers and explicit count limits. Enforce request-size and map-entry limits at the transport or application layer.

Resources

• MESSAGEPACKCSHARP-102: ExpandoObjectFormatter quadratic insertion behavior
• CWE-407: Inefficient Algorithmic Complexity

Summary

When MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable.

A small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins.

Impact

Applications are affected when they deserialize attacker-controlled MessagePack payloads with MessagePackCompression.Lz4Block or MessagePackCompression.Lz4BlockArray enabled.

In the Lz4Block case, an attacker-controlled integer is used to request the destination span. In the Lz4BlockArray case, per-block uncompressed lengths and their aggregate can be attacker-controlled. Without a cap, the declared output size can be disproportionate to the input size, producing out-of-memory exceptions, process termination on constrained hosts, or severe memory pressure.

This advisory is about unbounded allocation from declared decompressed sizes. It is separate from the LZ4 source-buffer over-read issue, which concerns unsafe decoder reads beyond the compressed input buffer.

Affected components

• Package: MessagePack
• Feature: LZ4 compressed MessagePack payloads
• APIs: MessagePackSerializer with WithCompression(MessagePackCompression.Lz4Block) or WithCompression(MessagePackCompression.Lz4BlockArray)
• Internal routine: MessagePackSerializer.TryDecompress
• Finding ID: MESSAGEPACKCSHARP-OPEN-004

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 reject negative and excessive uncompressed lengths before allocation. It should also cap aggregate decompressed size for block arrays and expose or honor an appropriate maximum decompressed length policy.

Workarounds

Patching is recommended.

Until a patched version is available, do not enable MessagePack-CSharp's built-in LZ4 compression modes for untrusted inputs. If compression is required, enforce strict compressed and decompressed size limits outside MessagePack-CSharp before deserialization.

Resources

• MESSAGEPACKCSHARP-OPEN-004: LZ4 decompression allocation from unbounded uncompressed length
• MESSAGEPACKCSHARP-011: duplicate decompression-bomb finding
• CWE-409: Improper Handling of Highly Compressed Data
• CWE-770: Allocation of Resources Without Limits or Throttling

Summary

The parameterless MessagePackInputFormatter() constructor uses default serializer options, which resolve to MessagePackSerializerOptions.Standard with MessagePackSecurity.TrustedData. The formatter is designed for ASP.NET Core MVC request bodies, which commonly cross an HTTP trust boundary.

This insecure default can expose applications to denial-of-service attacks that MessagePackSecurity.UntrustedData is intended to mitigate, such as hash-collision attacks against dictionary-like model properties.

Impact

Applications are affected when they register new MessagePackInputFormatter() without explicitly passing serializer options configured for untrusted data.

An unauthenticated or otherwise untrusted HTTP client can send MessagePack request bodies that are deserialized using the trusted-data posture. For models containing hash-based collections, this can enable algorithmic complexity attacks using colliding keys. The default constructor makes the unsafe posture easy to use at the exact boundary where request bodies should be treated as untrusted.

Affected components

• Package: MessagePack.AspNetCoreMvcFormatter
• API: MessagePackInputFormatter() parameterless constructor
• Scenario: ASP.NET Core MVC model binding from HTTP request bodies
• Finding IDs: MESSAGEPACKCSHARP-OPEN-009, duplicate MESSAGEPACKCSHARP-095

Patches

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

Upgrade guidance:

1. Upgrade MessagePack.AspNetCoreMvcFormatter 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 default the parameterless constructor to MessagePackSerializerOptions.Standard.WithSecurity(MessagePackSecurity.UntrustedData), or require callers to pass explicit options so the trust posture is deliberate.

Workarounds

Do not use the parameterless constructor on affected versions. Register the formatter with explicit untrusted-data options, for example:

options.InputFormatters.Add(
    new MessagePackInputFormatter(
        MessagePackSerializerOptions.Standard.WithSecurity(MessagePackSecurity.UntrustedData)));

Also apply normal HTTP request-size limits and model validation appropriate for your service.

Resources

• MESSAGEPACKCSHARP-OPEN-009: MVC input formatter defaults to trusted-data security posture
• MESSAGEPACKCSHARP-095: duplicate finding for the same root cause
• CWE-1188: Initialization of a Resource with an Insecure Default

Summary

MessagePackReader.TrySkip() recursively descends into nested arrays and maps without incrementing the reader depth or calling the configured depth checks. This bypasses MessagePackSecurity.MaximumObjectGraphDepth, the library's documented protection against deeply nested object graphs.

Many generated and dynamic formatters call reader.Skip() when they encounter unknown map keys, unknown array members, ignored fields, or data that should be skipped for forward compatibility. A deeply nested value in one of these skipped positions can therefore cause unbounded recursion and an uncatchable StackOverflowException.

Impact

Applications that deserialize untrusted MessagePack payloads are affected when a formatter skips attacker-controlled values. This is a broad deserialization path and can be reached during normal object deserialization when an input includes an unknown member or extra value.

The attacker does not need to target a special resolver or compression mode. A payload containing many nested single-element arrays or maps in a skipped location can exhaust the process stack. Because StackOverflowException is not catchable in normal .NET execution, this terminates the host process and can deny service to other users of the same process.

MessagePackSecurity.UntrustedData does not mitigate this issue because the skip path does not participate in depth accounting.

Affected components

• Package: MessagePack
• APIs: MessagePackReader.Skip, MessagePackReader.TrySkip, and formatter paths that skip unknown or ignored values
• Finding IDs: MESSAGEPACKCSHARP-021, duplicate/open variant MESSAGEPACKCSHARP-OPEN-001

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 either make skip traversal iterative or apply the existing depth accounting to arrays and maps encountered by TrySkip(). Any exceeded depth limit should result in a catchable serialization exception instead of process stack exhaustion.

Workarounds

Patching is recommended.

There is no complete workaround for applications that deserialize untrusted MessagePack payloads with affected versions. Reducing accepted message sizes can raise the cost of exploitation but does not remove the recursive skip behavior. Strict schema validation outside MessagePack-CSharp may help only if it rejects unknown or skipped fields before the serializer sees them.

Resources

• MESSAGEPACKCSHARP-021: unbounded recursion in TrySkip()
• MESSAGEPACKCSHARP-OPEN-001: duplicate/open finding for the same root cause
• CWE-674: Uncontrolled Recursion

CVE split rationale

This vulnerability is independently fixable in the skip traversal implementation. It should be tracked separately from formatter-specific missing depth checks, JSON conversion recursion, and non-recursion allocation bugs.

Summary

MessagePackReader.ReadDateTime() can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed tokenSize includes the extension body length from the wire and is used in a stackalloc operation before the extension length is validated as one of the valid timestamp sizes.

A very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable StackOverflowException, terminating the host process.

Impact

Applications are affected when they deserialize untrusted payloads into types containing DateTime values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.

MessagePackSecurity.UntrustedData and MaximumObjectGraphDepth do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.

An attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.

Affected components

• Package: MessagePack
• API: MessagePackReader.ReadDateTime
• Data types: DateTime and formatter paths that call ReadDateTime
• Finding IDs: MESSAGEPACKCSHARP-020, related stack allocation finding MESSAGEPACKCSHARP-CROW-MEM-001

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain DateTime or DateTimeOffset values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.

There is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.

Resources

• MESSAGEPACKCSHARP-020: ReadDateTime stack allocation from attacker-controlled extension length
• MESSAGEPACKCSHARP-CROW-MEM-001: related attacker-controlled stack allocation finding in MessagePackReader
• CWE-770: Allocation of Resources Without Limits or Throttling

CVE split rationale

This vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.

Impact

A vulnerability exists in the optional LZ4 decompression path used by MessagePack compression modes Lz4Block and Lz4BlockArray.

The decoder implementation is based on a deprecated fast-decompression algorithm that does not take a source-length bound. A remote attacker can send a crafted MessagePack payload with manipulated LZ4 token/length fields to force out-of-bounds reads from the compressed input buffer. In affected environments, this can trigger an AccessViolationException during decompression, causing process termination (denial of service). Under some conditions, limited unintended memory disclosure from over-read data may also be possible before failure.

This issue affects applications that deserialize untrusted data while LZ4 compression is enabled.

Patches

The v2 versions are patched as of 2.5.301. The v3 versions are patched as of 3.1.7.

Workarounds

Instead of upgrading, an application may take the following precautions:

1. Disable LZ4 compression for untrusted input paths (Lz4Block, Lz4BlockArray).
2. Only accept compressed payloads from strongly trusted producers.
3. Isolate deserialization in a separate process/container with restart supervision to limit availability impact.

Resources

• MESSAGEPACKCSHARP-010

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.

Summary

MessagePack-CSharp's typeless deserialization includes MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed(Type) as a safety check for dangerous types. The default implementation checks the outer type name, but it does not recursively inspect array element types or generic type arguments.

As a result, a type that would be blocked directly can be wrapped inside an array or constructed generic type and pass the outer type check. The formatter machinery can then materialize formatters for the inner blocked type.

Impact

Applications are affected when they deserialize untrusted payloads using typeless serialization features such as MessagePackSerializer.Typeless, TypelessObjectResolver, or related typeless resolver options.

Typeless deserialization is already a high-risk feature for untrusted data, but the presence of a disallowed-type hook creates an expectation that blocked types remain blocked. This issue weakens that mitigation because the check is not applied structurally to nested type components. An attacker who can supply typeless ext-100 payloads may bypass exact outer-type blocklist checks by naming wrapper types such as arrays or generic containers.

The consequence depends on which type is reached and what the application allows typeless deserialization to instantiate. The original findings describe bypasses involving blocked or user-blocklisted gadget types.

Affected components

• Package: MessagePack
• Feature: typeless deserialization
• APIs: MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed, TypelessFormatter
• Finding IDs: MESSAGEPACKCSHARP-030, duplicate/open variant MESSAGEPACKCSHARP-OPEN-007

Patches

Fixes are available via versions 2.5.301 and 3.1.7.

Upgrade guidance:

1. Upgrade MessagePack 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 apply type-disallow checks recursively to array element types, pointer/byref element types where applicable, nullable underlying types, and constructed generic type arguments. Formatter paths that materialize types supplied by the wire should not instantiate inner types that fail the configured policy.

Workarounds

Patching is recommended.

Avoid typeless deserialization for untrusted data. If typeless support is unavoidable, configure an explicit allowlist that rejects any type not approved by the application and ensure the allowlist recursively validates array elements and generic arguments. Do not rely on exact outer-type blocklists as a complete security boundary.

Resources

• MESSAGEPACKCSHARP-030: typeless disallowed-type check is not recursive
• MESSAGEPACKCSHARP-OPEN-007: duplicate/open finding for typeless blocklist gaps
• CWE-502: Deserialization of Untrusted Data
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code

CVE split rationale

This vulnerability is independently fixable in typeless type-policy enforcement. It is separate from MVC default options, collection allocation, LZ4 decoding, and recursion-depth issues.

Summary

InterfaceLookupFormatter<TKey,TElement> constructs an internal Dictionary<TKey, IGrouping<TKey,TElement>> with the default equality comparer instead of the security-aware comparer supplied by options.Security.GetEqualityComparer<TKey>().

Other hash-based collection formatters use the security-aware comparer when MessagePackSecurity.UntrustedData is configured. This formatter omission allows hash-collision CPU denial of service against ILookup<TKey,TElement> even when the application has opted into the untrusted-data security posture.

Impact

Applications are affected when they deserialize untrusted payloads into schemas containing ILookup<TKey,TElement> with a key type for which attacker-controlled hash collisions are feasible.

Under the default comparer, many colliding keys can degrade dictionary insertion from amortized constant time to quadratic behavior. A payload of colliding keys can consume CPU for a disproportionate amount of time. This bypasses the mitigation that developers intentionally enabled by using MessagePackSecurity.UntrustedData.

Affected components

• Package: MessagePack
• API: InterfaceLookupFormatter<TKey,TElement>.Create
• Data type: ILookup<TKey,TElement>
• Finding ID: MESSAGEPACKCSHARP-041

Patches

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

Upgrade guidance:

1. Upgrade MessagePack 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 create the internal dictionary with options.Security.GetEqualityComparer<TKey>(), matching the sibling dictionary and lookup formatter behavior.

Workarounds

Patching is recommended.

Until a patched version is available, avoid exposing ILookup<TKey,TElement> in DTOs that deserialize untrusted data. Use collection shapes that are already protected by the security-aware comparer path, or validate and cap collection sizes at the transport boundary.

Resources

• MESSAGEPACKCSHARP-041: InterfaceLookupFormatter missing security comparer
• CWE-407: Inefficient Algorithmic Complexity