Microsoft’s July 14, 2026 security updates fix CVE-2026-58638, a Windows Boot Loader security feature bypass that affects supported Windows client and server releases from Windows 10 version 1809 through Windows 11 version 26H1 and Windows Server 2025. The immediate action is straightforward: deploy the July cumulative updates, then ensure that offline deployment media and recovery workflows receive the corresponding boot-component updates as well.
Microsoft describes the flaw as a “missing cryptographic step” in Windows Boot Loader. According to the National Vulnerability Database record sourced from Microsoft, a locally authorized attacker could bypass a security feature through the boot process. The vulnerability is rated Important, with a CVSS 3.1 score of 6.0 and a vector requiring local access and high privileges before exploitation.
That qualification matters. CVE-2026-58638 is not a remotely reachable entry point, and Microsoft has not indicated that it is publicly disclosed or exploited in the wild. Its danger lies elsewhere: once an attacker already has powerful access on a machine, a weakness in the pre-OS trust chain can turn an ordinary compromise into one that is much harder to detect, remove, or trust after remediation.
The Windows Boot Loader sits in the narrow but consequential gap between UEFI firmware and the Windows kernel. Security controls at that point help establish whether the operating system is starting with trusted components and expected cryptographic validation. A flaw there does not automatically mean Secure Boot is universally defeated, nor does Microsoft’s advisory make that claim. But it does mean a security control in the Windows boot path can be bypassed under the stated conditions.
The CVSS vector spells out Microsoft’s intended risk framing: local attack vector, low attack complexity, high privileges required, no user interaction, unchanged scope, high confidentiality impact, high integrity impact, and no availability impact. In practical terms, an attacker needs to have crossed significant barriers first. They would not be able to exploit this by emailing a document, scanning the internet for exposed PCs, or simply plugging in a USB device at a locked sign-in screen.
That does not make the issue trivial for enterprises. Boot-chain attacks are attractive after privilege escalation because code that executes before or alongside Windows’ normal security stack can undermine endpoint telemetry, evade some operating-system-level controls, or preserve a foothold beyond a straightforward malware cleanup. The security value of the patch is therefore less about stopping initial compromise and more about limiting what a successful intruder can do next.
Microsoft’s advisory currently provides no public technical proof of concept, workaround, or mitigation separate from installing updates. BleepingComputer’s July Patch Tuesday coverage lists the issue as “Exploitation Less Likely,” not publicly disclosed, and not known to be exploited. That is useful prioritization information, but it should not become an excuse to defer the update indefinitely on systems that handle sensitive data or have privileged local administrators.
For mainstream desktop deployments, the key packages are KB5099539 for Windows 10 version 21H2 and 22H2, KB5101650 for Windows 11 version 24H2 and 25H2, and KB5101649 for Windows 11 version 26H1. Microsoft identifies KB5099538 as the update bringing Windows 10 Enterprise LTSC 2019 and Windows Server 2019 to build 17763.9020. Windows Server 2022 receives KB5099540, while Windows Server 2025 receives KB5099536.
Administrators should use their normal Windows Update for Business, Microsoft Configuration Manager, WSUS, or Microsoft Update Catalog workflow, but should validate the resulting build number rather than rely only on approval status. A device can appear compliant in an update console while a reboot, servicing-stack prerequisite, or deployment error prevents the intended boot components from being committed.
The inclusion of Windows Server 2012 and Windows Server 2012 R2 is notable. Those platforms require Extended Security Updates for continued security servicing. Organizations still running them should verify entitlement, patch status, and the operational dependency behind the legacy server rather than assume a standard monthly update ring covers the machines.
If that file is omitted, Microsoft warns that installation media may fail to boot and return error
For those environments, the July update process should include three checks:
The same July updates add more device-targeting data for certificate deployment. On Windows 10 version 22H2, Microsoft also says the Windows Security app can report Secure Boot status dynamically. These are related operational changes, but they should not be treated as a substitute for the Boot Loader patch: certificate modernization and remediation of a missing cryptographic validation step are separate pieces of boot-chain maintenance.
This combination makes staged validation sensible, particularly for devices with third-party UEFI configurations, Linux dual boot, custom PK/KEK/db management, or tightly controlled firmware settings. The right response is not to disable Secure Boot or pause routine patching; it is to test the current Windows updates on representative hardware and confirm the expected boot posture afterward.
CVE-2026-58638 does not carry the urgency of a wormable remote-code-execution bug. But it patches a weak point where Windows is supposed to establish trust before the operating system’s usual defenses are fully in control. For security teams, the July 14 builds should become the minimum baseline—and for image-management teams, the more important test may be whether the next machine can still boot from the media they built.
Microsoft describes the flaw as a “missing cryptographic step” in Windows Boot Loader. According to the National Vulnerability Database record sourced from Microsoft, a locally authorized attacker could bypass a security feature through the boot process. The vulnerability is rated Important, with a CVSS 3.1 score of 6.0 and a vector requiring local access and high privileges before exploitation.
That qualification matters. CVE-2026-58638 is not a remotely reachable entry point, and Microsoft has not indicated that it is publicly disclosed or exploited in the wild. Its danger lies elsewhere: once an attacker already has powerful access on a machine, a weakness in the pre-OS trust chain can turn an ordinary compromise into one that is much harder to detect, remove, or trust after remediation.
A Boot Loader Fix Is Not Just Another Monthly Patch
The Windows Boot Loader sits in the narrow but consequential gap between UEFI firmware and the Windows kernel. Security controls at that point help establish whether the operating system is starting with trusted components and expected cryptographic validation. A flaw there does not automatically mean Secure Boot is universally defeated, nor does Microsoft’s advisory make that claim. But it does mean a security control in the Windows boot path can be bypassed under the stated conditions.The CVSS vector spells out Microsoft’s intended risk framing: local attack vector, low attack complexity, high privileges required, no user interaction, unchanged scope, high confidentiality impact, high integrity impact, and no availability impact. In practical terms, an attacker needs to have crossed significant barriers first. They would not be able to exploit this by emailing a document, scanning the internet for exposed PCs, or simply plugging in a USB device at a locked sign-in screen.
That does not make the issue trivial for enterprises. Boot-chain attacks are attractive after privilege escalation because code that executes before or alongside Windows’ normal security stack can undermine endpoint telemetry, evade some operating-system-level controls, or preserve a foothold beyond a straightforward malware cleanup. The security value of the patch is therefore less about stopping initial compromise and more about limiting what a successful intruder can do next.
Microsoft’s advisory currently provides no public technical proof of concept, workaround, or mitigation separate from installing updates. BleepingComputer’s July Patch Tuesday coverage lists the issue as “Exploitation Less Likely,” not publicly disclosed, and not known to be exploited. That is useful prioritization information, but it should not become an excuse to defer the update indefinitely on systems that handle sensitive data or have privileged local administrators.
The July Builds Mark the Patched Baseline
The clearest way to determine whether a system has received the fix is to check its installed cumulative update and OS build. Microsoft’s published affected-version data identifies the following patched thresholds:| Product | Patched July 14 baseline |
|---|---|
| Windows 10 version 1809 / Windows Server 2019 | OS Build 17763.9020 |
| Windows 10 version 21H2 | OS Build 19044.7548 |
| Windows 10 version 22H2 | OS Build 19045.7548 |
| Windows 11 version 24H2 | OS Build 26100.8875 |
| Windows 11 version 25H2 | OS Build 26200.8875 |
| Windows 11 version 26H1 | OS Build 28000.2525 |
| Windows Server 2012 | OS Build 9200.26226 |
| Windows Server 2012 R2 | OS Build 9600.23291 |
| Windows Server 2016 | OS Build 14393.9339 |
| Windows Server 2022 | OS Build 20348.5386 |
| Windows Server 2025 | OS Build 26100.33158 |
Administrators should use their normal Windows Update for Business, Microsoft Configuration Manager, WSUS, or Microsoft Update Catalog workflow, but should validate the resulting build number rather than rely only on approval status. A device can appear compliant in an update console while a reboot, servicing-stack prerequisite, or deployment error prevents the intended boot components from being committed.
The inclusion of Windows Server 2012 and Windows Server 2012 R2 is notable. Those platforms require Extended Security Updates for continued security servicing. Organizations still running them should verify entitlement, patch status, and the operational dependency behind the legacy server rather than assume a standard monthly update ring covers the machines.
Deployment Images Need Their Own Review
This month’s Windows release notes carry an operational warning that is especially relevant to a Boot Loader vulnerability. Microsoft says dynamic-update deployments to existing Windows images must include theboot.stl file from the updated image. The file is used during Secure Boot validation and must match the Windows version and architecture being deployed.If that file is omitted, Microsoft warns that installation media may fail to boot and return error
0xc0430001. The practical consequence is that patching live endpoints is only half the job for organizations that build or repair machines using custom WinPE, task sequences, offline WIM files, recovery drives, or bare-metal provisioning media.For those environments, the July update process should include three checks:
- Update the reference image and its applicable SafeOS and setup components, not just the installed operating-system image.
- Confirm that
boot.stlis present under the appropriateWindows\Boot\EFIpath and corresponds to the same release and architecture as the image. - Test a full bare-metal deployment and a recovery boot on representative UEFI hardware before broad rollout.
Secure Boot Certificate Work Makes Validation More Important
CVE-2026-58638 arrives while Microsoft is also continuing the rollout of newer Secure Boot certificates. The company says certificates used by many Windows devices began expiring in June 2026, and that it is delivering replacements through Windows Update for supported consumer and unmanaged business PCs.The same July updates add more device-targeting data for certificate deployment. On Windows 10 version 22H2, Microsoft also says the Windows Security app can report Secure Boot status dynamically. These are related operational changes, but they should not be treated as a substitute for the Boot Loader patch: certificate modernization and remediation of a missing cryptographic validation step are separate pieces of boot-chain maintenance.
This combination makes staged validation sensible, particularly for devices with third-party UEFI configurations, Linux dual boot, custom PK/KEK/db management, or tightly controlled firmware settings. The right response is not to disable Secure Boot or pause routine patching; it is to test the current Windows updates on representative hardware and confirm the expected boot posture afterward.
CVE-2026-58638 does not carry the urgency of a wormable remote-code-execution bug. But it patches a weak point where Windows is supposed to establish trust before the operating system’s usual defenses are fully in control. For security teams, the July 14 builds should become the minimum baseline—and for image-management teams, the more important test may be whether the next machine can still boot from the media they built.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: support.microsoft.com
KB5099415: Cumulative security update for Internet Explorer: July 14, 2026 | Microsoft Support
KB5099415: Cumulative security update for Internet Explorer: July 14, 2026support.microsoft.com - Related coverage: pcgamer.com
Security researcher describes freshly uncovered Windows 11 vulnerability as 'one of the most insane discoveries I ever found.' | PC Gamer
The king in yellow.www.pcgamer.com
