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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Applications that call OptionalConverters.WithExpandoObjectConverter and deserialize untrusted data are open to a vulnerability by which an attacker can exploit a O(n²) algorithm to burn an inordinate amount of CPU effort by adding a great many properties to an ExpandoObject, whose Add method is implemented as an O(n) algorithm. Patches Update to a patched version. If a project's ExpandoObject data requires more than 128 properties, the default limit should be changed: Workarounds Avoid the non-default WithExpandoObjectConverter extension method when deserializing untrusted data. If deserializing untrusted data into an ExpandoObject is required, developers should write a custom converter for their project that limits the number of properties allowed before initializing the object.
Recommended action: Upgrade to 1.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.1.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Nerdbank.MessagePack contains an uncontrolled stack allocation vulnerability in DateTime decoding. A malicious MessagePack payload can declare an oversized timestamp extension length, causing the reader to allocate an attacker-controlled number of bytes on the stack. This can trigger a StackOverflowException, which is not catchable by user code and terminates the process. Impact Applications are impacted if they deserialize MessagePack data from untrusted or attacker-controlled sources using Nerdbank.MessagePack and the target type contains a DateTime value. A small malicious payload can cause process termination, resulting in a denial of service. This may affect services, APIs, workers, message consumers, or other long-running processes that deserialize untrusted MessagePack input. The issue occurs because DateTime timestamp extension decoding derives tokenSize from the attacker-controlled extension length before validating that the timestamp length is one of the legal…
Recommended action: Upgrade to 1.1.62 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.