CVE-2026-48517 Overview
CVE-2026-48517 affects MessagePack for C# (MessagePack-CSharp), a widely used MessagePack serializer for the .NET ecosystem. The vulnerability resides in the typeless deserialization safety check MessagePackSerializerOptions.ThrowIfDeserializingTypeIsDisallowed(Type). The check inspects only the outer type name and fails to recursively examine array element types or generic type arguments. Attackers can wrap a disallowed type inside an array or constructed generic type to bypass the block list. The formatter machinery then materializes formatters for the inner, blocked type during deserialization. The flaw is categorized under [CWE-470] Use of Externally-Controlled Input to Select Classes or Code (Unsafe Reflection).
Critical Impact
Untrusted MessagePack payloads can bypass type allow/deny enforcement and instantiate formatters for dangerous .NET types, leading to unsafe reflection-based deserialization.
Affected Products
- MessagePack-CSharp versions prior to 2.5.301 (2.x branch)
- MessagePack-CSharp versions prior to 3.1.7 (3.x branch)
- .NET applications using MessagePackSerializer with typeless deserialization enabled
Discovery Timeline
- 2026-06-22 - CVE-2026-48517 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-48517
Vulnerability Analysis
MessagePack-CSharp supports typeless serialization, where the .NET type name is embedded in the serialized payload and resolved during deserialization. To prevent attackers from triggering instantiation of dangerous types, the library exposes ThrowIfDeserializingTypeIsDisallowed(Type) as a guard.
The default implementation evaluates only the surface type passed to the check. It does not descend into composite type structures. As a result, a type that is explicitly disallowed at the top level passes validation when nested inside container types resolved by the formatter pipeline.
When deserialization proceeds, MessagePack-CSharp constructs formatters for the inner type and instantiates objects of the blocked class. This restores the same unsafe reflection behavior the block list was meant to prevent.
Root Cause
The root cause is incomplete validation logic in ThrowIfDeserializingTypeIsDisallowed. The function performs a single-level type-name comparison rather than walking the full type graph, including Type.GetElementType() for arrays and Type.GetGenericArguments() for constructed generics. This is a classic case of [CWE-470] unsafe reflection where input-controlled type resolution is not consistently constrained.
Attack Vector
An attacker who can supply a MessagePack payload to a vulnerable deserializer crafts a wrapper such as an array of a blocked type or a generic container parameterized with the blocked type. The outer type passes the deny check, but the inner formatter resolves and instantiates the blocked type during materialization. Exploitation requires the application to accept untrusted MessagePack input and use typeless deserialization with the default disallowed-type guard.
No verified proof-of-concept code is published for this CVE. Refer to the GitHub Security Advisory GHSA-qhmf-xw27-6rqr for vendor technical details.
Detection Methods for CVE-2026-48517
Indicators of Compromise
- MessagePack payloads from untrusted sources containing typeless markers that reference array or generic type wrappers of sensitive .NET types
- Unexpected loading of reflection-related assemblies in processes that deserialize MessagePack input
- Application exceptions or stack traces originating in MessagePack.Resolvers.TypelessFormatter or DynamicObjectResolver after processing external payloads
Detection Strategies
- Inventory .NET projects for MessagePack package references and identify versions earlier than 2.5.301 or 3.1.7.
- Audit code paths that call MessagePackSerializer.Typeless APIs or configure TypelessContractlessStandardResolver with externally sourced data.
- Inspect custom implementations of ThrowIfDeserializingTypeIsDisallowed to verify they recurse into element and generic argument types.
Monitoring Recommendations
- Log and alert on deserialization exceptions emitted from MessagePack formatters in production services.
- Monitor outbound network connections and child process creation initiated by services that ingest MessagePack data.
- Correlate web application telemetry with deserializer error patterns to identify probing attempts.
How to Mitigate CVE-2026-48517
Immediate Actions Required
- Upgrade MessagePack-CSharp to 2.5.301 or 3.1.7 or later across all affected services.
- Disable typeless deserialization for any endpoint that processes untrusted input until the upgrade is deployed.
- Treat all externally sourced MessagePack payloads as untrusted and validate schema before deserialization.
Patch Information
The maintainers fixed the issue in MessagePack-CSharp 2.5.301 and 3.1.7. The patched releases extend ThrowIfDeserializingTypeIsDisallowed to recursively inspect array element types and generic type arguments. See the MessagePack-CSharp Security Advisory GHSA-qhmf-xw27-6rqr for vendor remediation guidance.
Workarounds
- Avoid MessagePackSerializer.Typeless and TypelessContractlessStandardResolver for untrusted input streams.
- Implement a custom resolver that walks the full type tree and rejects disallowed types at any nesting level.
- Restrict network exposure of services that accept MessagePack payloads to authenticated, trusted callers only.
# Update MessagePack-CSharp via the .NET CLI
dotnet add package MessagePack --version 3.1.7
# Or for the 2.x branch
dotnet add package MessagePack --version 2.5.301
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
