CVE-2026-50460: July Updates Fix Windows Runtime Elevation

CVE-2026-50460, a high-severity Windows Runtime vulnerability capable of enabling privilege escalation over a network, is fixed in Microsoft’s July 14, 2026 security updates. The flaw carries a CVSS 3.1 score of 8.1 and affects supported Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 installations.
Detailed in Microsoft’s Security Update Guide and the CVE record submitted to the National Vulnerability Database, the vulnerability stems from a race condition and associated use-after-free behavior in Windows Runtime. Microsoft’s assessment says an unauthenticated attacker could exploit it without user interaction, potentially compromising the confidentiality, integrity, and availability of the target system.
Microsoft has not reported active exploitation or public disclosure. CISA’s initial assessment similarly lists no known exploitation and says the attack is not readily automatable, although it considers the potential technical impact total. Administrators should therefore treat CVE-2026-50460 as an important patching priority rather than evidence of an ongoing mass-exploitation campaign.

Cybersecurity graphic warning of Windows runtime vulnerabilities, privilege escalation, and a secure July 2026 patch.A Network Attack With a Difficult Timing Requirement​

The CVSS vector assigned by Microsoft is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. That combination is unusual for an elevation-of-privilege vulnerability because the attack vector is network-accessible rather than local.
The attacker does not require an existing account or action from a signed-in user. Successful exploitation does, however, depend on high attack complexity, indicating that the attacker must satisfy conditions outside their direct control—consistent with the timing-sensitive nature of a race condition.
A race condition occurs when separate operations access or modify a shared resource without adequate synchronization. If carefully timed, those operations may execute in an unexpected order and leave Windows working with memory or state that is no longer valid.
Microsoft also associates CVE-2026-50460 with CWE-416, use after free. This class of memory-safety defect occurs when software continues using memory after it has been released. Depending on the surrounding code and an attacker’s control over memory contents, the result can range from a crash to arbitrary code execution in a more privileged security context.
The CVSS score reflects the worst successful outcome, not the probability that every exploit attempt will work. Microsoft assigns high impact values for confidentiality, integrity, and availability, meaning a working exploit could expose data, alter protected resources, and disrupt the affected system.

The Patch Reaches Across Windows Generations​

Microsoft’s affected-product record covers client and server releases spanning several Windows generations. Windows 10 Version 1809 and its server counterpart remain exposed below build 17763.9020, while Windows 10 versions 21H2 and 22H2 are affected below builds 19044.7548 and 19045.7548 respectively.
The fixed builds and July cumulative updates include:
  • Windows 10 Version 1809 and Windows Server 2019 move to build 17763.9020 through KB5099538.
  • Windows 10 versions 21H2 and 22H2 move to builds 19044.7548 and 19045.7548 through KB5099539.
  • Windows 11 versions 24H2 and 25H2 move to builds 26100.8875 and 26200.8875 through KB5101650.
  • Windows 11 version 26H1 receives KB5101649, although Microsoft’s CVE data identifies build 28000.2269 as the vulnerable-version boundary and the July cumulative update advances devices to build 28000.2525.
  • Windows Server 2022 moves to build 20348.5386 through KB5099540.
  • Windows Server 2025 and its Server Core installation move to build 26100.33158 through KB5099536.
Both x64 and Arm64 editions of supported Windows 11 releases are included. The affected Windows 10 branches also include 32-bit, x64, and, where applicable, Arm64 systems, while the listed Windows Server releases are x64-based.
Windows Server Core does not escape the issue. Microsoft explicitly lists Server Core installations of Windows Server 2019 and Windows Server 2025, which matters for organizations that use the reduced installation option to limit attack surface. Server Core removes many graphical components, but it does not eliminate vulnerabilities in shared Windows infrastructure such as Windows Runtime.
The breadth of affected releases suggests the vulnerable code exists in a long-lived Windows component rather than a feature introduced only in the latest Windows 11 branch. That does not mean every machine exposes an identical exploitable endpoint, but administrators should not use edition or interface differences as a substitute for checking the installed build.

Confidence Is High Even While Technical Detail Is Scarce​

The public record currently offers enough information to confirm the vulnerability, its broad weakness classes, affected versions, and remediation boundaries. It does not provide the vulnerable function, protocol path, proof-of-concept code, or packet-level conditions required to trigger the flaw.
That distinction is important when interpreting vulnerability-confidence metrics. CVE-2026-50460 is not merely a suspected defect inferred from an unexplained crash: Microsoft has acknowledged it, assigned the identifier and CVSS vector, identified affected products, and shipped corrected builds. Confidence in the vulnerability’s existence is consequently high, even though outsiders have limited technical knowledge about its root cause.
The absence of exploit details cuts both ways. It restricts defenders’ ability to produce vulnerability-specific detection rules, but it also makes immediate weaponization harder for attackers who must reverse-engineer the July updates to locate the changed code.
CISA’s Stakeholder-Specific Vulnerability Categorization entry recorded no evidence of exploitation on July 14. It also classified exploitation as non-automatable while assigning total technical impact. In practical terms, CISA sees a potentially severe compromise if exploitation succeeds but no present indication of a reliable, scalable attack.
Microsoft has not identified CVE-2026-50460 as one of July’s actively exploited or publicly disclosed zero-days. According to BleepingComputer’s July Patch Tuesday accounting, Microsoft addressed 570 vulnerabilities in the release, including two actively exploited flaws and one publicly disclosed zero-day; CVE-2026-50460 was not among those three.
That status should prevent unnecessary alarm, not justify deferral. Network-accessible, unauthenticated flaws can become considerably more urgent after researchers compare patched and unpatched binaries, a process known as patch diffing. A high-complexity race condition may take longer to turn into dependable exploit code, but the update itself gives researchers—and attackers—a starting point.

Deployment Risk Belongs in the Change Window​

For most client systems, the fix arrives through the normal cumulative update workflow. Enterprises using Windows Update for Business, Microsoft Intune, Configuration Manager, or WSUS should verify that the applicable July package has installed and that machines have restarted onto the corrected build.
Server administrators have an additional deployment issue to consider. Microsoft documents a known problem in the July update for Windows Server 2022 in which a limited set of devices may request the BitLocker recovery key on the first reboot. The condition involves BitLocker-protected operating-system drives, an explicitly configured PCR7 validation profile, PCR7 Binding reported as “Not Possible,” and deployment of the newer Windows Boot Manager certificate.
That known issue does not negate the CVE-2026-50460 fix, but it makes recovery-key availability and policy review sensible prerequisites for a server change window. Administrators should confirm that BitLocker recovery material is escrowed before rebooting remotely managed or physically inaccessible systems.
Microsoft also warns that July’s cumulative updates enforce registration requirements for third-party Transport Driver Interface transports. Applications using sockets over unregistered legacy TDI transports may stop working after installation. That compatibility change is separate from CVE-2026-50460, but it can complicate testing because the security correction arrives inside the same cumulative package.
Organizations unable to deploy immediately have little vulnerability-specific mitigation to rely on. Microsoft’s public CVE material does not identify a workaround, registry setting, service-disablement procedure, or network port that fully blocks the attack. General segmentation and restricting unnecessary inbound access can reduce exposure, but installing the corrected cumulative update is the definitive remediation.
The immediate task is measurable: inventory affected Windows builds, deploy the July 14 cumulative package, restart where required, and verify the resulting build number rather than relying only on an update-management success flag. CVE-2026-50460 is not known to be under attack as of July 15, 2026, but its unauthenticated network vector leaves little reason to keep vulnerable Windows Runtime code in service once compatibility testing is complete.

References​

  1. Primary source: MSRC
    Published: 2026-07-14T07:00:00-07:00
  2. Related coverage: aha.org
  3. Related coverage: tomshardware.com
 

Back
Top