Yes. CISA added CVE-2023-38180 to its Known Exploited Vulnerabilities catalogue on 9 August 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft .NET Core and Visual Studio contain an unspecified vulnerability that allows for denial-of-service (DoS). Any organisation running the affected product should treat remediation as urgent.
What this means for Microsoft .NET Core and Visual Studio users
Because CISA placed CVE-2023-38180 in the KEV catalogue, this is not just a theoretical .NET issue, it is a known-exploited weakness that should be treated as an active exposure. If your estate includes Microsoft .NET Core or Visual Studio, the first question is whether those installations are present, reachable, and still in use on internet-facing or high-value systems.
For prioritisation, the practical rule is simple: confirmed KEV status should move remediation ahead of routine backlog work. A DoS flaw may not imply code execution, but it can still interrupt build pipelines, development tooling, hosted services, or application availability if the vulnerable component is a shared dependency or a user-facing service path.
When validating exposure, check not only installed product versions but also where the component is embedded in tooling, build servers, developer workstations, CI runners, and published applications. That distinction matters because availability loss in a developer platform can cascade into missed releases, stalled testing, or disrupted deployment workflows.
How to respond when patching cannot happen immediately
The safest response is to follow the vendor advisory and CISA KEV guidance for the exact remediation path rather than relying on general hardening advice. If the fix must wait, reduce reachability, limit who can interact with the affected service, and remove any unnecessary exposure to the vulnerable interface or host.
Temporary compensating controls should focus on blast radius reduction. For a denial-of-service condition, that usually means rate limiting, segmentation, service isolation, and heightened monitoring for repeated requests or abnormal resource exhaustion rather than trying to “detect” exploitation after the service is already unavailable.
Where the affected product sits in a shared environment, ensure that one failing instance cannot take down adjacent services. A build server, internal application, or developer platform is often more valuable as an availability target than as a direct intrusion path, so resilience controls matter even when the vulnerability is not about credential theft or remote code execution.
How to check for earlier compromise and recovery needs
For KEV-listed DoS vulnerabilities, the main compromise question is often whether the service experienced repeated crashes, hangs, or resource spikes before remediation. Review service logs, host telemetry, and any incident tickets around the CISA listing date and after, especially if users reported timeouts, failed builds, or unexplained restarts.
Use this review to decide whether the issue was a transient availability event or part of a broader attack pattern. If the vulnerable component is public-facing, correlate traffic spikes with source IPs, request patterns, and upstream load balancer or CDN metrics so you can distinguish normal load from abusive request volume.
If the service was unstable, treat recovery as a resilience exercise as well as a patch task. Validate that the application restarts cleanly, that dependent services recover in order, and that no automation depends on a brittle assumption that the vulnerable component is always available.
Risk and Threat Considerations
A known-exploited denial-of-service flaw creates immediate availability risk, and availability loss can become a business interruption even when no data is stolen. In development and build environments, the impact can include stalled releases, broken pipelines, and delayed incident response if tooling itself becomes unreliable.
Failure mechanism: An attacker can repeatedly trigger the vulnerable condition until the affected .NET Core or Visual Studio component exhausts resources, crashes, or becomes unresponsive. If the service is exposed broadly, the attacker does not need deep access to cause operational disruption.
Impact: Expect service interruption, degraded performance, and possible knock-on failure in dependent systems or delivery pipelines. If the component supports critical internal workflows, the practical consequence is lost availability, not just a local technical fault.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | CVE-2023-38180 is a KEV-listed vulnerability needing rapid prioritisation. |
| Recommendation — Prioritise and remediate KEV-listed vulnerabilities before routine backlog work. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and Events Are Detected | DoS exploitation is usually observed through service instability and abnormal traffic. |
| RC.RP-01 — Recovery Plan Is Executed | A DoS issue needs validated recovery steps for restart and service restoration. | |
| Recommendation — Monitor for repeated crashes, hangs, and abnormal request patterns on exposed services. Test and execute recovery procedures so the service can be restored quickly after disruption. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The subject is an actively exploited software flaw requiring timely remediation. |
| SC-5 — Denial of Service Protection | The vulnerability type is denial-of-service, so availability safeguards are central. | |
| Recommendation — Patch or mitigate the vulnerable component as soon as the fix is available. Apply service protection measures that limit request abuse and resource exhaustion. | ||
Practitioner Guidance
What to prioritise: Triage any KEV-listed DoS flaw ahead of ordinary patch queues when the affected product supports production, release, or customer-facing workflows. The decision point is not whether the issue has already caused an outage, but whether the system can tolerate an availability hit.
What to verify: Confirm where the vulnerable component is deployed, whether it is externally reachable, and whether a failure would interrupt a business-critical dependency. If the answer is yes, remediation should be scheduled as an urgent operational change rather than a routine maintenance item.
Practitioner takeaway: For exploited availability flaws, the key judgement is blast radius, not exploit novelty, reduce exposure first, then patch and validate that the service can survive repeat failures without cascading into a broader outage.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- How do you patch or mitigate CVE-2023-38180 (Microsoft .NET Core and Visual Studio Denial-of-Service)?
- CVE-2023-38180 (Microsoft .NET Core and Visual Studio Denial-of-Service)
- Is CVE-2023-29552 (Service Location Protocol (SLP) Denial-of-Service) being exploited in the wild?
- Is CVE-2023-28229 (Microsoft Windows CNG Key Isolation Service Privilege Escalation) being exploited in the wild?