Aarnott

**Name of the Vulnerable Software and Affected Versions** Nerdbank.MessagePack versions prior to 1.1.62 **Description** An uncontrolled stack allocation issue exists in DateTime decoding. A malicious MessagePack payload can declare an oversized timestamp extension length, leading the reader to allocate an attacker-controlled number of bytes on the stack. This occurs because the `tokenSize` is derived from the extension length before validating that it matches legal MessagePack timestamp sizes (4, 8, or 12 bytes). When the buffer is incomplete, this unvalidated size is used in a `stackalloc` operation, triggering a `StackOverflowException` that terminates the process and results in a denial of service. This affects applications deserializing MessagePack data from untrusted sources where the target type contains a `DateTime` value. **Recommendations** Update to version 1.1.62. Avoid deserializing untrusted MessagePack payloads into type graphs containing `DateTime` fields or properties. Pre-validate MessagePack extension headers and reject timestamp extensions with lengths other than 4, 8, or 12 bytes. Reject or filter extension type `-1` timestamp values from untrusted input. Run deserialization of untrusted payloads in an isolated process that can be safely restarted. Restrict MessagePack deserialization to trusted producers.

**Name of the Vulnerable Software and Affected Versions** MessagePack-CSharp versions prior to 2.5.187 and 3.0.214 **Description** The vulnerability occurs when the library is used to deserialize messagepack data from an untrusted source, leading to a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions. This results in large CPU consumption disproportionate to the size of the data being deserialized. The issue is similar to a prior advisory, which provided an inadequate fix for the hash collision part of the vulnerability. **Recommendations** To mitigate this risk, upgrade to a version of the library where a fix is available. If upgrading from v1, check out the migration guide. Review the steps in the previous advisory to ensure the application is configured for untrusted data. If upgrading MessagePack to a patched version is not an option, apply a manual workaround by declaring a class that derives from `MessagePackSecurity`, overriding the `GetHashCollisionResistantEqualityComparer` method to provide a collision-resistant hash function, and configuring `MessagePackSerializerOptions` with an instance of the derived type. Use the custom options object for all deserialization operations.