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
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A truncated map32 header causes an out-of-bounds buffer read and throws RangeError instead of IncompleteBufferError. Applications that rely on IncompleteBufferError to wait for additional bytes may terminate a request, stream, or worker unexpectedly. No adjacent memory is disclosed because the buffer implementation checks bounds. Patches The decoder now validates the complete five-byte map32 header before reading its length and reports truncated input as IncompleteBufferError. Workarounds Require at least five bytes before decoding a value beginning with 0xdf, or catch RangeError and treat it as incomplete input only for truncated map32 headers.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The streaming decoder recursively invokes itself for every complete value remaining in a chunk. A single chunk containing many small valid MessagePack values can exhaust the JavaScript call stack and interrupt the process or stream. Patches The streaming decoder now drains concatenated values iteratively with constant call-stack depth. Workarounds Limit the number of MessagePack values accepted in one chunk, or split large batches before passing them to the decoder stream.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The reserved MessagePack byte 0xc1 is incorrectly treated as incomplete input. When it appears at the start of a decoder stream, all subsequent data is retained while the decoder waits for bytes that can never make the value valid, allowing memory exhaustion. Patches The decoder now rejects 0xc1 as invalid input. Streaming decoders release buffered input and stop after unrecoverable decoding errors. Workarounds Reject 0xc1 before streaming input to msgpack5, and enforce stream byte and time limits.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Passing an empty or partial options object disables the default protoAction: 'error' protection. A map containing a proto key can then replace the prototype of the decoded object, potentially changing inherited properties or causing unexpected behavior in downstream code. Only the decoded object's prototype is affected; this does not modify Object.prototype globally. Patches Options are now merged with secure defaults without modifying the caller's object. Unsupported protoAction values are rejected. Workarounds Explicitly set protoAction: 'error' whenever constructing a msgpack5 instance, and validate decoded values before use.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The decoder has no nesting-depth limit for arrays and maps. An attacker who can provide MessagePack input can use deeply nested containers to exhaust the JavaScript call stack and interrupt the process or request handler. Patches The decoder now limits nesting depth to 100 by default and throws Maximum decode depth exceeded. Applications can configure the limit with the maxDepth option. Workarounds Reject deeply nested input before decoding, isolate decoding in a worker, or enforce a trusted schema with a bounded nesting depth.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The streaming decoder reparses an incomplete container from the beginning whenever another chunk arrives. A remote peer can split one valid MessagePack value across many small chunks, causing quadratic CPU usage and blocking the event loop. Patches The decoder now preserves incremental container state so completed elements are not parsed again when more input arrives. Workarounds Buffer each complete MessagePack value before decoding it, or limit the number of chunks accepted for a single value.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Decoding a negative signed 64-bit integer modifies the corresponding bytes in the caller-provided input buffer. Applications that retain or reuse encoded input for integrity checks, logging, or subsequent processing may observe silently corrupted data. Positive integers and other MessagePack value types are not affected. Patches The decoder now computes signed 64-bit values without writing to the input buffer. Workarounds Copy untrusted MessagePack input before decoding it, or do not retain or reuse input buffers after decoding.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The issue is as follows: when msgpack5 decodes a map containing a key "proto", it assigns the decoded value to proto. As you are no doubt aware, Object.prototype.proto is an accessor property for the receiver's prototype. If the value corresponding to the key proto decodes to an object or null, msgpack5 sets the decoded object's prototype to that value. An attacker who can submit crafted MessagePack data to a service can use this to produce values that appear to be of other types; may have unexpected prototype properties and methods (for example length, numeric properties, and push et al if proto's value decodes to an Array); and/or may throw unexpected exceptions when used (for example if the proto value decodes to a Map or Date). Other unexpected behavior might be produced for other types. There is no effect on the global prototype. An example: This "prototype poisoning" is sort of a very limited inversion of a prototype pollution attack. Only the decoded value's prototype…
Recommended action: Upgrade to 5.2.1, 4.5.1 or 3.6.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.