CVE-2026-50406 is a newly documented Windows Backup Engine vulnerability that allows a locally authenticated attacker to elevate privileges through a use-after-free memory flaw. Microsoft rates the bug Important, assigns it a CVSS 3.1 base score of 7.0, and addresses it through cumulative Windows updates reaching Windows 10 and current Windows 11 releases.
Published by the Microsoft Security Response Center on July 14, 2026, the vulnerability is not remotely exploitable and was neither publicly disclosed nor known to be under active attack when the advisory appeared. Microsoft’s exploitability assessment says exploitation is unlikely, but the potential result is substantial: a successful attacker could compromise confidentiality, integrity, and availability at a high-impact level.
The National Vulnerability Database reproduces Microsoft’s technical description and identifies the underlying weakness as CWE-416, use after free. For administrators, the immediate task is straightforward: verify that affected endpoints have reached the fixed build for their Windows release rather than treating the absence of known exploitation as a reason to postpone deployment.
A use-after-free condition occurs when software continues to reference memory after that memory has been released. If an attacker can influence what replaces the freed object, the stale reference may point to attacker-controlled data, potentially turning an application crash into code execution or privilege escalation.
Microsoft has not published reproduction steps, the vulnerable Windows Backup Engine operation, or the precise privilege level gained after successful exploitation. The CVSS vector—
The attacker must already have low-level privileges and execute the attack locally. No additional user interaction is required, but Microsoft assesses attack complexity as high, indicating that exploitation depends on conditions beyond simply running a malicious executable.
That profile makes CVE-2026-50406 a post-compromise vulnerability rather than an initial-access mechanism. An attacker cannot directly target an unpatched PC over the internet using this flaw alone, but malware or an intruder with an ordinary account could potentially use it to cross a security boundary after gaining a foothold.
This distinction matters, but it should not be mistaken for low impact. Local privilege-escalation bugs frequently become the second stage in an attack chain: phishing, a malicious download, stolen credentials, or another vulnerability provides entry, and the privilege-escalation flaw supplies the authority needed to disable defenses, access protected data, establish persistence, or interfere with recovery.
Microsoft’s CVSS assessment assigns high impact to confidentiality, integrity, and availability. In practical terms, the successful outcome is not limited to viewing backup metadata or crashing a backup-related process. The scoring indicates that exploitation could give the attacker broad control over resources protected by the affected security authority.
The fixed-build boundaries are:
For Windows 11 24H2 and 25H2, the relevant July cumulative package is KB5101650, which advances the two releases to builds 26100.8875 and 26200.8875 respectively. As detailed by Microsoft and reported by BleepingComputer, the two Windows versions share the same cumulative update while retaining separate base build numbers.
Windows 10 Version 22H2 reaches build 19045.7548 through KB5099539. The appearance of Windows 10 21H2 and 22H2 in the affected data does not mean every consumer PC on those releases remains entitled to ordinary security servicing; organizations must still account for the edition, servicing channel, and Extended Security Updates status of each device.
Windows 11 26H1 is the unusual entry. Microsoft lists systems earlier than build 28000.2269 as affected, but that build was already distributed in June through KB5095051. Consequently, a 26H1 device with the June 9 cumulative update—or any later cumulative update—has already crossed the remediation threshold for CVE-2026-50406, even though the CVE itself was not published until July 14.
That chronology is a useful reminder that a CVE publication date and the first availability of corrected code do not always match. Administrators should base compliance checks on the affected-version ranges and installed builds, not solely on whether an update’s release notes visibly named the CVE at the time of installation.
For CVE-2026-50406, Microsoft’s known-exploitation fields provide the more relevant operational signal. The vulnerability was not publicly disclosed, Microsoft had not detected exploitation, and its exploitability assessment was “Exploitation Unlikely” at publication.
Those factors lower the immediate threat compared with an actively exploited zero-day, but they do not erase the patching requirement. Microsoft has now disclosed the affected component, vulnerability class, supported product ranges, and fixed build boundaries. That information gives security researchers and attackers a starting point for comparing patched and unpatched binaries.
The high attack-complexity rating may slow reliable exploit development. It can also indicate that an attacker needs favorable memory conditions, careful heap manipulation, a race, or a specific sequence of Backup Engine operations. Microsoft has not said which of those conditions applies, so any more detailed explanation would be speculation.
The safest reading is that exploitation is technically demanding rather than impossible. Systems exposed to untrusted local users, frequently executed third-party code, developer workloads, or shared-session environments deserve particular attention because the attacker’s prerequisite—some existing local access—is more plausible there.
Until Microsoft documents a configuration-based mitigation, security teams should not assume that disabling a backup schedule, removing a destination drive, or relying on third-party backup software eliminates the vulnerable code path. The official remediation is to install the applicable Windows cumulative update.
Endpoint and vulnerability-management teams can check
Testing remains appropriate, particularly on systems where backup, Volume Shadow Copy Service operations, disaster recovery, or third-party backup agents are business-critical. The update should be validated against representative restore and snapshot workflows, but validation should lead to staged deployment rather than an indefinite hold.
CVE-2026-50406 is not the July release’s most urgent issue, and Microsoft’s own assessment does not place it in the same category as an exploited zero-day. Its practical risk lies in what it can provide after another defense has already failed: a route from an ordinary local foothold to much broader control.
Windows 11 24H2 and 25H2 estates should therefore move to KB5101650 and builds 26100.8875 or 26200.8875. Windows 10 deployments should confirm build 19044.7548 or 19045.7548 as applicable, while Windows 11 26H1 devices already at build 28000.2269 or later meet Microsoft’s published remediation boundary.
Published by the Microsoft Security Response Center on July 14, 2026, the vulnerability is not remotely exploitable and was neither publicly disclosed nor known to be under active attack when the advisory appeared. Microsoft’s exploitability assessment says exploitation is unlikely, but the potential result is substantial: a successful attacker could compromise confidentiality, integrity, and availability at a high-impact level.
The National Vulnerability Database reproduces Microsoft’s technical description and identifies the underlying weakness as CWE-416, use after free. For administrators, the immediate task is straightforward: verify that affected endpoints have reached the fixed build for their Windows release rather than treating the absence of known exploitation as a reason to postpone deployment.
The Attack Starts Locally but Can End With Full Privileges
A use-after-free condition occurs when software continues to reference memory after that memory has been released. If an attacker can influence what replaces the freed object, the stale reference may point to attacker-controlled data, potentially turning an application crash into code execution or privilege escalation.Microsoft has not published reproduction steps, the vulnerable Windows Backup Engine operation, or the precise privilege level gained after successful exploitation. The CVSS vector—
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H—nevertheless outlines the expected attack path.The attacker must already have low-level privileges and execute the attack locally. No additional user interaction is required, but Microsoft assesses attack complexity as high, indicating that exploitation depends on conditions beyond simply running a malicious executable.
That profile makes CVE-2026-50406 a post-compromise vulnerability rather than an initial-access mechanism. An attacker cannot directly target an unpatched PC over the internet using this flaw alone, but malware or an intruder with an ordinary account could potentially use it to cross a security boundary after gaining a foothold.
This distinction matters, but it should not be mistaken for low impact. Local privilege-escalation bugs frequently become the second stage in an attack chain: phishing, a malicious download, stolen credentials, or another vulnerability provides entry, and the privilege-escalation flaw supplies the authority needed to disable defenses, access protected data, establish persistence, or interfere with recovery.
Microsoft’s CVSS assessment assigns high impact to confidentiality, integrity, and availability. In practical terms, the successful outcome is not limited to viewing backup metadata or crashing a backup-related process. The scoring indicates that exploitation could give the attacker broad control over resources protected by the affected security authority.
Fixed Builds Span Windows 10 Through Windows 11 26H1
Microsoft’s affected-product data covers Windows 10 Version 21H2 and 22H2 alongside Windows 11 Versions 24H2, 25H2, and 26H1. Both x64 and ARM64 Windows 11 installations are included, while the Windows 10 records additionally include 32-bit systems.The fixed-build boundaries are:
| Windows release | Install this build or later |
|---|---|
| Windows 10 Version 21H2 | 19044.7548 |
| Windows 10 Version 22H2 | 19045.7548 |
| Windows 11 Version 24H2 | 26100.8875 |
| Windows 11 Version 25H2 | 26200.8875 |
| Windows 11 Version 26H1 | 28000.2269 |
Windows 10 Version 22H2 reaches build 19045.7548 through KB5099539. The appearance of Windows 10 21H2 and 22H2 in the affected data does not mean every consumer PC on those releases remains entitled to ordinary security servicing; organizations must still account for the edition, servicing channel, and Extended Security Updates status of each device.
Windows 11 26H1 is the unusual entry. Microsoft lists systems earlier than build 28000.2269 as affected, but that build was already distributed in June through KB5095051. Consequently, a 26H1 device with the June 9 cumulative update—or any later cumulative update—has already crossed the remediation threshold for CVE-2026-50406, even though the CVE itself was not published until July 14.
That chronology is a useful reminder that a CVE publication date and the first availability of corrected code do not always match. Administrators should base compliance checks on the affected-version ranges and installed builds, not solely on whether an update’s release notes visibly named the CVE at the time of installation.
Report Confidence Is Not an Exploitation Warning
The supplied description of Microsoft’s report confidence metric can sound more alarming than it is when separated from the rest of the advisory. A “confirmed” assessment means the vulnerability’s existence and technical basis have been sufficiently established by Microsoft or supporting research. It does not mean that attackers have exploited the flaw, possess public proof-of-concept code, or can reproduce the attack reliably in ordinary conditions.For CVE-2026-50406, Microsoft’s known-exploitation fields provide the more relevant operational signal. The vulnerability was not publicly disclosed, Microsoft had not detected exploitation, and its exploitability assessment was “Exploitation Unlikely” at publication.
Those factors lower the immediate threat compared with an actively exploited zero-day, but they do not erase the patching requirement. Microsoft has now disclosed the affected component, vulnerability class, supported product ranges, and fixed build boundaries. That information gives security researchers and attackers a starting point for comparing patched and unpatched binaries.
The high attack-complexity rating may slow reliable exploit development. It can also indicate that an attacker needs favorable memory conditions, careful heap manipulation, a race, or a specific sequence of Backup Engine operations. Microsoft has not said which of those conditions applies, so any more detailed explanation would be speculation.
The safest reading is that exploitation is technically demanding rather than impossible. Systems exposed to untrusted local users, frequently executed third-party code, developer workloads, or shared-session environments deserve particular attention because the attacker’s prerequisite—some existing local access—is more plausible there.
Backup Servers Are Not the Only Systems to Check
The “Windows Backup Engine” name may lead administrators to focus only on machines running scheduled Windows backups. Microsoft’s product data, however, identifies affected operating-system builds rather than limiting exposure to Windows Server Backup installations or devices with a particular backup plan enabled.Until Microsoft documents a configuration-based mitigation, security teams should not assume that disabling a backup schedule, removing a destination drive, or relying on third-party backup software eliminates the vulnerable code path. The official remediation is to install the applicable Windows cumulative update.
Endpoint and vulnerability-management teams can check
winver, the Settings app’s Windows Update history, PowerShell inventory, Microsoft Intune, Windows Update for Business reports, Configuration Manager, or another management platform for the installed OS build. Scanners that flag the CVE after the device has reached the listed fixed build may need updated vulnerability definitions or a fresh inventory cycle.Testing remains appropriate, particularly on systems where backup, Volume Shadow Copy Service operations, disaster recovery, or third-party backup agents are business-critical. The update should be validated against representative restore and snapshot workflows, but validation should lead to staged deployment rather than an indefinite hold.
CVE-2026-50406 is not the July release’s most urgent issue, and Microsoft’s own assessment does not place it in the same category as an exploited zero-day. Its practical risk lies in what it can provide after another defense has already failed: a route from an ordinary local foothold to much broader control.
Windows 11 24H2 and 25H2 estates should therefore move to KB5101650 and builds 26100.8875 or 26200.8875. Windows 10 deployments should confirm build 19044.7548 or 19045.7548 as applicable, while Windows 11 26H1 devices already at build 28000.2269 or later meet Microsoft’s published remediation boundary.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: tomshardware.com
Windows Server vulnerability can grant system privileges with just a malformed packet — domain controllers are being exploited in the wild | Tom's Hardware
System administrators, run the May 12 patch immediately if you haven't already.www.tomshardware.com
