msgpack5 is a msgpack v5 implementation for node.js and the browser. In msgpack5 before versions 3.6.1, 4.5.1, and 5.2.1 there is a Prototype Poisoning vulnerability. When msgpack5 decodes a map containing a key proto, it assigns the decoded value to proto. Object.prototype.proto is an accessor property for the receivers prototype. If the value corresponding to the key proto decodes to an object or null, msgpack5 sets the decoded objects 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. This prototype poisoning is sort of a very limited inversion of a prototype pollution attack. Only the decoded values prototype is affected, and it can only be set to msgpack5 values (though if the victim makes use of custom codecs, anything could be a msgpack5 value). We have not found a way to escalate this to true prototype pollution (absent other bugs in the consumers code). This has been fixed in msgpack5 version 3.6.1, 4.5.1, and 5.2.1. See the referenced GitHub Security Advisory for an example and more details.
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Msgpack5 | Msgpack5_project | * | 3.6.1 (excluding) |
| Msgpack5 | Msgpack5_project | 4.0.0 (including) | 4.5.1 (excluding) |
| Msgpack5 | Msgpack5_project | 5.0.0 (including) | 5.2.1 (excluding) |
If the object contains attributes that were only intended for internal use, then their unexpected modification could lead to a vulnerability. This weakness is sometimes known by the language-specific mechanisms that make it possible, such as mass assignment, autobinding, or object injection.