CVE-2023-38180

What it actually does

This is a remotely reachable denial-of-service flaw in affected .NET Core/.NET and Visual Studio components. An unauthenticated network attacker can send specially crafted input to software using a vulnerable runtime or framework component and cause excessive resource consumption, an unhandled exception, crash, hang, or service unavailability. The impact is availability only: it is not described as enabling code execution, privilege escalation, or data disclosure.

Why it matters to the business

Successful exploitation can take .NET-based applications or development tooling offline, interrupt customer-facing services, break APIs, disrupt CI/CD or developer workflows, and trigger cascading outages where dependent services retry or fail. The risk is elevated because this vulnerability is listed in CISA KEV, has documented in-the-wild exploitation, and the federal remediation due date of 2023-08-30 has long passed; exposed internet-facing .NET services should be treated as urgent remediation targets even though ransomware use is not currently indicated.

How an attack unfolds

An attacker first identifies an application, API, service, or development-facing endpoint running an affected .NET runtime/framework version. Because the flaw is network-reachable, requires low attack complexity, no authentication, and no user interaction, the attacker can send crafted requests or inputs directly to the vulnerable component. When processed by the vulnerable .NET code path, the input causes the target process or service to consume excessive resources, fault, or become unavailable. In real operations, the attacker may repeat the request pattern across multiple instances or through load balancers to sustain the outage, degrade service health checks, force restarts, and exhaust operational capacity. Exploitation has been observed in the wild and is tracked by CISA KEV, so defenders should assume commodity scanning or opportunistic exploitation may occur against exposed vulnerable deployments.

How to fix it

Upgrade affected .NET Core/.NET and Visual Studio components to Microsoft-supported fixed releases that include the security fix. For source builds of dotnet/core, ensure the build includes commit 28577332a7c3ed4134105a80b949da96dd4b9e1f or a later trusted upstream commit/release. Apply the relevant Microsoft August 2023 or later .NET and Visual Studio security updates across runtime hosts, SDK/build images, developer workstations, CI/CD runners, containers, base images, and application platforms. Rebuild and redeploy applications that package a self-contained .NET runtime or are built from pinned container/base images. If immediate patching is not possible, reduce exposure by removing unnecessary internet access, placing vulnerable services behind authenticated gateways or WAF/rate-limiting controls, applying request size/time limits, isolating vulnerable workloads, and increasing process supervision and autoscaling safeguards. Mitigations should be treated as temporary because the vulnerability is KEV-listed and actively exploited.

How to confirm the fix worked

Inventory installed .NET runtimes, SDKs, Visual Studio versions, container images, build agents, and self-contained application deployments, then compare them with Microsoft fixed releases or confirm inclusion of dotnet/core commit 28577332a7c3ed4134105a80b949da96dd4b9e1f or later. Use `dotnet --info`, package manifests, container image SBOMs, lockfiles, and CI build metadata to verify runtime and SDK lineage. Confirm that rebuilt artifacts no longer include vulnerable runtime layers. From an exposure perspective, validate that internet-facing .NET services are patched, protected by rate limits and request controls, and no longer exhibit crashes, high resource consumption, or repeated restarts under normal traffic. Review vulnerability scanner results after patching and ensure KEV exceptions or compensating controls are closed or formally risk-accepted only where upgrade is impossible.

Typical attack path

1. Discover internet-facing or reachable services built on affected .NET Core/.NET components or systems with vulnerable Visual Studio/.NET installations.
2. Fingerprint the runtime or application behavior using HTTP responses, service banners, error behavior, package metadata, or exposed diagnostics.
3. Send crafted network input that reaches the vulnerable .NET processing path.
4. Trigger service crash, hang, high CPU, high memory consumption, thread starvation, or repeated application restarts.
5. Repeat or distribute requests to maintain service degradation and bypass simple restart-based recovery.
6. Monitor for availability impact and shift targets as services are patched, restarted, rate-limited, or isolated.

How to detect it

Detection should focus on evidence of availability attacks against .NET services rather than data-theft artifacts. Review web server, reverse proxy, WAF, load balancer, application, container orchestration, EDR, and operating system logs for bursts of unusual requests followed by .NET process crashes, hangs, restarts, elevated CPU or memory, thread-pool exhaustion, health-check failures, or sharp increases in HTTP 500/502/503/504 responses. Correlate timestamps across request logs and runtime events to identify source IPs, user agents, request paths, payload sizes, headers, protocol versions, and recurrence patterns immediately before service instability. For Windows, inspect Application event logs, Windows Error Reporting, IIS/ASP.NET logs, and process crash telemetry for dotnet.exe, w3wp.exe, iisexpress.exe, or devenv.exe failures. For Linux and containers, review journald/syslog, Kubernetes events, container restart counts, stdout/stderr, coredumps, and orchestrator OOMKilled or CrashLoopBackOff events. Because no universally reliable public exploit string is available from the provided intelligence, detections should be behavior-based and tuned to affected .NET workloads. Treat repeated unauthenticated request bursts that reliably precede .NET process termination or resource exhaustion as suspected exploitation.

• dotnet.exe
• w3wp.exe
• iisexpress.exe
• devenv.exe
• System.OutOfMemoryException
• StackOverflowException
• Process terminated
• Application Error
• Windows Error Reporting
• Faulting application name: dotnet.exe
• Faulting application name: w3wp.exe
• OOMKilled
• CrashLoopBackOff
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Prioritize patching all internet-facing .NET services and externally reachable APIs because the issue is KEV-listed and exploitation is active in the wild.
• Identify and update self-contained .NET applications, containers, serverless packages, and build images; host-level runtime updates alone may not fix bundled runtimes.
• Patch Visual Studio and .NET SDK installations on developer workstations and CI/CD runners to prevent vulnerable tooling from persisting in build pipelines.
• Search logs and telemetry for unexplained .NET process crashes, restarts, high CPU or memory exhaustion, HTTP 5xx spikes, health-check failures, and traffic bursts preceding outages.
• Apply temporary controls such as rate limiting, request body/header limits, WAF rules for anomalous request patterns, and network access restrictions until all affected assets are confirmed fixed.
• Add this CVE to KEV-driven SLA reporting and treat overdue systems as high-priority operational risk because the CISA due date has passed.
• Confirm third-party products and internal applications built on .NET have received vendor updates or have been rebuilt with fixed runtimes.