Microsoft has patched CVE-2026-47302, a denial-of-service vulnerability in .NET Framework, through the July 14, 2026 security updates. Windows administrators should treat the flaw as an availability risk for applications and services built on affected .NET Framework components and deploy the applicable cumulative updates after normal compatibility testing.
Microsoft disclosed the vulnerability in its Security Update Guide on July 14 at 7:00 a.m. Pacific time. The associated Microsoft Support documentation confirms that the fix is included in the July cumulative update for .NET Framework 3.5, 4.8, and 4.8.1 on Windows Server 2022, including KB5102206.
The public advisory identifies the security impact but offers little technical detail about the vulnerable code path or the input required to trigger it. There is also no public proof-of-concept in Microsoft’s documentation, leaving defenders with a straightforward operational response: patch the runtime rather than waiting for exploit mechanics to become clearer.
Successful exploitation of CVE-2026-47302 can cause a denial-of-service condition. In practical terms, that means an affected .NET process, application, or service could stop responding, terminate unexpectedly, or otherwise become unavailable.
Microsoft’s public material does not establish that the vulnerability permits remote code execution, privilege escalation, or disclosure of application data. That distinction matters when triaging July’s security workload, but it should not turn the flaw into a routine desktop-only update. Availability failures can still be serious when the affected process handles authentication, web requests, business transactions, scheduled jobs, monitoring, or administrative functions.
The real impact therefore depends heavily on where .NET Framework is being used. A crash in an occasional desktop utility is inconvenient; repeated termination of an IIS-hosted application, Windows service, or internal line-of-business system can become an outage.
Microsoft has not publicly detailed whether recovery requires a process restart, an application-pool recycle, or a full operating-system restart. Nor has it documented whether a hostile request can repeatedly reproduce the condition. Administrators should avoid building compensating controls around assumptions that have not yet been confirmed.
The vulnerability’s denial-of-service classification also does not reveal whether exploitation is possible directly over a network. A .NET Framework component can process untrusted data delivered through many routes, including HTTP endpoints, message queues, uploaded files, integration services, and application-specific protocols. Exposure must be evaluated at the application level rather than inferred solely from the runtime’s presence.
The update is available through Windows Update, Microsoft Update, Windows Update for Business, the Microsoft Update Catalog, and Windows Server Update Services. Microsoft says it will synchronize automatically with WSUS when Windows Server 2022 is selected as the product and Security Updates as the classification.
That delivery model makes CVE-2026-47302 primarily an operating-system servicing task for affected .NET Framework installations. It should not be confused with servicing modern .NET releases through SDK, runtime, container-image, or NuGet-package updates.
This distinction is particularly important on servers that carry both technology stacks. An inventory may show .NET 8, .NET 9, or .NET 10 alongside .NET Framework 4.8, but updating the modern runtime does not necessarily service the Windows-integrated .NET Framework installation used by older applications.
Administrators should verify the actual update applicability reported by Windows servicing, Microsoft Endpoint Configuration Manager, Windows Update for Business reporting, or their vulnerability-management platform. Microsoft’s individual Security Update Guide entry remains the authoritative place to check the complete affected-product matrix as its metadata is refined.
That bundling changes the deployment calculation. Even if an organization rates CVE-2026-47302 below an internet-facing remote-code-execution flaw, delaying the cumulative package may leave the same machines exposed to other July vulnerabilities with different consequences.
It also limits the usefulness of trying to isolate this one fix. Microsoft services supported .NET Framework releases cumulatively, so administrators generally deploy the complete applicable update rather than selecting an individual CVE correction.
Microsoft says it is not currently aware of any known issues with the Windows Server 2022 .NET update. That is useful early guidance, but it is not a substitute for testing applications that depend on legacy framework behavior, custom serialization, older ASP.NET components, Windows Communication Foundation, or vendor software with strict runtime requirements.
The safest rollout pattern remains a staged one:
Checking only the operating system’s installed-features list is not enough. .NET Framework 4.x is an in-place Windows component, while .NET Framework 3.5 may be enabled only on systems supporting older software. Application documentation, IIS configuration, service executables, software inventories, and dependency-scanning records can provide a more accurate picture.
Internet-facing and partner-facing applications should receive particular attention because they routinely process untrusted input. Internal services should not be ignored, especially where ordinary users, compromised endpoints, or external integrations can submit data that reaches a vulnerable .NET code path.
Administrators should also review restart and recovery settings for important Windows services. Automatic service recovery, application-pool health monitoring, load balancing, and redundant application nodes can reduce operational damage, but these measures do not remove the vulnerability. A repeatable denial-of-service condition can defeat simple automatic restarts and produce persistent disruption until the triggering traffic is blocked or the runtime is patched.
The vulnerability record’s confidence-related metric should not be read as a measure of business impact. Such metrics describe how firmly the flaw and its technical details have been established, not whether a particular organization can tolerate the resulting outage. Microsoft’s acknowledgement and release of corrected binaries provide the key operational fact: the vendor has confirmed a defect requiring a security update.
For Windows Server 2022, the next milestone is deployment and validation of KB5102206 or its applicable component updates. Until Microsoft publishes more information about the triggering conditions, administrators should assume that application exposure is workload-dependent and close the gap through the July cumulative servicing channel.
Microsoft disclosed the vulnerability in its Security Update Guide on July 14 at 7:00 a.m. Pacific time. The associated Microsoft Support documentation confirms that the fix is included in the July cumulative update for .NET Framework 3.5, 4.8, and 4.8.1 on Windows Server 2022, including KB5102206.
The public advisory identifies the security impact but offers little technical detail about the vulnerable code path or the input required to trigger it. There is also no public proof-of-concept in Microsoft’s documentation, leaving defenders with a straightforward operational response: patch the runtime rather than waiting for exploit mechanics to become clearer.
A Service Failure Is the Primary Risk
Successful exploitation of CVE-2026-47302 can cause a denial-of-service condition. In practical terms, that means an affected .NET process, application, or service could stop responding, terminate unexpectedly, or otherwise become unavailable.Microsoft’s public material does not establish that the vulnerability permits remote code execution, privilege escalation, or disclosure of application data. That distinction matters when triaging July’s security workload, but it should not turn the flaw into a routine desktop-only update. Availability failures can still be serious when the affected process handles authentication, web requests, business transactions, scheduled jobs, monitoring, or administrative functions.
The real impact therefore depends heavily on where .NET Framework is being used. A crash in an occasional desktop utility is inconvenient; repeated termination of an IIS-hosted application, Windows service, or internal line-of-business system can become an outage.
Microsoft has not publicly detailed whether recovery requires a process restart, an application-pool recycle, or a full operating-system restart. Nor has it documented whether a hostile request can repeatedly reproduce the condition. Administrators should avoid building compensating controls around assumptions that have not yet been confirmed.
The vulnerability’s denial-of-service classification also does not reveal whether exploitation is possible directly over a network. A .NET Framework component can process untrusted data delivered through many routes, including HTTP endpoints, message queues, uploaded files, integration services, and application-specific protocols. Exposure must be evaluated at the application level rather than inferred solely from the runtime’s presence.
Windows Server 2022 Receives the Fix Through Its .NET Rollup
Microsoft’s Windows Server 2022 documentation lists CVE-2026-47302 among the security issues addressed by KB5102206, the July 14 cumulative update for .NET Framework 3.5, 4.8, and 4.8.1. That rollup references the version-specific updates KB5101010 for .NET Framework 3.5 and 4.8 and KB5101005 for .NET Framework 3.5 and 4.8.1.The update is available through Windows Update, Microsoft Update, Windows Update for Business, the Microsoft Update Catalog, and Windows Server Update Services. Microsoft says it will synchronize automatically with WSUS when Windows Server 2022 is selected as the product and Security Updates as the classification.
That delivery model makes CVE-2026-47302 primarily an operating-system servicing task for affected .NET Framework installations. It should not be confused with servicing modern .NET releases through SDK, runtime, container-image, or NuGet-package updates.
This distinction is particularly important on servers that carry both technology stacks. An inventory may show .NET 8, .NET 9, or .NET 10 alongside .NET Framework 4.8, but updating the modern runtime does not necessarily service the Windows-integrated .NET Framework installation used by older applications.
Administrators should verify the actual update applicability reported by Windows servicing, Microsoft Endpoint Configuration Manager, Windows Update for Business reporting, or their vulnerability-management platform. Microsoft’s individual Security Update Guide entry remains the authoritative place to check the complete affected-product matrix as its metadata is refined.
The July Rollup Fixes More Than One .NET Weakness
KB5102206 is not a single-CVE patch. Microsoft’s support article lists CVE-2026-47302 alongside a substantial group of other .NET Framework vulnerabilities addressed in the same release, including additional denial-of-service flaws, a security-feature bypass, elevation-of-privilege issues, tampering, and remote-code-execution vulnerabilities.That bundling changes the deployment calculation. Even if an organization rates CVE-2026-47302 below an internet-facing remote-code-execution flaw, delaying the cumulative package may leave the same machines exposed to other July vulnerabilities with different consequences.
It also limits the usefulness of trying to isolate this one fix. Microsoft services supported .NET Framework releases cumulatively, so administrators generally deploy the complete applicable update rather than selecting an individual CVE correction.
Microsoft says it is not currently aware of any known issues with the Windows Server 2022 .NET update. That is useful early guidance, but it is not a substitute for testing applications that depend on legacy framework behavior, custom serialization, older ASP.NET components, Windows Communication Foundation, or vendor software with strict runtime requirements.
The safest rollout pattern remains a staged one:
- Install the applicable July .NET Framework update on representative test systems and lower-risk application tiers first.
- Exercise authentication, request processing, background services, scheduled tasks, reporting, and application integrations after installation.
- Monitor Windows Application logs, IIS application pools, service-control events, and application-specific health checks for new failures.
- Confirm that vulnerability scanners recognize the installed KB rather than relying only on the displayed .NET Framework version.
- Move production systems through deployment rings quickly once application validation is complete.
Sparse Disclosure Raises the Value of Runtime Inventory
The limited technical disclosure surrounding CVE-2026-47302 makes basic asset knowledge more valuable. Security teams cannot yet use a detailed description of the vulnerable API to identify every reachable application path, so they need to know which machines host .NET Framework workloads and how important those workloads are.Checking only the operating system’s installed-features list is not enough. .NET Framework 4.x is an in-place Windows component, while .NET Framework 3.5 may be enabled only on systems supporting older software. Application documentation, IIS configuration, service executables, software inventories, and dependency-scanning records can provide a more accurate picture.
Internet-facing and partner-facing applications should receive particular attention because they routinely process untrusted input. Internal services should not be ignored, especially where ordinary users, compromised endpoints, or external integrations can submit data that reaches a vulnerable .NET code path.
Administrators should also review restart and recovery settings for important Windows services. Automatic service recovery, application-pool health monitoring, load balancing, and redundant application nodes can reduce operational damage, but these measures do not remove the vulnerability. A repeatable denial-of-service condition can defeat simple automatic restarts and produce persistent disruption until the triggering traffic is blocked or the runtime is patched.
The vulnerability record’s confidence-related metric should not be read as a measure of business impact. Such metrics describe how firmly the flaw and its technical details have been established, not whether a particular organization can tolerate the resulting outage. Microsoft’s acknowledgement and release of corrected binaries provide the key operational fact: the vendor has confirmed a defect requiring a security update.
For Windows Server 2022, the next milestone is deployment and validation of KB5102206 or its applicable component updates. Until Microsoft publishes more information about the triggering conditions, administrators should assume that application exposure is workload-dependent and close the gap through the July cumulative servicing channel.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
