GHSA-4qm4-8hg2-g2xm
MessagePack allows untrusted data to lead to DoS attack due to hash collisions and stack overflow
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
MessagePack.NETMessagePackReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
Impact
When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized.
This is similar to a prior advisory, which provided an inadequate fix for the hash collision part of the vulnerability.
Patches
The following steps are required to mitigate this risk.
- Upgrade to a version of the library where a fix is available. If upgrading from v1, check out our migration guide.
- Review the steps in this previous advisory to ensure you have your application configured for untrusted data.
Workarounds
If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows:
- Declare a class that derives from
MessagePackSecurity. - Override the
GetHashCollisionResistantEqualityComparer<T>method to provide a collision-resistant hash function of your own and avoid callingbase.GetHashCollisionResistantEqualityComparer<T>(). - Configure a
MessagePackSerializerOptionswith an instance of your derived type by callingWithSecurityon an existing options object. - Use your custom options object for all deserialization operations. This may be by setting the
MessagePackSerializer.DefaultOptionsstatic property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to anyDeserializemethod.
References
- Learn more about best security practices when reading untrusted data with MessagePack 1.x or MessagePack 2.x.
- The .NET team's discussion on hash collision vulnerabilities of their
HashCodestruct (or in the pull request that merges this into the dotnet org).
For more information
If you have any questions or comments about this advisory:
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | MessagePack | all versions | 2.5.187 |
| .NETNuGet | MessagePack | ≥ 2.6.95-alpha&&< 3.0.214-rc.1 | 3.0.214-rc.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for MessagePack. 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 MessagePack to 2.5.187 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4qm4-8hg2-g2xm 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-4qm4-8hg2-g2xm 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-4qm4-8hg2-g2xm. 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-4qm4-8hg2-g2xm in your dependencies?
O3 detects GHSA-4qm4-8hg2-g2xm across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.