MessagePack-CSharp Patches 12 CVEs Affecting .NET 6 and SignalR

On June 25, 2026, the MessagePack-CSharp project disclosed a coordinated batch of twelve security advisories affecting every release line of the MessagePack serializer for .NET. The batch includes three High-severity flaws, led by CVE-2026-48109 (8.2, LZ4 out-of-bounds read) and CVE-2026-48506 (7.5, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, unbounded recursion in MessagePackReader.Skip), plus nine Medium denial-of-service variants that share one failure mode: the deserializer trusting attacker-controlled sizes, depths, and dictionary keys. Upstream fixes landed in MessagePack 2.5.301 and 3.1.7. NES Essentials Plus MessagePack shipped the same remediations in 2.5.192.3, and NES for .NET 6.0.42 updated the MessagePack dependency bundled with SignalR. 

Affected and unsupported? See NES for .NET.

‍

What was disclosed

All twelve advisories were published by the MessagePack-CSharp maintainers through GitHub Security Advisories. Every advisory was fixed in MessagePack 2.5.301 on the 2.x line and 3.1.7 on the 3.x line, so all twelve affect both lines: any 2.x build below 2.5.301 (including the 2.1.90 bundled with SignalR) and any 3.x build below 3.1.7 is exposed. Scores below are the GitHub advisory (CNA) scores; most of the batch is scored on CVSS v4, with CVE-2026-48109 and CVE-2026-48506 scored on CVSS 3.1.

‍

One batch, one failure mode

Taken individually, most of these are Medium DoS bugs. Taken together, they describe a single design gap that appeared in at least five independent places: the deserializer repeatedly let attacker-controlled values drive resource decisions before validation. The pattern breaks down into four groups: 

• Attacker-controlled allocation sizes. CVE-2026-48510, CVE-2026-48514, and CVE-2026-48515 all allocate memory based on a length or dimension the attacker declares in the message header. The payload stays tiny; the allocation does not. A few dozen bytes claiming a multi-gigabyte array is enough to exhaust memory. 
• Unbounded recursion. CVE-2026-48506, CVE-2026-48512, and CVE-2026-48513 each found a code path (skipping values, converting to JSON, union deserialization) where deeply nested input recurses past the depth limit the library is supposed to enforce. CVE-2026-48506 is the standout at 7.5: Skip is called on data the application never even maps to a type, which is exactly the code path teams assume is safe. 
• Algorithmic complexity through hostile keys. CVE-2026-48511 and CVE-2026-48516 turn dictionary insertion into the bottleneck. The InterfaceLookupFormatter case is the more instructive one: the library ships a collision-resistant comparer for exactly this threat, and the formatter simply did not use it. Enabling MessagePackSecurity.UntrustedData did not help because the vulnerable dictionary was constructed with the default comparer regardless.
• Trust-posture defaults. CVE-2026-48509 is a configuration trap rather than a parsing bug: the parameterless MessagePackInputFormatter constructor for ASP.NET Core MVC applies the TrustedData security posture to HTTP request bodies, which are by definition untrusted. Any team that wired up MessagePack content negotiation with the default constructor was running with hardening off on a public endpoint. The lesson for anyone deserializing binary formats on a network boundary: security settings only protect the code paths that consult them. Two of these CVEs (48506 and 48516) exist precisely because a hardening flag was implemented in some formatters and skipped in others.

‍

What an attacker can do

The realistic outcomes across the batch:

• Crash an ASP.NET Core or SignalR process outright with a malformed LZ4 block (CVE-2026-48109) or deeply nested payload (CVE-2026-48506), taking down every connection the process serves
• Exhaust server memory with a message a few bytes long that declares enormous array lengths or dimensions (CVE-2026-48510, CVE-2026-48514, CVE-2026-48515)
• Pin CPU on a single request through hash-collision or quadratic-insertion behavior in map deserialization (CVE-2026-48511, CVE-2026-48516), degrading service for all tenants of the process
• Instantiate types the application explicitly blocklisted, by wrapping them in an array or generic argument to slip past the outer-type-only check (CVE-2026-48517), an integrity impact rather than availability None of these grants code execution on its own. But for anything internet-facing, the cost asymmetry matters: each attack costs the attacker a small crafted message and costs the target a process, a core, or a heap.

‍

CVE-2026-48517: the same allowlist bug, twice, in two ecosystems

CVE-2026-48517 deserves its own note because .NET is the second ecosystem to ship this exact mistake in a deserialization safety mechanism this year. The bug: MessagePack's typeless deserialization supports type restrictions, an allowlist-style check meant to stop dangerous types from being instantiated. The check inspects the outer type name only. Wrap a blocked type in an array (BlockedType[]) or hand it in as a generic argument (List<BlockedType>) and the wrapper's name passes inspection while the inner type gets instantiated anyway. That is structurally the same flaw as the jackson-databind PolymorphicTypeValidator bypasses (CVE-2026-54512 and CVE-2026-54513) disclosed in the Java ecosystem in June: a gatekeeper that validates the type it can see rather than the types it will construct. Different serializer, different language, identical failure shape. If your threat model includes polymorphic or typeless deserialization anywhere, the portable takeaway is that allowlist checks must recurse into element types and generic arguments, and that this is worth verifying in your own custom formatters, not just the library's.

‍

Who is affected?

The affected versions span every MessagePack-CSharp line, including the version bundled inside Microsoft's SignalR MessagePack protocol package. .NET 6 itself reached end of life on November 12, 2024 (Microsoft .NET support policy), so applications pinned there receive no upstream servicing for bundled dependencies.

The last row is the one most teams miss. The SignalR MessagePack protocol package on .NET 6 carries its own copy of the library, so an application can be exposed without ever declaring a direct MessagePack package reference. Check your lock file, not just your .csproj.

‍

Mitigation guidance

‍

How the fixes reached NES users

The remediation timeline is short. Upstream advisories were published June 25, 2026. On June 27, 2026, HeroDevs shipped fixes on both affected NES lines, per the .NET 6.0.x release notes:

• NES for .NET 6.0.42 updated the MessagePack dependency bundled in Microsoft.AspNetCore.SignalR.Protocols.MessagePack from 2.1.90 to 2.5.301, resolving all twelve batch CVEs affecting the 2.x line plus the earlier stack-overflow flaw CVE-2024-48924
• NES Essentials Plus MessagePack 2.5.192.3 carries the same remediations on the NES fork line, with machine-readable VEX statements published per CVE The fork itself was in scope for this batch, and that is the point of the model: when upstream discloses, the NES line ships the fix on the version customers are already pinned to, without a forced framework migration in the middle of an incident response window.

‍

Related CVEs

If you are tracking MessagePack-CSharp or deserialization risk more broadly:

• CVE-2026-48109: the LZ4 out-of-bounds read from this same batch, covered in depth in our standalone analysis
• CVE-2024-48924: the earlier MessagePack stack-overflow DoS, also resolved by the 2.5.301 update in NES for .NET 6.0.42
• CVE-2026-54512 and CVE-2026-54513: the jackson-databind validator bypasses that share CVE-2026-48517's failure shape
• CVE-2025-52999: the jackson-core recursion DoS, the Java twin of this batch's depth-enforcement bugs

‍

Taking action

If you can upgrade, upgrade: 3.1.7 or 2.5.301 closes the entire batch on maintained lines. The teams with a real decision to make are the ones on .NET 6, where the SignalR MessagePack package bundles a vulnerable 2.1.90 and Microsoft's servicing ended in November 2024. For those applications, NES for .NET 6.0.42 already carries the fix, alongside the rest of the thirty patched vulnerabilities on the 6.0.x NES line. Audit your dependency graph for MessagePack (direct and transitive), confirm which line you resolve, and get onto a patched version before someone tests the cost asymmetry for you.