Microsoft’s July 14, 2026 security updates address CVE-2026-58628, an elevation-of-privilege flaw in Windows Wireless Networking that could allow an authenticated local attacker to obtain higher privileges on an affected machine. The practical action is straightforward: deploy the July cumulative update for every supported Windows client and server build in scope, particularly shared endpoints where a standard user, compromised application, or malware foothold is a realistic threat.
Microsoft’s Security Response Center lists the issue as “Windows Wireless Network Manager Elevation of Privilege Vulnerability.” The accompanying vulnerability record describes a race condition—formally CWE-362, concurrent execution using a shared resource with improper synchronization—in Windows Wireless Networking. NIST’s National Vulnerability Database has published Microsoft’s initial record and CVSS data, though it has not yet completed its own enrichment.
The flaw carries a CVSS 3.1 base score of 7.8, rated High. That score deserves context: this is not a wireless-network attack that an unauthenticated person can launch from across the room or from the Internet. Microsoft’s vector requires local access and low privileges, with no user interaction. In other words, it is best understood as a post-compromise or local-user escalation path rather than an entry point.
Race conditions arise when two or more operations run at nearly the same time and software fails to consistently control their ordering or shared state. A successful attacker may be able to force Windows into an unexpected condition between a security check and a later action.
Microsoft rates attack complexity as High, indicating that exploitation requires conditions an attacker cannot simply assume will occur on demand. That is a meaningful limiting factor, especially compared with the many low-complexity privilege-escalation bugs that tend to become routine malware components quickly.
But the potential result remains serious. The CVSS vector assigns high impacts to confidentiality, integrity, and availability, and it marks scope as changed. In plain operational terms, a successful exploit could move a process or user beyond the security boundary originally governing the vulnerable wireless-networking component, potentially opening the door to data access, system modification, or disruption that the attacker did not initially possess.
That makes CVE-2026-58628 relevant to the familiar Windows intrusion chain: initial access through a phishing attachment, browser exploit, exposed remote service, malicious installer, or abused low-privilege account; local code execution; then privilege escalation to gain durable administrative control. The vulnerability does not replace those initial-access steps, but it could make them more damaging on an unpatched device.
For administrators, the useful compliance target is the resulting operating-system build, not merely whether Windows Update says a machine is current:
Windows 10 deserves special attention. Standard support for Windows 10 version 22H2 ended on October 14, 2025, so ordinary installations need to be enrolled in Microsoft’s Extended Security Updates program to receive KB5099539 through supported channels. Windows 10 Enterprise LTSC and the corresponding Windows Server editions remain part of the affected and patched set.
Windows 11 version 23H2 is not enumerated in the affected-product configuration Microsoft supplied to NIST for this particular CVE. Administrators should not turn that omission into a reason to defer the broader July security release: organizations should continue deploying KB5099414, which brings Windows 11 23H2 to OS Build 22631.7376 and carries that month’s cumulative security content.
A Windows 11 24H2 machine, for example, should report
The July release also contains changes unrelated to CVE-2026-58628 that deserve normal deployment discipline. Microsoft’s update notes call out security hardening for third-party TDI transports. Applications using sockets over unregistered third-party TDI transports may stop working after installation, while registered transports are not affected. That is a narrower concern than the wireless privilege-escalation flaw, but it is precisely the kind of network-stack compatibility issue that calls for representative testing before broad server rollout.
Microsoft also continues to distribute updated Secure Boot certificates through Windows servicing, and its July documentation includes deployment guidance for installation media. Organizations building or refreshing Windows images should ensure that monthly Dynamic Update components and the relevant
Still, Microsoft has confirmed the condition and supplied a complete fix through standard monthly servicing. The NVD record was created from Microsoft’s disclosure on July 14, 2026 and identifies the issue as an elevation-of-privilege vulnerability with high potential impact once exploitation succeeds. Treating it as “only local” would miss how often modern endpoint incidents begin with a constrained foothold and end with administrative access.
For most organizations, CVE-2026-58628 belongs in the normal accelerated Patch Tuesday deployment ring: validate the July cumulative updates against network-sensitive line-of-business software, deploy to managed workstations and servers, and use build-level reporting to find stragglers. The remaining uncertainty is not whether a patch exists—it does—but whether unpatched endpoints will remain available when attackers need a local escalation step.
Microsoft’s Security Response Center lists the issue as “Windows Wireless Network Manager Elevation of Privilege Vulnerability.” The accompanying vulnerability record describes a race condition—formally CWE-362, concurrent execution using a shared resource with improper synchronization—in Windows Wireless Networking. NIST’s National Vulnerability Database has published Microsoft’s initial record and CVSS data, though it has not yet completed its own enrichment.
The flaw carries a CVSS 3.1 base score of 7.8, rated High. That score deserves context: this is not a wireless-network attack that an unauthenticated person can launch from across the room or from the Internet. Microsoft’s vector requires local access and low privileges, with no user interaction. In other words, it is best understood as a post-compromise or local-user escalation path rather than an entry point.
A Local Bug With a System-Wide Outcome
Race conditions arise when two or more operations run at nearly the same time and software fails to consistently control their ordering or shared state. A successful attacker may be able to force Windows into an unexpected condition between a security check and a later action.Microsoft rates attack complexity as High, indicating that exploitation requires conditions an attacker cannot simply assume will occur on demand. That is a meaningful limiting factor, especially compared with the many low-complexity privilege-escalation bugs that tend to become routine malware components quickly.
But the potential result remains serious. The CVSS vector assigns high impacts to confidentiality, integrity, and availability, and it marks scope as changed. In plain operational terms, a successful exploit could move a process or user beyond the security boundary originally governing the vulnerable wireless-networking component, potentially opening the door to data access, system modification, or disruption that the attacker did not initially possess.
That makes CVE-2026-58628 relevant to the familiar Windows intrusion chain: initial access through a phishing attachment, browser exploit, exposed remote service, malicious installer, or abused low-privilege account; local code execution; then privilege escalation to gain durable administrative control. The vulnerability does not replace those initial-access steps, but it could make them more damaging on an unpatched device.
The July Builds That Close the Exposure
According to Microsoft’s CVE record, the vulnerability affects Windows 10, current Windows 11 releases, and multiple Windows Server versions. The fix is included in the July 14 cumulative-update release train.For administrators, the useful compliance target is the resulting operating-system build, not merely whether Windows Update says a machine is current:
- Windows 11 version 24H2 is protected at OS Build 26100.8875 through KB5101650.
- Windows 11 version 25H2 is protected at OS Build 26200.8875 through KB5101650.
- Windows 11 version 26H1 is protected at OS Build 28000.2525 through KB5101649.
- Windows 10 version 22H2 is protected at OS Build 19045.7548 through KB5099539, while version 21H2 reaches 19044.7548 through the same package family.
- Windows 10 version 1809 and Windows Server 2019 are protected at OS Build 17763.9020 through KB5099538.
- Windows Server 2022 is protected at OS Build 20348.5386 through KB5099540.
- Windows Server 2025 is protected at OS Build 26100.33158 through KB5099536.
Windows 10 deserves special attention. Standard support for Windows 10 version 22H2 ended on October 14, 2025, so ordinary installations need to be enrolled in Microsoft’s Extended Security Updates program to receive KB5099539 through supported channels. Windows 10 Enterprise LTSC and the corresponding Windows Server editions remain part of the affected and patched set.
Windows 11 version 23H2 is not enumerated in the affected-product configuration Microsoft supplied to NIST for this particular CVE. Administrators should not turn that omission into a reason to defer the broader July security release: organizations should continue deploying KB5099414, which brings Windows 11 23H2 to OS Build 22631.7376 and carries that month’s cumulative security content.
Verify the Build, Then Verify the Deployment Ring
The cleanest endpoint check is the build number plus its revision, not the feature-version label alone. In PowerShell, administrators can retrieve both from the registry:
Code:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, DisplayVersion, CurrentBuildNumber, UBRCurrentBuildNumber 26100 and UBR 8875 after KB5101650. A Windows Server 2025 system should report build 26100 with revision 33158 after KB5099536.The July release also contains changes unrelated to CVE-2026-58628 that deserve normal deployment discipline. Microsoft’s update notes call out security hardening for third-party TDI transports. Applications using sockets over unregistered third-party TDI transports may stop working after installation, while registered transports are not affected. That is a narrower concern than the wireless privilege-escalation flaw, but it is precisely the kind of network-stack compatibility issue that calls for representative testing before broad server rollout.
Microsoft also continues to distribute updated Secure Boot certificates through Windows servicing, and its July documentation includes deployment guidance for installation media. Organizations building or refreshing Windows images should ensure that monthly Dynamic Update components and the relevant
boot.stl file are handled correctly, rather than treating a cumulative update solely as a live-system patch.No Evidence of a Wireless Worm, but No Reason to Wait
The available technical detail does not point to a self-propagating wireless attack or a vulnerability that can be exploited by merely placing a laptop within radio range of a target. The low-privilege requirement and High attack complexity matter. They reduce the urgency relative to an actively exploited, remote, no-authentication Windows flaw.Still, Microsoft has confirmed the condition and supplied a complete fix through standard monthly servicing. The NVD record was created from Microsoft’s disclosure on July 14, 2026 and identifies the issue as an elevation-of-privilege vulnerability with high potential impact once exploitation succeeds. Treating it as “only local” would miss how often modern endpoint incidents begin with a constrained foothold and end with administrative access.
For most organizations, CVE-2026-58628 belongs in the normal accelerated Patch Tuesday deployment ring: validate the July cumulative updates against network-sensitive line-of-business software, deploy to managed workstations and servers, and use build-level reporting to find stragglers. The remaining uncertainty is not whether a patch exists—it does—but whether unpatched endpoints will remain available when attackers need a local escalation step.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
