CVE-2026-70159: ASP.NET Core DOS Vulnerability

CVE-2026-70159 Overview

CVE-2026-70159 is a denial-of-service vulnerability in ASP.NET Core caused by allocation of resources without limits or throttling [CWE-770]. An unauthorized remote attacker can exhaust server resources over the network, degrading or halting application availability. The flaw requires no authentication, no user interaction, and low attack complexity, making it reachable from any network path exposed to untrusted clients. Microsoft published guidance for this issue in the Microsoft Security Response Center update guide. The vulnerability affects availability only; confidentiality and integrity are not impacted.

Critical Impact
Remote, unauthenticated attackers can trigger resource exhaustion in ASP.NET Core applications, resulting in denial of service for all users of the targeted web service.

Affected Products

ASP.NET Core (versions covered by the Microsoft advisory)
Web applications and APIs built on ASP.NET Core and exposed over the network
.NET-hosted services that process untrusted client requests through ASP.NET Core pipelines

Discovery Timeline

2026-10-13 - CVE-2026-70159 published to the National Vulnerability Database
2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-70159

Vulnerability Analysis

The vulnerability stems from ASP.NET Core allocating resources in response to client input without enforcing adequate limits or throttling. An attacker who can send network requests to a vulnerable endpoint can force the server to consume disproportionate memory, CPU, threads, or other finite resources. Sustained or amplified requests drive the host into resource starvation, causing the application to stop responding to legitimate traffic.

The weakness is classified under [CWE-770] (Allocation of Resources Without Limits or Throttling). This class of flaw is common in request-processing frameworks where per-request work is scaled by attacker-controlled parameters such as header counts, payload sizes, or stream frames. Because ASP.NET Core underlies large portions of modern .NET web infrastructure, the practical blast radius extends to internet-facing APIs, intranet services, and backend microservices.

Root Cause

The root cause is missing or insufficient quota enforcement on resources allocated during request handling. Server code paths accept input shaping the size or frequency of allocations without bounding the resulting cost. Microsoft's advisory describes the specific condition and the fixed component versions.

Attack Vector

Exploitation occurs over the network against any ASP.NET Core endpoint reachable by the attacker. The attacker sends crafted requests designed to maximize allocation per request or per connection. No credentials, prior access, or user interaction are required. Observable effects include elevated memory consumption, thread pool starvation, request queue growth, and eventual process termination or unresponsiveness. Public proof-of-concept code is not currently listed in the enriched data, and the Exploit Prediction Scoring System rates near-term exploitation as low but non-trivial.

No verified exploitation code is available. Refer to the Microsoft CVE-2026-70159 Update Guide for authoritative technical details.

Detection Methods for CVE-2026-70159

Indicators of Compromise

Sudden, sustained spikes in memory or CPU utilization on ASP.NET Core worker processes without a corresponding increase in legitimate traffic volume.
Growth of the Kestrel request queue, thread pool starvation events, or OutOfMemoryException entries in application logs.
Repeated requests from a narrow set of source addresses targeting a single endpoint with unusually large or malformed payloads.

Detection Strategies

Baseline per-endpoint request rate, payload size, and allocation cost, then alert on deviations consistent with resource amplification.
Correlate web server telemetry with host metrics to identify requests that trigger disproportionate memory or thread consumption.
Inspect reverse proxy and WAF logs for anomalous header counts, oversized bodies, or abnormal streaming patterns directed at ASP.NET Core services.

Monitoring Recommendations

Instrument ASP.NET Core applications with the Microsoft.AspNetCore.Hosting and Microsoft.AspNetCore.Server.Kestrel event counters and ship them to a centralized analytics platform.
Monitor process-level metrics (working set, gen2 heap size, thread count) and alert when thresholds are breached during request bursts.
Track HTTP 503, 500, and connection reset rates per endpoint to catch early-stage denial-of-service conditions.

How to Mitigate CVE-2026-70159

Immediate Actions Required

Apply the ASP.NET Core and .NET runtime updates referenced in the Microsoft CVE-2026-70159 Update Guide across all affected hosts.
Inventory ASP.NET Core applications, including container images and self-contained deployments, to confirm every instance ships a patched runtime.
Place rate limiting and request size limits in front of exposed endpoints until patch deployment is verified in production.

Patch Information

Microsoft has published fixed component versions and installation guidance in the Microsoft Security Response Center advisory. Administrators should install the updated .NET SDK and runtime packages, rebuild self-contained applications against the patched runtime, and redeploy container images that bundle the ASP.NET Core framework. Validate the fix by confirming the deployed assembly versions match those listed in the advisory.

Workarounds

Enforce request rate limiting with the ASP.NET Core rate-limiting middleware (AddRateLimiter) to cap concurrent and queued requests per client.
Configure Kestrel limits such as MaxRequestBodySize, MaxConcurrentConnections, MaxConcurrentUpgradedConnections, and request header size and count limits to bound per-request cost.
Terminate client traffic at a reverse proxy or WAF that applies connection, body-size, and request-rate ceilings before traffic reaches application code.
Isolate internet-facing ASP.NET Core workloads behind autoscaling boundaries so a single instance cannot be driven into total resource exhaustion.

bash

# Example Kestrel and rate-limiter hardening in Program.cs
builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.MaxRequestBodySize = 1_048_576;         // 1 MB
    options.Limits.MaxRequestHeaderCount = 64;
    options.Limits.MaxRequestHeadersTotalSize = 16_384;    // 16 KB
    options.Limits.MaxConcurrentConnections = 1000;
    options.Limits.MaxConcurrentUpgradedConnections = 100;
});

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("per-ip", o =>
    {
        o.PermitLimit = 100;
        o.Window = TimeSpan.FromMinutes(1);
        o.QueueLimit = 0;
    });
});