CVE-2017-8585

What it actually does

This vulnerability is an unauthenticated network denial-of-service condition caused by improper input validation in affected .NET Framework versions 4.6, 4.6.1, 4.6.2, and 4.7. A remote attacker can send specially crafted HTTP requests to a .NET web application that trigger excessive resource consumption or an unhandled failure path, reducing availability of the application process or the web server worker process. The CVSS vector indicates no authentication or user interaction is required and the impact is limited to availability, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected web applications slow, unstable, or unavailable, causing service outages, failed transactions, customer-facing errors, and operational disruption. Internet-facing legacy .NET applications are the highest-priority exposure because exploitation is remote and low-complexity. This issue is not listed in CISA KEV and the supplied exploit maturity is none, but its age means vulnerable systems should be treated as unmanaged legacy risk if still present. The supplied product metadata also references omniauth/omniauth fixed at commit 01809cb63237ea76322b977c2df9d78bc5e6bb5f; organizations should verify package attribution because the CVE description is for Microsoft .NET Framework denial of service.

How an attack unfolds

An attacker first identifies an exposed web application running on an affected .NET Framework version. They then send crafted HTTP requests designed to exercise the vulnerable parsing or request-processing path. Because the issue requires no credentials and no user interaction, the attacker can repeat requests directly against the application endpoint. If vulnerable, the application or its hosting worker process consumes excessive CPU, memory, threads, or reaches an exception path, resulting in slow responses, HTTP errors, application pool recycling, or complete service unavailability. The attacker may sustain the outage by continuing to send the malformed requests or by distributing traffic across multiple sources to bypass simple rate limits.

How to fix it

Apply the Microsoft security updates that remediate CVE-2017-8585 for all affected .NET Framework installations, especially versions 4.6, 4.6.1, 4.6.2, and 4.7. Where possible, upgrade to a supported .NET Framework or modern .NET runtime with current security servicing. Restart affected application pools or hosts after patching as required by the update. If package inventories identify omniauth/omniauth as affected, validate the mapping and update to a version containing commit 01809cb63237ea76322b977c2df9d78bc5e6bb5f. Temporary mitigations include enforcing request size and header limits, blocking malformed or abusive request patterns at a WAF or reverse proxy, applying per-IP and per-route rate limits, reducing request timeouts, and isolating or disabling vulnerable legacy applications until patched.

How to confirm the fix worked

Confirm the installed .NET Framework release and patch level on all application hosts and verify that the relevant Microsoft security update is present. Validate that no production application is still running on unpatched .NET Framework 4.6, 4.6.1, 4.6.2, or 4.7. Review dependency and software composition analysis results for any package entry referencing omniauth/omniauth and confirm it includes commit 01809cb63237ea76322b977c2df9d78bc5e6bb5f if that package is genuinely in scope. Perform controlled negative testing through approved application security testing to ensure malformed requests are rejected or rate-limited without worker-process crashes, excessive resource consumption, or HTTP 500/503 spikes. Confirm IIS, reverse proxy, WAF, and application telemetry show stable CPU, memory, thread count, and response latency under malformed-request handling.

Typical attack path

1. Scan for internet-facing ASP.NET or .NET Framework web applications and identify likely legacy framework versions through headers, error pages, technology fingerprints, or application behavior.
2. Send specially crafted HTTP requests to endpoints handled by the .NET application.
3. Observe whether the target returns elevated latency, HTTP 500-series errors, connection resets, worker-process recycling, or service unavailability.
4. Repeat or automate the request pattern to keep the application unavailable.
5. Optionally vary request size, parameter structure, headers, or concurrency to evade basic blocking and maximize resource exhaustion.

How to detect it

To determine whether this was already exploited, review IIS access logs, reverse proxy logs, load balancer logs, WAF events, ASP.NET application logs, Windows Application/System event logs, and performance telemetry around periods of high latency or outages. Look for bursts of unauthenticated requests with unusual request sizes, deeply nested or repetitive parameters, abnormal headers, repeated 400/500/503 responses, connection resets, and a small number of sources producing disproportionate traffic. Correlate HTTP error spikes with application pool recycling, w3wp.exe crashes, high CPU, memory exhaustion, thread pool starvation, or .NET runtime exceptions. Because the public description does not provide a unique payload signature, detection should be behavior-based: repeated malformed requests followed by worker-process instability or resource exhaustion. If WAF logs are available, search for blocked or anomalous requests immediately preceding availability incidents. No known named threat actors or ransomware campaigns are provided for this vulnerability.

• System.OutOfMemoryException
• System.StackOverflowException
• ThreadAbortException
• w3wp.exe
• Application pool is being automatically disabled due to a series of failures
• A process serving application pool
• The worker process failed to initialize correctly
• HTTP Error 503
• HTTP Error 500.0
• sc-status=503
• sc-status=500
• Microsoft-Windows-WAS
• ASP.NET 4.0.30319.0
• aspnet_wp.exe

What your security team should do

• Prioritize patching internet-facing ASP.NET/.NET Framework applications running affected legacy versions.
• Inventory all .NET Framework 4.6 through 4.7 installations and verify current Microsoft security servicing status.
• Validate the apparent affected-product mismatch between the .NET Framework CVE description and the supplied omniauth/omniauth package metadata before closing remediation tickets.
• Add WAF and reverse-proxy controls for request size, header count, parameter count, request body limits, and suspicious malformed request bursts.
• Create monitoring for spikes in HTTP 500/503 responses, application pool recycles, worker-process crashes, thread exhaustion, memory pressure, and repeated malformed requests from the same sources.
• Review historical IIS, application, Windows Event Log, reverse proxy, load balancer, and WAF logs for outage windows or request bursts consistent with denial-of-service activity.
• Retire or isolate unsupported legacy .NET applications that cannot be patched promptly.