ASP.NET Core SignalR Resource Exhaustion Flaw CVE-2026-70159 Patches Available for .NET 8 to 11

Microsoft has released patches for a high-severity denial of service vulnerability in ASP.NET Core SignalR components. The flaw, tracked as CVE-2026-70159, exists in the `Microsoft.AspNetCore.SignalR.Common` and `Microsoft.AspNetCore.SignalR.Core` NuGet packages. According to Microsoft’s security update guide, the issue allows an unauthorized attacker to deny service over a network by exploiting resource allocation without limits or throttling.

Root cause

The vulnerability stems from how SignalR handles stateful reconnect clients. According to the GitHub advisory, these clients can indefinitely block broadcasts through `MessageBuffer.ResendAsync` backpressure mechanisms. This behavior causes the system to retain associated resources without releasing them properly. The underlying weakness is classified as CWE-770, allocation of resources without limits or throttling. This design flaw allows an attacker to exhaust server resources by manipulating client reconnection states.

Attack path

An attacker does not need authentication to exploit this vulnerability. The CVSS vector indicates the attack is network-based with low complexity and no user interaction required. By triggering the backpressure condition in `MessageBuffer.ResendAsync`, an attacker can force the server to hold onto resources indefinitely. This effectively blocks broadcast capabilities and consumes memory or processing power. The impact is limited to availability, with no compromise of confidentiality or integrity.

Affected versions

Several version ranges across multiple .NET releases are vulnerable. The affected packages and their patched versions are:

• Microsoft.AspNetCore.SignalR.Common 10.0.0 through 10.0.12; patched in 10.0.13.
• Microsoft.AspNetCore.SignalR.Core 1.0.0 through 1.2.13; patched in 1.2.14.
• Microsoft.AspNetCore.SignalR.Common 11.0.0-preview.5 through 11.0.0-rc.1; patched in 11.0.0-rc.2.
• Microsoft.AspNetCore.SignalR.Common 8.0.0 through 8.0.31; patched in 8.0.32.
• Microsoft.AspNetCore.SignalR.Common 9.0.0 through 9.0.20; patched in 9.0.21.

Mitigation

Developers should update their applications to the patched versions listed above. Microsoft advises users to review their project dependencies to identify if they are using any of the vulnerable package ranges. Updating the NuGet packages to the specified patched versions removes the vulnerability. Teams should verify that their deployment pipelines include these updates to ensure all environments are protected.

Signals worth monitoring

Security operations teams should monitor for unusual patterns in SignalR connection logs. Look for spikes in reconnection attempts from single or multiple sources. Check for increased memory usage on servers hosting SignalR hubs without corresponding traffic increases. Alert on broadcast failures or delays that coincide with high connection churn. Investigate any sustained resource exhaustion events that lack an obvious legitimate cause. Review application logs for errors related to message buffer backpressure.

What to do and how to stay safe: Microsoft

• Audit your NuGet package dependencies to identify if you are using vulnerable versions of SignalR.Common or SignalR.Core.
• Update to the patched versions listed in the advisory as soon as possible to mitigate the risk.
• Monitor server resource utilization for signs of unexplained memory growth or CPU spikes during peak connection times.
• Review application logs for broadcast failures or excessive reconnection attempts that may indicate exploitation.

Step-by-step guide: Attack Surface Management: 6 Common Misreadings and Correct Views

General security guidance from the NetSec Observer newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the CVSS score for CVE-2026-70159?

The CVSS 3.1 score is 7.5, which is rated as High severity.

Which operating systems are affected by this vulnerability?

The vulnerability affects Windows, Linux, and macOS across all architectures.

Is authentication required to exploit this flaw?

No, the vulnerability can be exploited by an unauthorized attacker without authentication.