Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 3.1.9 or 2.5.303 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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,…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.7 or 2.5.301 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized. This is similar to a prior advisory, which provided an inadequate fix for the hash collision part of the vulnerability. Patches The following steps are required to mitigate this risk. 1. Upgrade to a version of the library where a fix is available. If upgrading from v1, check out our migration guide. 1. Review the steps in this previous advisory to ensure you have your application configured for untrusted data. Workarounds If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows: 1. Declare a class that derives from MessagePackSecurity. 2. Override the GetHashCollisionResistantEqualityComparer<T method to provide a…
Recommended action: Upgrade to 3.0.214-rc.1 (pre-release) or 2.5.187 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by either of two vectors: 1. hash collisions - leading to large CPU consumption disproportionate to the size of the data being deserialized. 1. stack overflow - leading to the deserializing process crashing. Patches The following steps are required to mitigate this risk. 1. Upgrade to a version of the library where a fix is available 1. Add code to your application to put MessagePack into the defensive UntrustedData mode. 1. Identify all MessagePack extensions that implement IMessagePackFormatter<T implementations that do not ship with the MessagePack library to include the security mitigations. This includes those acquired from 3rd party packages and classes included directly into your project. Any AOT formatters generated with the MPC tool must be regenerated with the patched version of mpc. 1. Review your messagepack-serializable data structures…
Recommended action: Upgrade to 2.1.90 or 1.9.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.