A denial-of-service weakness in ASP.NET Core identified as CVE-2023-36038 has forced .NET teams and Windows administrators to reassess the risk profile for applications running on the newest .NET 8 stack — particularly those hosted in IIS using the in‑process model — and to prioritize patching, architecture checks, and perimeter hardening to prevent easy, remote-induced service outages.
CVE-2023-36038 is classified as an ASP.NET Core Denial of Service vulnerability that allows a remote, unauthenticated actor to send specially crafted requests and cause an application to exhaust resources or otherwise become unavailable. Public vulnerability trackers and vendor advisories describe the bug as resulting from uncontrolled resource consumption and assign it a high severity rating consistent with an availability‑first impact profile.
The timing and the affected surface are important here: the bug was disclosed in November 2023 and is tied to early .NET 8 builds (release candidate versions). The official advisory published by the .NET/ASP.NET project clarifies that the issue specifically impacts ASP.NET Core applications hosted in IIS when running the in‑process hosting model, whereas applications hosted by Kestrel (out‑of‑process) do not exhibit the vulnerability. The recommended remediation path is to install the patched runtime or the latest .NET 8 runtime/SDK.
Note: Conflicting version labels appear across public trackers; confirm the precise runtime/SDK build fingerprints in your environment and map them to the vendor advisory before taking wide automation actions.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE-2023-36038 is classified as an ASP.NET Core Denial of Service vulnerability that allows a remote, unauthenticated actor to send specially crafted requests and cause an application to exhaust resources or otherwise become unavailable. Public vulnerability trackers and vendor advisories describe the bug as resulting from uncontrolled resource consumption and assign it a high severity rating consistent with an availability‑first impact profile. The timing and the affected surface are important here: the bug was disclosed in November 2023 and is tied to early .NET 8 builds (release candidate versions). The official advisory published by the .NET/ASP.NET project clarifies that the issue specifically impacts ASP.NET Core applications hosted in IIS when running the in‑process hosting model, whereas applications hosted by Kestrel (out‑of‑process) do not exhibit the vulnerability. The recommended remediation path is to install the patched runtime or the latest .NET 8 runtime/SDK.
What is the vulnerability, in plain technical terms?
The class: uncontrolled resource consumption (DoS)
This CVE falls under CWE‑400 — Uncontrolled Resource Consumption. Attackers can craft requests that cause the affected component to allocate, hold, or process excessive resources (CPU, memory, threads, or similar) until the host process or service becomes unresponsive. The net effect is denial of service to legitimate users.Where it lives: ASP.NET Core in IIS (in‑process)
The root cause is specific to ASP.NET Core when hosted inside IIS via the in‑process model (aspnetcorev2_inprocess). When the framework runs in-process inside the IIS worker process, certain request handling paths are executed within the IIS process boundary. That behavior is central to why this issue matters for IIS‑hosted apps and not for Kestrel-hosted apps running out‑of‑process behind a reverse proxy. The vendor advisory names the affected binary/package and hosting scenario directly.What makes it exploitable
- Network attack vector — exploit requires an HTTP request to a reachable endpoint.
- No privileges or authentication required — unauthenticated remote actors can attempt exploitation.
- Low attack complexity — described as straightforward to repeat, making exploitation practical against internet‑facing hosts.
These attributes contribute to the high urgency for internet‑facing, IIS‑hosted apps.
Affected products and version ambiguity
- The .NET/ASP.NET advisory specifically flags an ASP.NET Core package tied to 8.0 release candidates (notably the RC2 build) and says the issue was addressed in a patched build/release. The advisory lists the affected binary name (aspnetcorev2_inprocess.dll) and instructs users to update to the latest .NET 8 runtime/SDK.
- Several third‑party vulnerability aggregators list aspnetcore 8.0.0 as affected and show CVSS ratings in the high range (for example, 7.5–8.2 depending on the tracker). That apparent discrepancy — RC2 flagged by the vendor advisory vs. some trackers listing 8.0.0 — is a cautionary signal for operations teams to validate exactly which builds are installed in their environment before taking action. Where trackers differ, rely on vendor advisories and installed package metadata to map CVE → runtime/KB.
Why this matters — risk and operational exposure
- Internet‑facing IIS servers running ASP.NET Core in‑process are highest priority. Because the attacker requires only network access, any public web endpoint that uses the in‑process hosting model is a prime target.
- Low complexity and no auth make large‑scale probing and crude denial-of-service attacks practical for low-skilled attackers or opportunistic scan-and‑blast campaigns.
- Potential for cascading impact. In‑process hosting means an app crash or worker process exhaustion can destabilize the IIS site or even the application pool, requiring administrative intervention to recover — with SLA and availability implications for services.
- Containers and cloud images. Container images or PaaS offerings that bundle the vulnerable runtime expose the same risk; images must be rebuilt with patched runtimes and redeployed rather than relying on host-side patching alone.
Technical analysis — what operators and engineers need to know
How to determine whether an app is vulnerable (quick checks)
- Run dotnet --info on the host (or inside the image) to list installed SDKs and runtimes and their exact versions. Confirm whether you have RC builds or early 8.0 runtime versions.
- Inspect the application’s hosting model:
- If your app uses the in‑process hosting model (aspnetcorev2_inprocess), it's the configuration called out by the advisory.
- If your app runs under Kestrel (out‑of‑process) and IIS is only a reverse proxy, risk is lower for this specific CVE.
- Look for the presence of the in‑process worker module in deployed sites or check web.config for the in‑process host entry.
Indicators of exploitation or probing
- Sudden spikes in CPU or memory correlated to HTTP request activity.
- Repeated IIS worker process crashes or application pool recycles.
- Rapid, repeated similar requests in IIS logs targeting a single endpoint or malformed request patterns from limited IP ranges.
- Container restarts or health check failures on PaaS instances concurrently with unusual HTTP request patterns.
Why Kestrel apps are not affected (as reported)
The advisory and follow-up discussion note that the vulnerable code path is present when ASP.NET Core executes within the IIS process boundary (in‑process). When applications are hosted out‑of‑process (Kestrel behind IIS/HTTP.sys), the problematic code path isn’t exercised in the same way, so this specific vulnerability does not apply. That is a narrow and important architectural distinction — it does not imply Kestrel is immune to other, unrelated DoS vectors.Mitigations and recommended actions — prioritized playbook
Apply the following in the order shown; each step is actionable and pragmatic for enterprise operations.- Patch first (highest priority)
- Install the vendor‑recommended .NET runtime/SDK update for any hosts running affected builds. The .NET project advisory instructs updating to the latest .NET 8 runtime/SDK; do so in staging and then production per normal change control.
- If immediate patching is impossible, apply compensating controls
- Restrict network exposure: block or limit inbound access to HTTP/S endpoints at network edge for affected hosts.
- Rate-limit and WAF: use a web application firewall or edge rate limiting to throttle suspicious request patterns and malformed payloads.
- Temporary hosting change: where feasible and safe to do so, reconfigure to out‑of‑process (Kestrel) hosting if that migration can be done quickly and tested — this removes the specific in‑process exposure path for this CVE. Note that migration is nontrivial for larger estates and must be tested.
- Hardening and request‑filters
- Configure IIS Request Filtering to set conservative limits for header size, URL length, and request body size.
- Enable Dynamic IP Restrictions to automatically throttle request storms from single sources.
- Ensure front-end load balancers and CDNs enforce connection and request limits.
- Monitoring and detection
- Watch for worker process recycles and correlate with IIS logs.
- Create alerts for sudden memory/CPU spikes on web hosts tied to HTTP activity.
- Use EDR/IDS signatures tuned to anomalous HTTP patterns and maintain updated signatures matching known PoC or scanning behavior (if any become public).
- DevOps / CI pipeline updates
- Rebuild containers and images with patched runtime images and redeploy.
- Update your CI/CD pipelines to pin to patched runtime versions and add checks that prevent RC builds from being promoted to production.
- Communications & change control
- Prioritize internet-facing endpoints in your maintenance windows.
- If using managed hosting or PaaS, check provider advisories for when provider images will be updated and follow their mitigation guidance.
Detection checklist and commands
- Verify installed runtimes and SDKs
- Windows / Linux: dotnet --info
- Confirm hosting model
- Inspect web.config for in‑process hosting or check for aspnetcorev2_inprocess in the site configuration.
- Review IIS logs: look for repeated requests, abnormal header sizes, or sudden high counts from single IPs.
- Windows event logs: monitor for application pool crashes or WAS/W3SVC errors that correlate with the timeframe of suspicious traffic.
- Container images: check Dockerfile base image tags and rebuild images where runtimes are pinned to vulnerable builds.
- dotnet --info (lists Host and SDK versions)
- netstat -ano | findstr :80 (identify listening services)
- Check web.config for <aspNetCore processPath="dotnet" hostingModel="InProcess"> entries
Patch management and testing playbook
- Inventory first
- Create an inventory of every host, container image, and PaaS instance that runs ASP.NET Core; include the exact runtime/SDK versions.
- Test patches in staging
- Patch representative staging hosts, run high‑load and functional tests, and confirm no regressions.
- Schedule prioritized rollouts
- Internet‑facing IIS hosts → internal IIS hosts → container images → development machines.
- Post‑deployment validation
- Validate runtimes with dotnet --info, run smoke tests, and monitor for new or recurring process crashes.
- Rebuild artifacts and pipelines
- Update Dockerfiles, CI build agents, and developer images to use patched base images to prevent reintroduction.
Communication and supply‑chain notes for development teams
- Developers should avoid promoting pre‑release RC builds into production. The advisory tied the issue to an RC build, underlining the risk of RC artifacts in production. If RC builds are present in production, remediate urgently.
- Keep dependency scanning and SBOM practices current so that any future out‑of‑band CVE → package mappings can be quickly identified and remediated.
Forensics and incident response — what to collect if you suspect exploitation
- Capture IIS logs and full request/response traces for the suspicious window.
- Pull memory/process dumps of the worker process when under attack (if feasible without interfering with triage actions).
- Collect netflow/pcap for the timeline to characterize attack patterns and source IPs.
- Preserve container images and image metadata if containers are involved.
Editorial analysis — strengths and limits of the public record
- Strengths: The vendor advisory was explicit about the hosting model (IIS in‑process) and recommended remediation: update to the latest .NET 8 runtime/SDK. That clear scope makes remediation practical for many organizations because it allows targeted mitigation (patch or change hosting model) rather than sweeping architectural changes.
- Limitations and ambiguities: Public aggregators and trackers vary in how they list affected versions (some list aspnetcore 8.0.0 as affected). These inconsistencies stress the need for authoritative mapping between installed runtime build numbers (dotnet --info output) and the vendor's patched package. Organizations should not rely solely on third‑party feeds when deciding which hosts to patch first.
- Exploit code maturity: At disclosure, the maturity of exploit code was described as unproven / theoretical by some trackers, but the low complexity and network exposure make practical DoS attempts likely by opportunistic actors. Treat absence of public PoC as temporary — attackers often weaponize low‑complexity bugs quickly.
Practical, prioritized checklist (one‑page actionable)
- 1) Inventory all ASP.NET Core hosts and images (include exact runtime versions).
- 2) If any host runs an 8.0 RC or other early 8.0 build, schedule immediate patching to the latest .NET 8 runtime/SDK.
- 3) For unpatchable hosts: restrict inbound traffic, enable WAF rate limits, and consider switching to out‑of‑process hosting if feasible.
- 4) Update CI/CD and container base images to use patched runtimes and rebuild all artifacts.
- 5) Monitor logs and set alerts for worker process crashes and unusual request patterns.
- 6) Validate fixes in staging before broad rollout; maintain rollback plans.
Conclusion
CVE‑2023‑36038 is a high‑priority availability vulnerability for IIS‑hosted ASP.NET Core applications that underscores two perennial security truths: (1) the hosting model matters — in‑process hosting raises a different risk profile than out‑of‑process, and (2) rapidly applying vendor patches and validating runtime inventories is critical when a network‑accessible DoS bug is disclosed. The most effective single action for operators is to patch affected runtimes and rebuild images; secondarily, layer defensive controls (WAF, rate‑limits, request filtering) and tighten exposure until the patch window completes. Given the low complexity and network attack vector described in vendor advisories and trackers, treating internet‑facing IIS hosts as urgent is the correct operational posture.Note: Conflicting version labels appear across public trackers; confirm the precise runtime/SDK build fingerprints in your environment and map them to the vendor advisory before taking wide automation actions.
Source: MSRC Security Update Guide - Microsoft Security Response Center
