CVE-2026-50378, a high-severity elevation-of-privilege vulnerability in Windows Key Guard, has been fixed in Microsoft’s July 14, 2026 security updates. The flaw affects supported Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 systems, giving administrators another locally exploitable weakness to prioritize during this month’s unusually large Patch Tuesday rollout.
Microsoft assigned the vulnerability a CVSS 3.1 base score of 7.8 High. Detailed in the Microsoft Security Response Center advisory and the Microsoft-issued CVE record, the bug is a race condition that could allow an already authorized local attacker to elevate privileges without further user interaction.
The National Vulnerability Database currently lists CVE-2026-50378 as awaiting enrichment. That status means NIST has not completed its independent assessment; it does not mean the vulnerability itself is unconfirmed. Microsoft is the CVE Numbering Authority for this record and has supplied the description, affected-version data, CWE classification, and CVSS vector.
Microsoft classifies CVE-2026-50378 as CWE-362, concurrent execution using a shared resource with improper synchronization. In practical terms, two or more operations can access the same resource in an unsafe sequence, creating a timing window in which the security state may differ from what Windows expects.
Microsoft has not publicly documented the precise Windows Key Guard object, operation, or code path involved. There is also no public proof-of-concept in the material released with the advisory, so claims about obtaining SYSTEM privileges, bypassing a specific credential boundary, or extracting particular secrets would go beyond the published evidence.
The CVSS vector does establish the expected attack conditions: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. An attacker must have local access and low-level privileges, but Microsoft rates the attack complexity as low and says exploitation requires no additional user interaction. Successful exploitation could have a high effect on confidentiality, integrity, and availability while remaining inside the original Windows security scope.
That makes CVE-2026-50378 unsuitable as an initial remote compromise by itself. It is more plausibly useful after an attacker has obtained a foothold through malware, stolen credentials, a malicious document, an exposed service, or another vulnerability. Elevation-of-privilege bugs are regularly chained with those entry techniques to turn limited access into control powerful enough to disable defenses, access protected data, establish persistence, or interfere with recovery.
Microsoft’s July release includes hundreds of other vulnerabilities, and BleepingComputer reported that CVE-2026-50378 was not among the three zero-days highlighted for public disclosure or active exploitation. Administrators should therefore distinguish its high technical impact from evidence of immediate exploitation in the wild: the former is documented, while the latter has not been established in the available advisories.
Affected versions fall below these corrected build thresholds:
Windows 11 version 26H1 has a potentially confusing version trail. The CVE data uses build 28000.2269 as the vulnerable boundary, while the July cumulative update KB5101649 advances the branch to build 28000.2525. Administrators should use the current July cumulative update and the resulting installed build rather than treating the older boundary as the desired deployment target.
The presence of Windows 10 version 1809, 21H2, and 22H2 in the record does not restore support to every consumer device running those releases. Eligibility still depends on edition, servicing channel, and any applicable Extended Security Updates arrangement. A device that is outside servicing may remain vulnerable simply because it is no longer entitled to receive the cumulative update containing the fix.
Administrators do not need to determine whether users directly interact with something named “Windows Key Guard.” Microsoft lists the operating-system versions as affected, including Server Core installations, and the correction ships through normal Windows servicing. Treating the component as absent because it has no familiar management console or user-facing application would be unsafe.
On individual PCs, the installed build can be checked with
A successful update status alone is not enough. Devices can report a completed scan while still awaiting installation, sitting on a pending restart, or failing to move to the expected build because of servicing-stack, disk-space, compatibility, or policy problems. Compliance rules should therefore evaluate the resulting OS build or the installed July cumulative update, not merely the last Windows Update scan time.
Servers deserve particular attention because the vulnerability’s local attack requirement does not make them low value. A compromised application identity, remote-management account, scheduled task, or service credential may already provide the limited access needed to attempt a local privilege escalation. Server Core reduces graphical components and general attack surface, but Microsoft explicitly lists Server Core installations of Windows Server 2019 and Windows Server 2025 as affected.
Here, Microsoft has confirmed the flaw, assigned CWE-362, supplied affected-version ranges, released corrected builds, and marked the report-confidence portion of its temporal scoring as confirmed. Those factors provide strong confidence that the vulnerability exists and that Microsoft’s updates address it.
They do not establish that exploit code is publicly available or that attacks have been observed. As of July 15, 2026, the available Microsoft and NVD records do not identify CVE-2026-50378 as actively exploited or publicly disclosed before a fix was available. NVD’s independent enrichment is also still pending, leaving Microsoft’s CNA data as the main technical record.
That distinction should guide prioritization rather than delay it. CVE-2026-50378 requires an existing local foothold, but its low attack complexity, lack of user interaction, and high potential impact make it a credible link in a multi-stage intrusion. Organizations should fold the fix into their July deployment cycle, test the cumulative updates against critical workloads, and confirm that every managed endpoint and server has crossed the appropriate corrected-build threshold.
Microsoft assigned the vulnerability a CVSS 3.1 base score of 7.8 High. Detailed in the Microsoft Security Response Center advisory and the Microsoft-issued CVE record, the bug is a race condition that could allow an already authorized local attacker to elevate privileges without further user interaction.
The National Vulnerability Database currently lists CVE-2026-50378 as awaiting enrichment. That status means NIST has not completed its independent assessment; it does not mean the vulnerability itself is unconfirmed. Microsoft is the CVE Numbering Authority for this record and has supplied the description, affected-version data, CWE classification, and CVSS vector.
A Race Condition Opens the Privilege Boundary
Microsoft classifies CVE-2026-50378 as CWE-362, concurrent execution using a shared resource with improper synchronization. In practical terms, two or more operations can access the same resource in an unsafe sequence, creating a timing window in which the security state may differ from what Windows expects.Microsoft has not publicly documented the precise Windows Key Guard object, operation, or code path involved. There is also no public proof-of-concept in the material released with the advisory, so claims about obtaining SYSTEM privileges, bypassing a specific credential boundary, or extracting particular secrets would go beyond the published evidence.
The CVSS vector does establish the expected attack conditions: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. An attacker must have local access and low-level privileges, but Microsoft rates the attack complexity as low and says exploitation requires no additional user interaction. Successful exploitation could have a high effect on confidentiality, integrity, and availability while remaining inside the original Windows security scope.
That makes CVE-2026-50378 unsuitable as an initial remote compromise by itself. It is more plausibly useful after an attacker has obtained a foothold through malware, stolen credentials, a malicious document, an exposed service, or another vulnerability. Elevation-of-privilege bugs are regularly chained with those entry techniques to turn limited access into control powerful enough to disable defenses, access protected data, establish persistence, or interfere with recovery.
Microsoft’s July release includes hundreds of other vulnerabilities, and BleepingComputer reported that CVE-2026-50378 was not among the three zero-days highlighted for public disclosure or active exploitation. Administrators should therefore distinguish its high technical impact from evidence of immediate exploitation in the wild: the former is documented, while the latter has not been established in the available advisories.
The Affected Footprint Reaches Desktops and Servers
The Microsoft CVE record identifies a broad range of affected Windows releases. Both x64 and ARM64 editions are included for current Windows 11 versions, while older Windows 10 branches also cover 32-bit installations where supported.Affected versions fall below these corrected build thresholds:
- Windows 10 version 1809 systems are affected below build 17763.9020.
- Windows 10 version 21H2 systems are affected below build 19044.7548.
- Windows 10 version 22H2 systems are affected below build 19045.7548.
- Windows 11 version 24H2 systems are affected below build 26100.8875.
- Windows 11 version 25H2 systems are affected below build 26200.8875.
- Windows 11 version 26H1 systems are affected below the corrected builds identified through Microsoft’s servicing channel.
- Windows Server 2019 and its Server Core installation are affected below build 17763.9020.
- Windows Server 2022 is affected below build 20348.5386.
- Windows Server 2025 and its Server Core installation are affected below build 26100.33158.
Windows 11 version 26H1 has a potentially confusing version trail. The CVE data uses build 28000.2269 as the vulnerable boundary, while the July cumulative update KB5101649 advances the branch to build 28000.2525. Administrators should use the current July cumulative update and the resulting installed build rather than treating the older boundary as the desired deployment target.
The presence of Windows 10 version 1809, 21H2, and 22H2 in the record does not restore support to every consumer device running those releases. Eligibility still depends on edition, servicing channel, and any applicable Extended Security Updates arrangement. A device that is outside servicing may remain vulnerable simply because it is no longer entitled to receive the cumulative update containing the fix.
Build Verification Matters More Than Component Hunting
Microsoft has not published a standalone Windows Key Guard workaround or mitigation for CVE-2026-50378. The practical response is therefore to deploy the relevant July 2026 cumulative security update, restart where required, and verify that the machine reached the corrected build.Administrators do not need to determine whether users directly interact with something named “Windows Key Guard.” Microsoft lists the operating-system versions as affected, including Server Core installations, and the correction ships through normal Windows servicing. Treating the component as absent because it has no familiar management console or user-facing application would be unsafe.
On individual PCs, the installed build can be checked with
winver or under Settings, System, About. Enterprise teams can collect the same information through PowerShell, Microsoft Intune, Configuration Manager, Windows Update for Business reporting, or their endpoint-management platform.A successful update status alone is not enough. Devices can report a completed scan while still awaiting installation, sitting on a pending restart, or failing to move to the expected build because of servicing-stack, disk-space, compatibility, or policy problems. Compliance rules should therefore evaluate the resulting OS build or the installed July cumulative update, not merely the last Windows Update scan time.
Servers deserve particular attention because the vulnerability’s local attack requirement does not make them low value. A compromised application identity, remote-management account, scheduled task, or service credential may already provide the limited access needed to attempt a local privilege escalation. Server Core reduces graphical components and general attack surface, but Microsoft explicitly lists Server Core installations of Windows Server 2019 and Windows Server 2025 as affected.
High Confidence Does Not Equal Active Exploitation
The confidence language associated with vulnerability metrics can be easy to misread. It measures how firmly the vulnerability and its technical characteristics have been established, not whether attackers are currently using it.Here, Microsoft has confirmed the flaw, assigned CWE-362, supplied affected-version ranges, released corrected builds, and marked the report-confidence portion of its temporal scoring as confirmed. Those factors provide strong confidence that the vulnerability exists and that Microsoft’s updates address it.
They do not establish that exploit code is publicly available or that attacks have been observed. As of July 15, 2026, the available Microsoft and NVD records do not identify CVE-2026-50378 as actively exploited or publicly disclosed before a fix was available. NVD’s independent enrichment is also still pending, leaving Microsoft’s CNA data as the main technical record.
That distinction should guide prioritization rather than delay it. CVE-2026-50378 requires an existing local foothold, but its low attack complexity, lack of user interaction, and high potential impact make it a credible link in a multi-stage intrusion. Organizations should fold the fix into their July deployment cycle, test the cumulative updates against critical workloads, and confirm that every managed endpoint and server has crossed the appropriate corrected-build threshold.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com