GHSA-7q36-4xx7-xcxf is a medium-severity (CVSS 4.8) CWE-121 vulnerability in MessagePack. O3 Security confirms whether GHSA-7q36-4xx7-xcxf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Untrusted data can lead to DoS attack due to hash collisions and stack overflow in MessagePack
Real-World Exposure
MessagePack.NETMessagePack.NETMessagePack.ImmutableCollection.NETMessagePack.ImmutableCollection.NETMessagePack.ReactiveProperty.NETMessagePack.ReactiveProperty.NETMessagePack.UnityShims.NETMessagePack.UnityShims+2 moreReal-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 either of two vectors:
- hash collisions - leading to large CPU consumption disproportionate to the size of the data being deserialized.
- stack overflow - leading to the deserializing process crashing.
Patches
The following steps are required to mitigate this risk.
- Upgrade to a version of the library where a fix is available
- Add code to your application to put MessagePack into the defensive
UntrustedDatamode. - Identify all MessagePack extensions that implement
IMessagePackFormatter<T>implementations that do not ship with the MessagePack library to include the security mitigations. This includes those acquired from 3rd party packages and classes included directly into your project. Any AOT formatters generated with the MPC tool must be regenerated with the patched version of mpc. - Review your messagepack-serializable data structures for hash-based collections that use custom or unusual types for the hashed key. See below for details on handling such situations.
Review the MessagePackSecurity class to tweak any settings as necessary to strike the right balance between performance, functionality, and security.
Specialized IEqualityComparer<T> implementations provide the hash collision resistance.
Each type of hashed key may require a specialized implementation of its own.
The patched MessagePack library includes many such implementations for primitive types commonly used as keys in hash-based collections.
If your data structures use custom types as keys in these hash-based collections,
putting MessagePack in UntrustedData mode may lead the deserializer to throw an exception
because no safe IEqualityComparer<T> is available for your custom T type.
You can provide your own safe implementation by deriving from the MessagePackSecurity class
and overriding the GetHashCollisionResistantEqualityComparer<T>() method to return your own
custom implementation when T matches your type, and fallback to return base.GetHashCollisionResistantEqualityComparer<T>(); for types you do not have custom implementations for.
Unrelated to this advisory, but as general security guidance, you should also avoid the Typeless serializer/formatters/resolvers for untrusted data as that opens the door for the untrusted data to potentially deserialize unanticipated types that can compromise security.
MessagePack 1.x users
-
Upgrade to any 1.9.x version.
-
When deserializing untrusted data, put MessagePack into a more secure mode with:
MessagePackSecurity.Active = MessagePackSecurity.UntrustedData;In MessagePack v1.x this is a static property and thus the security level is shared by the entire process or AppDomain. Use MessagePack v2.1 or later for better control over the security level for your particular use.
-
Any code produced by mpc should be regenerated with the mpc tool with the matching (patched) version. Such generated code usually is written to a file called
Generated.cs. A patchedGenerated.csfile will typically reference theMessagePackSecurityclass.Review any custom-written
IMessagePackFormatter<T>implementations in your project or that you might use from 3rd party packages to ensure they also utilize theMessagePackSecurityclass as required. In particular, a formatter that deserializes an object (as opposed to a primitive value) should wrap the deserialization in ausing (MessagePackSecurity.DepthStep())block. For example:public MyObject Deserialize(ref MessagePackReader reader, MessagePackSerializerOptions options) { if (reader.TryReadNil()) { return default; } else { using (MessagePackSecurity.DepthStep()) // STACK OVERFLOW MITIGATION { MyObject o = new MyObject(); // deserialize members of the object here. return o; } } }If your custom formatter creates hash-based collections (e.g.
Dictionary<K, V>orHashSet<T>) where the hashed key comes from the messagepack data, always instantiate your collection usingMessagePackSecurity.Active.GetEqualityComparer<T>()as the equality comparer:var collection = new HashSet<T>(MessagePackSecurity.Active.GetEqualityComparer<T>());This ensures that when reading untrusted data, you will be using a collision-resistent hash algorithm.
Learn more about best security practices when reading untrusted data with MessagePack 1.x.
MessagePack 2.x users
-
Upgrade to any 2.1.x or later version.
-
When deserializing untrusted data, put MessagePack into a more secure mode by configuring your
MessagePackSerializerOptions.Securityproperty:var options = MessagePackSerializerOptions.Standard .WithSecurity(MessagePackSecurity.UntrustedData); // Pass the options explicitly for the greatest control. T object = MessagePackSerializer.Deserialize<T>(data, options); // Or set the security level as the default. MessagePackSerializer.DefaultOptions = options; -
Any code produced by mpc should be regenerated with the mpc tool with the matching (patched) version. Such generated code usually is written to a file called
Generated.cs. A patchedGenerated.csfile will typically reference theSecuritymember on theMessagePackSerializerOptionsparameter.Review any custom-written
IMessagePackFormatter<T>implementations in your project or that you might use from 3rd party packages to ensure they also utilize theMessagePackSecurityclass as required. In particular, a formatter that deserializes an object (as opposed to a primitive value) should calloptions.Security.DepthStep(ref reader);before deserializing the object's members, and be sure to revert the depth step withreader.Depth--;before exiting the method. For example:public MyObject Deserialize(ref MessagePackReader reader, MessagePackSerializerOptions options) { if (reader.TryReadNil()) { return default; } else { options.Security.DepthStep(ref reader); // STACK OVERFLOW MITIGATION, line 1 try { MyObject o = new MyObject(); // deserialize members of the object here. return o; } finally { reader.Depth--; // STACK OVERFLOW MITIGATION, line 2 } } }If your custom formatter creates hash-based collections (e.g.
Dictionary<K, V>orHashSet<T>) where the hashed key comes from the messagepack data, always instantiate your collection usingoptions.Security.GetEqualityComparer<TKey>()as the equality comparer:var collection = new HashSet<T>(options.Security.GetEqualityComparer<T>());This ensures that when reading untrusted data, you will be using a collision-resistent hash algorithm.
Learn more about best security practices when reading untrusted data with MessagePack 2.x.
Workarounds
The security vulnerabilities are in the formatters. Avoiding the built-in formatters entirely in favor of reading messagepack primitive data directly or relying on carefully written custom formatters can provide a workaround.
MessagePack v1.x users may utilize the MessagePackBinary static class directly to read the data they expect.
MessagePack v2.x users may utilize the MessagePackReader struct directly to read the data they expect.
References
Learn more about best security practices when reading untrusted data with MessagePack 1.x or MessagePack 2.x.
For more information
If you have any questions or comments about this advisory:
- Open an issue in MessagePack-CSharp
- Email us
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | MessagePack | all versions | 1.9.11 |
| .NETNuGet | MessagePack | ≥ 2.0.0&&< 2.1.90 | 2.1.90 |
| .NETNuGet | MessagePack.ImmutableCollection | all versions | 1.9.11 |
| .NETNuGet | MessagePack.ImmutableCollection | ≥ 2.0.0&&< 2.1.90 | 2.1.90 |
| .NETNuGet | MessagePack.ReactiveProperty | all versions | 1.9.11 |
| .NETNuGet | MessagePack.ReactiveProperty | ≥ 2.0.0&&< 2.1.90 | 2.1.90 |
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 1.9.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7q36-4xx7-xcxf 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-7q36-4xx7-xcxf 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-7q36-4xx7-xcxf. 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-7q36-4xx7-xcxf in your dependencies?
O3 detects GHSA-7q36-4xx7-xcxf across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.