GHSA-gmjw-49p4-pcfm is a medium-severity (CVSS 6.7) vulnerability in msgpack5. 1 public exploit reference exists, so weaponization risk is real. O3 Security confirms whether GHSA-gmjw-49p4-pcfm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Prototype poisoning
Real-World Exposure
msgpack5📦msgpack5📦msgpack5Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
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:
const msgpack5 = require('msgpack5')();
const payload = {};
Object.defineProperty(payload, '__proto__', {
value: new Map().set(1, 2),
enumerable: true
});
const encoded = msgpack5.encode(payload);
console.log(encoded); // <Buffer 81 a9 5f 5f 70 72 6f 74 6f 5f 5f 81 01 02>
const decoded = msgpack5.decode(encoded);
// decoded's prototype has been overwritten
console.log(Object.getPrototypeOf(decoded)); // Map(1) { 1 => 2 }
console.log(decoded.get); // [Function: get]
// decoded appears to most common typechecks to be a Map
console.log(decoded instanceof Map); // true
console.log(decoded.toString()); // [object Map]
console.log(Object.prototype.toString.call(decoded)); // [object Map]
console.log(decoded.constructor.name); // Map
console.log(Object.getPrototypeOf(decoded).constructor.name); // Map
// decoded is not, however, a Map
console.log(Object.getPrototypeOf(decoded) === Map.prototype); // false
// using decoded as though it were a Map throws
try {
decoded.get(1);
} catch (error) {
console.log(error); // TypeError: Method Map.prototype.get called
// on incompatible receiver #<Map>
}
try {
decoded.size;
} catch (error) {
console.log(error); // TypeError: Method get Map.prototype.size
// called on incompatible receiver #<Map>
}
// re-encoding the decoded value throws
try {
msgpack5.encode(decoded);
} catch (error) {
console.log(error); // TypeError: Method Map.prototype.entries
// called on incompatible receiver #<Map>
}
This "prototype poisoning" is sort of a very limited inversion of a
prototype pollution attack. Only the decoded value's 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 consumer's code).
Patches
Versions v5.2.1, v4.5.1, v3.6.1 include the fix.
Workarounds
Always validate incoming data after parsing before doing any processing.
For more information
If you have any questions or comments about this advisory:
- Open an issue in example link to repo
- Email us at example email address
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | msgpack5 | all versions | 3.6.1 |
| 📦npm | msgpack5 | ≥ 4.0.0&&< 4.5.1 | 4.5.1 |
| 📦npm | msgpack5 | ≥ 5.0.0&&< 5.2.1 | 5.2.1 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for msgpack5. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update msgpack5 to 3.6.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gmjw-49p4-pcfm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gmjw-49p4-pcfm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gmjw-49p4-pcfm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gmjw-49p4-pcfm in your dependencies?
O3 detects GHSA-gmjw-49p4-pcfm across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.