MessagePack-CSharp CVE-2026-92707: SignalR Memory DoS from Patch Tuesday

On 13 October 2026, Microsoft's Patch Tuesday listed CVE-2026-92707, a denial of service flaw in the MessagePack-CSharp library, and marked it as publicly disclosed. The bug lives in the open source MessagePack serializer, not in .NET itself, but it reaches ASP.NET Core apps through the SignalR MessagePack hub protocol. Microsoft rates it Moderate (CVSS 5.3) and says it is not exploited.

The CVSS score undersells the operational risk for anyone running a public SignalR hub. The maintainers' advisory describes a payload of roughly 31.5 KiB that makes the server allocate about 114.7 MiB of reference storage on x64 before the depth check rejects it, an amplification of around 3,800 times. Send that repeatedly and the process spends its life in garbage collection or falls over.

What's affected

The flaw is in PrimitiveObjectFormatter, the formatter MessagePack uses when it deserializes data into System.Object. When it meets an array header, it allocates an object[] sized from the declared length before it enforces the configured maximum object graph depth. Nested array headers can reuse the same trailing bytes to pass the per header length check, so a small message keeps many large arrays alive at once.

• NuGet package MessagePack: versions before 2.5.303, and 3.0 up to but not including 3.1.9. Fixed in 2.5.303 and 3.1.9 (GHSA-qhrr-8q5h-9q3h).
• Microsoft.AspNetCore.SignalR.Protocols.MessagePack: Microsoft lists fixed releases 8.0.32, 9.0.21, 10.0.13 and 11.0.0-rc.2, all published 13 October 2026.
• Visual Studio: MSRC also lists Visual Studio 2026 version 18.10 (fixed in 18.10.4) and Visual Studio 2022 version 17.14 (fixed in 17.14.42).

You are exposed when your application deserializes untrusted MessagePack data as object (including object typed members of otherwise typed models) and lets an attacker send it repeatedly. The advisory names one common route: an ASP.NET Core app that calls AddMessagePackProtocol() and exposes a hub method with an object parameter.

How to check if you're exposed

Start with the resolved dependency graph, not your project file. The SignalR protocol package declares a minimum version of MessagePack, and NuGet resolves to the lowest version that satisfies it. We checked the package metadata on nuget.org: Microsoft.AspNetCore.SignalR.Protocols.MessagePack 10.0.12 and 8.0.31 depend on MessagePack 2.5.302 or later, so unless something else in your graph asks for more, you get 2.5.302, which is vulnerable. Only the 13 October releases raise the floor to 2.5.303.

# Show every MessagePack version actually resolved, including transitive ones
dotnet list package --include-transitive | grep -i messagepack

# Ask NuGet's vulnerability feed directly
dotnet list package --vulnerable --include-transitive

Then look for the code path. These searches find the risky shapes:

# SignalR apps using the MessagePack protocol
grep -rn "AddMessagePackProtocol" --include=*.cs .

# Hub methods or DTOs that accept object
grep -rnE "public (async )?[A-Za-z<>]+ [A-Za-z]+\(.*\bobject\b" --include=*.cs src/

# Direct deserialization into object
grep -rn "Deserialize<object>" --include=*.cs .

If the protocol is enabled but every hub parameter is a concrete type, the vulnerable formatter is much less likely to be selected. That is exactly the question reachability analysis answers: does your code actually call into the vulnerable path, or does the package just sit in the graph.

What to do now

1. Pin MessagePack directly. Add a top level reference so NuGet cannot resolve below the fix: MessagePack 2.5.303 for the 2.x line or 3.1.9 for 3.x. If you use central package management, set it in Directory.Packages.props.
2. Update the SignalR protocol package to 8.0.32, 9.0.21 or 10.0.13 to match your runtime, and update Visual Studio to 18.10.4 or 17.14.42 on developer machines.
3. Replace object parameters on reachable hub methods with concrete DTO types. The advisory lists this as the primary workaround, and it is good hygiene even after patching.
4. Turn on the library's hardened mode for untrusted input:

var options = MessagePackSerializerOptions.Standard
    .WithSecurity(MessagePackSecurity.UntrustedData);
var result = MessagePackSerializer.Deserialize<MyDto>(data, options);

The MessagePack README is explicit that UntrustedData "merely hardens against some common attacks" and is not a complete defense, and the advisory says lowering the depth limit or message size only reduces the worst case.

5. Rate limit hub connections and messages. The attack needs repetition, so connection limits and per client message limits blunt it while you roll out the fix.
6. Rebuild and redeploy. A package bump does nothing for a container image built last month.

Why it matters

This is a familiar pattern with a .NET flavor: a third party library ships inside a first party framework package, and the framework's version floor quietly decides which copy you run. Microsoft issued the CVE through its Patch Tuesday, but the fix only lands in your app when the resolved MessagePack version changes, and NuGet's lowest applicable version rule means it will not change by itself.

It is also a reminder that "Moderate" is a score, not a priority. A low effort, unauthenticated memory exhaustion against a real time hub that every client connects to is worth a same week fix.

Try it yourself

Generate a CycloneDX SBOM for one of your ASP.NET Core services (for example with the CycloneDX .NET tool), then look for the MessagePack component and its version. Drop the SBOM into the free scanner at https://gold.safeguard.sh/scan. It runs in your browser, the file never leaves your machine, and it handles up to 100 dependencies per scan. Then compare the result with what your .csproj claims you depend on.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-qhrr-8q5h-9q3h: Nested arrays can blow past buffer length limits (MessagePack-CSharp)
• CVE-2026-92707 record (cve.org)
• Microsoft Security Update Guide: CVE-2026-92707
• MessagePack-CSharp README, Security section
• MessagePack 2.5.303 release
• Microsoft.AspNetCore.SignalR.Protocols.MessagePack on NuGet
• BleepingComputer: Microsoft October 2026 Patch Tuesday