GHSA-qjvr-435c-5fjh

Nerdbank.MessagePack deserializers for many collection-shaped types trusted the element count declared in MessagePack array and map headers when allocating destination storage. A crafted payload could therefore force large arrays, pooled buffers, dictionaries, or collection instances to be allocated before the deserializer had consumed the corresponding elements. The same allocation pattern existed across strongly typed arrays, primitive arrays, mutable and immutable dictionaries, mutable enumerables, span-backed enumerable construction, `JsonNode`, `MessagePackValue`, and the object/dynamic primitive converters. Because MessagePack array and map headers carry an attacker-controlled element count, any converter that immediately allocates `count` elements or constructs a collection with capacity `count` can turn a payload that is merely large into a much larger managed heap allocation. The reader's residency checks reduce the most extreme header-only attack shape, but they do not remove the memory amplification: minimal MessagePack elements can be one or two bytes on the wire while the managed representation may require object references, dictionary buckets, entries, array headers, or over-allocated collection internals. ## Vulnerability Pattern Affected converters followed one or both of these patterns: ```csharp int count = reader.ReadArrayHeader(); TElement[] array = new TElement[count]; int count = reader.ReadMapHeader(); Dictionary<TKey, TValue> map = new(count); ``` or, for streaming and span-backed construction: ```csharp TElement[] elements = ArrayPool<TElement>.Shared.Rent(count); TCollection collection = getCollection(state, count); ``` In all affected cases, the allocation size was derived from the untrusted header count before the converter had read the elements. This made deserialization vulnerable to memory amplification and process availability attacks. ## Affected Scope The vulnerable logic was present in multiple converter families: | Con