CVE-2026-50650 is a newly patched .NET Framework code-injection vulnerability that can let an unauthorized attacker elevate privileges on a Windows system. Microsoft released the fix on July 14, 2026, rating the flaw Important with a CVSS 3.1 base score of 7.8.
Detailed in Microsoft’s Security Update Guide and July .NET servicing release, the vulnerability is local rather than remotely exploitable. The attack still carries serious consequences: Microsoft’s scoring assigns high potential impact to confidentiality, integrity, and availability if exploitation succeeds.
Administrators should deploy the applicable July 2026 Windows and .NET updates rather than waiting for more technical detail. Microsoft has not reported active exploitation or public disclosure, but the weakness requires no prior privileges and could become useful to an attacker who has already gained limited access to a device.
Microsoft describes CVE-2026-50650 as an instance of improper control of generated code, classified under CWE-94. In practical terms, an affected .NET component does not adequately control code generation or interpretation, creating a route through which attacker-controlled input could be treated as executable code.
The vulnerability’s CVSS vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. That translates into a local attack with low complexity, no privileges required at the beginning of the attack, and required interaction by another user.
That combination deserves attention even though it is not a one-click attack from across the internet. An attacker must first obtain a way to operate locally and then induce a user to take an unspecified action, but Microsoft’s assessment indicates that no specialized conditions or existing account privileges are required beyond those steps.
Successful exploitation could elevate the attacker’s effective privileges and compromise all three primary security properties measured by CVSS. High confidentiality impact means protected data could be exposed; high integrity impact points to unauthorized modification; and high availability impact indicates the affected system or applications could be disrupted.
The scope remains unchanged in Microsoft’s scoring. That means exploitation affects security resources managed by the same authority as the vulnerable component rather than crossing into a separately controlled security domain. It does not make the result benign: an elevation-of-privilege path inside Windows can still turn an initial foothold into meaningful control.
CISA’s Stakeholder-Specific Vulnerability Categorization record currently lists no known exploitation and assesses the flaw as non-automatable. It nevertheless assigns a total technical impact, reinforcing the distinction between present-day exploit activity and the damage that a successful exploit could cause.
Microsoft’s records identify affected configurations involving .NET Framework 3.5 with versions 4.7.2, 4.8, and 4.8.1. Platforms listed in the available vulnerability data include Windows 10 Version 1607, Windows 10 Version 1809, Windows 10 Version 21H2, Windows 10 Version 22H2, Windows Server 2016, Windows Server 2019, and Windows Server 2022, including applicable Server Core installations.
The July .NET servicing announcement also maps CVE-2026-50650 to supported modern .NET releases. Microsoft published patched builds .NET 8.0.29, .NET 9.0.18, and .NET 10.0.10, making it important not to interpret the “.NET Framework” title as proof that newer runtime deployments can be ignored.
For IT teams, this creates two related patching paths. The in-box and Windows-serviced .NET Framework components are generally updated through the applicable operating-system or cumulative .NET Framework package, while modern .NET installations may require updated runtimes, SDKs, hosting bundles, containers, or rebuilt application images.
That distinction matters on servers where Windows Update compliance does not necessarily prove that every privately deployed .NET runtime has been serviced. Applications can carry or select their own runtime, and containerized workloads may remain vulnerable until their base images are refreshed and redeployed.
Inventory should therefore cover more than the entry displayed in Windows Update history. Administrators should identify installed .NET Framework versions, modern .NET runtimes, ASP.NET Core hosting bundles, SDK installations, self-contained applications, and container images derived from older Microsoft runtime layers.
Windows 10 Version 22H2 systems using .NET Framework 3.5, 4.8, or 4.8.1 receive the relevant fixes through KB5102203. Other supported Windows and Windows Server versions have their own applicable packages, so deployment tools should rely on Microsoft’s product applicability metadata instead of attempting to force a single KB across the estate.
Microsoft says the updates are available through Windows Update, Microsoft Update, the Microsoft Update Catalog, Windows Update for Business, and Windows Server Update Services where applicable. On WSUS-managed systems, the .NET Framework update may be delivered as part of the associated operating-system servicing process.
A restart is required if affected files are in use during installation. Microsoft recommends closing .NET Framework-based applications before applying the package, which should reduce locked-file conditions and make restart behavior more predictable.
Microsoft was not aware of any known issues with the referenced Windows Server 2022 update when it published the release. That is useful for initial deployment planning, but it is not a substitute for ring-based validation where servers host older line-of-business applications with strict runtime dependencies.
The same July package also addresses numerous other .NET and .NET Framework vulnerabilities, including denial-of-service, security-feature bypass, tampering, and remote-code-execution issues. Consequently, attempting to isolate CVE-2026-50650 from the broader cumulative update would provide little operational benefit and could leave neighboring vulnerabilities unresolved.
Those facts support normal emergency-change discipline, but not indefinite deferral. The vulnerability has low attack complexity, needs no existing attacker privileges, and carries high impact across confidentiality, integrity, and availability. Its main limiting factors are local access and required user interaction.
That profile makes CVE-2026-50650 particularly relevant to shared workstations, remote desktop hosts, development machines, build servers, help-desk systems, and application servers where users or services process content from less-trusted sources. In those environments, attackers may already have several ways to obtain limited execution without holding an administrative account.
An elevation-of-privilege flaw is also commonly used as the second stage of an intrusion. A phishing attachment, compromised developer dependency, malicious installer, or exploited user-facing application may provide initial code execution; a local privilege-escalation vulnerability can then help the attacker move beyond the restrictions of that first foothold.
User-interaction requirements should therefore be interpreted narrowly. They reduce the likelihood of fully unattended exploitation, but they do not guarantee that a conspicuous security prompt will appear or that the requested action will look obviously malicious. Microsoft has not publicly documented the precise interaction or exploit sequence.
Security teams should avoid creating detections based on speculative exploit mechanics. Until Microsoft or independent researchers publish reliable technical indicators, the more defensible controls are prompt patching, application allowlisting, endpoint behavior monitoring, least-privilege administration, and investigation of unexpected child processes launched by .NET applications.
Development and application teams have a separate task: confirm that build agents and production workloads are using the patched modern .NET releases. Images based on older .NET 8, .NET 9, or .NET 10 tags should be rebuilt from updated Microsoft images, scanned, tested, and redeployed.
Self-contained applications warrant particular attention because their runtime is bundled with the application rather than supplied centrally by Windows. Updating the machine’s shared runtime may not alter those application directories, leaving remediation dependent on a fresh application build and release.
The absence of known exploitation gives organizations room to test, but CVE-2026-50650 should remain in the July patch cycle’s active deployment queue. The concrete milestone is straightforward: affected Windows systems need their applicable cumulative .NET Framework package, while modern workloads should reach .NET 8.0.29, .NET 9.0.18, or .NET 10.0.10 and be redeployed where the runtime is bundled.
Detailed in Microsoft’s Security Update Guide and July .NET servicing release, the vulnerability is local rather than remotely exploitable. The attack still carries serious consequences: Microsoft’s scoring assigns high potential impact to confidentiality, integrity, and availability if exploitation succeeds.
Administrators should deploy the applicable July 2026 Windows and .NET updates rather than waiting for more technical detail. Microsoft has not reported active exploitation or public disclosure, but the weakness requires no prior privileges and could become useful to an attacker who has already gained limited access to a device.
Code Injection Creates a Privilege Boundary Problem
Microsoft describes CVE-2026-50650 as an instance of improper control of generated code, classified under CWE-94. In practical terms, an affected .NET component does not adequately control code generation or interpretation, creating a route through which attacker-controlled input could be treated as executable code.The vulnerability’s CVSS vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. That translates into a local attack with low complexity, no privileges required at the beginning of the attack, and required interaction by another user.
That combination deserves attention even though it is not a one-click attack from across the internet. An attacker must first obtain a way to operate locally and then induce a user to take an unspecified action, but Microsoft’s assessment indicates that no specialized conditions or existing account privileges are required beyond those steps.
Successful exploitation could elevate the attacker’s effective privileges and compromise all three primary security properties measured by CVSS. High confidentiality impact means protected data could be exposed; high integrity impact points to unauthorized modification; and high availability impact indicates the affected system or applications could be disrupted.
The scope remains unchanged in Microsoft’s scoring. That means exploitation affects security resources managed by the same authority as the vulnerable component rather than crossing into a separately controlled security domain. It does not make the result benign: an elevation-of-privilege path inside Windows can still turn an initial foothold into meaningful control.
CISA’s Stakeholder-Specific Vulnerability Categorization record currently lists no known exploitation and assesses the flaw as non-automatable. It nevertheless assigns a total technical impact, reinforcing the distinction between present-day exploit activity and the damage that a successful exploit could cause.
The Patch Reaches Beyond One .NET Framework Version
The affected-product record covers multiple generations of Microsoft’s runtime stack. It includes .NET Framework 3.5 deployments on Windows Server 2012 and Windows Server 2012 R2, as well as combined .NET Framework packages used by later Windows and Windows Server releases.Microsoft’s records identify affected configurations involving .NET Framework 3.5 with versions 4.7.2, 4.8, and 4.8.1. Platforms listed in the available vulnerability data include Windows 10 Version 1607, Windows 10 Version 1809, Windows 10 Version 21H2, Windows 10 Version 22H2, Windows Server 2016, Windows Server 2019, and Windows Server 2022, including applicable Server Core installations.
The July .NET servicing announcement also maps CVE-2026-50650 to supported modern .NET releases. Microsoft published patched builds .NET 8.0.29, .NET 9.0.18, and .NET 10.0.10, making it important not to interpret the “.NET Framework” title as proof that newer runtime deployments can be ignored.
For IT teams, this creates two related patching paths. The in-box and Windows-serviced .NET Framework components are generally updated through the applicable operating-system or cumulative .NET Framework package, while modern .NET installations may require updated runtimes, SDKs, hosting bundles, containers, or rebuilt application images.
That distinction matters on servers where Windows Update compliance does not necessarily prove that every privately deployed .NET runtime has been serviced. Applications can carry or select their own runtime, and containerized workloads may remain vulnerable until their base images are refreshed and redeployed.
Inventory should therefore cover more than the entry displayed in Windows Update history. Administrators should identify installed .NET Framework versions, modern .NET runtimes, ASP.NET Core hosting bundles, SDK installations, self-contained applications, and container images derived from older Microsoft runtime layers.
July’s Cumulative Updates Carry the Fix
Microsoft has incorporated the correction into its July 14 servicing packages. For Windows Server 2022 systems running .NET Framework 3.5 and 4.8, Microsoft identifies KB5101010 as one of the applicable cumulative updates, with KB5102206 providing related version-specific package information.Windows 10 Version 22H2 systems using .NET Framework 3.5, 4.8, or 4.8.1 receive the relevant fixes through KB5102203. Other supported Windows and Windows Server versions have their own applicable packages, so deployment tools should rely on Microsoft’s product applicability metadata instead of attempting to force a single KB across the estate.
Microsoft says the updates are available through Windows Update, Microsoft Update, the Microsoft Update Catalog, Windows Update for Business, and Windows Server Update Services where applicable. On WSUS-managed systems, the .NET Framework update may be delivered as part of the associated operating-system servicing process.
A restart is required if affected files are in use during installation. Microsoft recommends closing .NET Framework-based applications before applying the package, which should reduce locked-file conditions and make restart behavior more predictable.
Microsoft was not aware of any known issues with the referenced Windows Server 2022 update when it published the release. That is useful for initial deployment planning, but it is not a substitute for ring-based validation where servers host older line-of-business applications with strict runtime dependencies.
The same July package also addresses numerous other .NET and .NET Framework vulnerabilities, including denial-of-service, security-feature bypass, tampering, and remote-code-execution issues. Consequently, attempting to isolate CVE-2026-50650 from the broader cumulative update would provide little operational benefit and could leave neighboring vulnerabilities unresolved.
Privilege Escalation Changes the Priority Calculation
CVE-2026-50650 is not currently identified as a zero-day, and Microsoft has not reported exploitation in the wild. Zero Day Initiative’s July 2026 review likewise records the vulnerability as neither publicly disclosed nor actively exploited at release.Those facts support normal emergency-change discipline, but not indefinite deferral. The vulnerability has low attack complexity, needs no existing attacker privileges, and carries high impact across confidentiality, integrity, and availability. Its main limiting factors are local access and required user interaction.
That profile makes CVE-2026-50650 particularly relevant to shared workstations, remote desktop hosts, development machines, build servers, help-desk systems, and application servers where users or services process content from less-trusted sources. In those environments, attackers may already have several ways to obtain limited execution without holding an administrative account.
An elevation-of-privilege flaw is also commonly used as the second stage of an intrusion. A phishing attachment, compromised developer dependency, malicious installer, or exploited user-facing application may provide initial code execution; a local privilege-escalation vulnerability can then help the attacker move beyond the restrictions of that first foothold.
User-interaction requirements should therefore be interpreted narrowly. They reduce the likelihood of fully unattended exploitation, but they do not guarantee that a conspicuous security prompt will appear or that the requested action will look obviously malicious. Microsoft has not publicly documented the precise interaction or exploit sequence.
Security teams should avoid creating detections based on speculative exploit mechanics. Until Microsoft or independent researchers publish reliable technical indicators, the more defensible controls are prompt patching, application allowlisting, endpoint behavior monitoring, least-privilege administration, and investigation of unexpected child processes launched by .NET applications.
Check the Runtime, Not Just the Windows Build
For conventional Windows endpoints, the immediate action is to approve and install the applicable July 14, 2026 cumulative updates, then verify that installation completed successfully after any required restart. Managed environments should check for failed or pending updates rather than assuming that an approved WSUS or Windows Update for Business policy produced full coverage.Development and application teams have a separate task: confirm that build agents and production workloads are using the patched modern .NET releases. Images based on older .NET 8, .NET 9, or .NET 10 tags should be rebuilt from updated Microsoft images, scanned, tested, and redeployed.
Self-contained applications warrant particular attention because their runtime is bundled with the application rather than supplied centrally by Windows. Updating the machine’s shared runtime may not alter those application directories, leaving remediation dependent on a fresh application build and release.
The absence of known exploitation gives organizations room to test, but CVE-2026-50650 should remain in the July patch cycle’s active deployment queue. The concrete milestone is straightforward: affected Windows systems need their applicable cumulative .NET Framework package, while modern workloads should reach .NET 8.0.29, .NET 9.0.18, or .NET 10.0.10 and be redeployed where the runtime is bundled.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
