Microsoft disclosed CVE-2026-42984 on June 9, 2026, as an Important-rated Windows Kernel elevation-of-privilege vulnerability caused by a use-after-free flaw that lets an authenticated local attacker, after winning a race condition, gain SYSTEM privileges on supported Windows client and server releases. The company says exploitation is unlikely, not publicly disclosed, and not observed in the wild. That combination should not lull administrators into treating it as background noise. In Windows security, local kernel bugs are rarely the beginning of an intrusion, but they are often the part that turns a foothold into ownership.
CVE-2026-42984 is not a remote wormable bug, and it is not the kind of vulnerability that lets an anonymous attacker knock on a server from across the internet and immediately seize it. Microsoft’s own scoring says the attack vector is local, the attack complexity is high, and the attacker needs low privileges before exploitation. That is why the headline severity lands at Important rather than Critical.
But the prize is SYSTEM, and that changes the operational reading. A local elevation-of-privilege flaw is the tool an attacker reaches for after phishing, credential theft, malicious scripting, browser compromise, exposed RDP, or abuse of a low-privileged service account. In that second stage of an attack, “local only” is not comforting; it is the whole point.
The vulnerability sits in the Windows Kernel, the boundary that decides whether a user-mode process remains a user-mode process or crosses into the operating system’s most privileged territory. Microsoft’s summary is short but consequential: a use-after-free condition in the kernel allows an authorized attacker to elevate privileges locally. The advisory’s own FAQ adds the critical exploit note: successful exploitation requires winning a race condition.
That phrasing matters because it separates this bug from the clean, deterministic exploits that defenders dread most. Race conditions are finicky. They may depend on timing, system load, processor behavior, object lifetime, and kernel scheduling details. But finicky does not mean irrelevant, especially once exploit developers have a patch to diff and a kernel primitive to study.
That confirmation does two things at once. It gives defenders confidence that patching is addressing a real issue, not theoretical noise. It also tells attackers that the advisory is worth studying because a real kernel defect was fixed in real code.
The exploitability assessment is more restrained. Microsoft lists the vulnerability as not publicly disclosed, not exploited, and “Exploitation Unlikely” at the time of publication. That is a temporal statement, not a lifetime guarantee. It reflects what Microsoft knew on June 9, 2026, and how it judged the practical exploitability of the issue when the update shipped.
The gap between confirmed vulnerability and unlikely exploitation is where mature patch management lives. A confirmed kernel bug with no known exploitation usually belongs in the planned-but-fast lane: test quickly, deploy through rings, watch for regressions, and do not wait for exploit chatter to become incident response.
The Windows Kernel is full of object lifetimes, reference counts, callbacks, handles, and synchronization boundaries. A race condition in that environment can create a narrow moment in which one thread frees or changes an object while another thread still assumes it is valid. If an attacker can influence what occupies that freed memory next, the bug may become a path to corrupt privileged state.
Microsoft’s CVSS vector captures this shape neatly: local attack vector, high attack complexity, low privileges required, no user interaction, unchanged scope, and high impact to confidentiality, integrity, and availability. That is the profile of a bug that is hard to trigger reliably but severe when it lands. The attacker does not need a second user to click anything once they already have low-privileged code running on the machine.
The “high attack complexity” field deserves a plain-English translation. Microsoft says successful exploitation requires winning a race condition. That usually means the attacker must line up kernel behavior precisely enough to hit the vulnerable timing window, and that reliability work is often what separates a crash from a usable exploit.
Attackers have gotten better at this. Modern exploit development can spray objects, pin CPU affinity, manipulate thread priorities, create load patterns, and repeatedly trigger vulnerable code paths until the right timing appears. Endpoint security products may catch crude attempts, but kernel race exploitation does not always look like a classic file-based malware event.
That is why Microsoft’s “Exploitation Unlikely” assessment should be read as a prioritization aid, not a permission slip. It tells administrators this is not currently in the same category as an actively exploited zero-day. It does not say the bug is harmless, and it certainly does not say a motivated actor could never build working exploit code.
For enterprise defenders, the practical question is not whether every workstation is likely to be popped by CVE-2026-42984 tomorrow. It is whether unpatched local privilege escalation remains available long enough to be chained with the first successful foothold. In that chain, one weak link is often enough.
The patch mappings are split across several KB articles. Windows 11 26H1 systems receive KB5095051, while Windows 11 24H2 and 25H2 receive KB5094126. Windows 11 23H2 receives KB5093998, Windows 10 21H2 and 22H2 receive KB5094127, Windows Server 2019 and Windows 10 1809 receive KB5094123, Windows Server 2022 receives KB5094128, and Windows Server 2025 receives KB5094125.
Those KB numbers matter for administrators because vulnerability scanners, WSUS reporting, Intune deployment status, and change tickets often speak in update packages rather than CVE prose. The CVE is the security story; the KB is the thing operations teams actually have to move through the environment.
The fixed build numbers also show the spread. Examples include build 10.0.19045.7417 for Windows 10 22H2, 10.0.22631.7219 for Windows 11 23H2, 10.0.26100.8655 for Windows 11 24H2, 10.0.26200.8655 for Windows 11 25H2, 10.0.20348.5256 for Windows Server 2022, and 10.0.26100.32995 for Windows Server 2025. Windows 11 26H1 is listed at 10.0.28000.2269.
For consumer users, the answer is boring and direct: install the cumulative update offered through Windows Update if the device is eligible to receive it. For managed environments, the answer is more tangled. Windows 10 machines may sit in special-purpose pools, shared workstations, labs, manufacturing cells, kiosk deployments, or remote branches where reboots are negotiated rather than assumed.
The vulnerability does not appear to require special configuration, and Microsoft’s advisory does not advertise a workaround. That pushes remediation back to the standard Windows update machinery. If a device is affected and supported, the fix is the update; if a device is out of support or stuck on an unsupported servicing state, the security conversation becomes larger than this CVE.
This is where local privilege escalation bugs expose asset-management reality. The machines most likely to lag on patching are often the ones with the messiest operational constraints. Attackers do not need every endpoint to be vulnerable; they need one foothold, one neglected system, and one path from low privilege to high.
The risk model for servers is also different. A local attacker on a server may already have compromised a service account, abused a web application, landed through a management tool, or gained code execution via another vulnerability. A kernel elevation-of-privilege bug can then transform constrained access into control over the host.
That does not mean every server patch must be rushed into production without testing. Kernel updates deserve caution because regressions can hit drivers, endpoint agents, storage stacks, virtualization components, and security products. But caution is not the same as delay without a plan.
A good server response is ringed deployment with aggressive validation. Patch non-critical systems first, watch for boot and workload anomalies, move through application clusters, and prioritize internet-facing, multi-user, and high-value infrastructure. Domain controllers, virtualization hosts, management servers, jump boxes, and security tooling infrastructure should not be left at the end of the queue simply because the CVE is “only” Important.
CVE-2026-42984 is not a full intrusion story by itself. It does not provide initial access, and Microsoft says the attacker must already be authorized with low privileges. In a clean CVSS model, that narrows the risk.
In the real world, low-privileged access is not rare. Phished users, stolen tokens, malicious Office macros, poisoned developer dependencies, browser sandbox escapes, exposed credentials, and misconfigured remote access all create situations where an attacker can run code but still needs to escalate. A local kernel EoP is the bridge from “I am on the box” to “I own the box.”
That is why defenders should treat the advisory’s exploitability language as one signal among several. The absence of public exploit code on release day is reassuring. The presence of an official fix, a confirmed root class, and a clear SYSTEM outcome is enough to justify prompt deployment.
This is especially true for environments with many interactive users or developer workstations. Developers often have compilers, scripts, virtualization tools, package managers, and credentials that make endpoints unusually valuable. A kernel EoP on such a machine is not just an endpoint problem; it can become a source-code, CI/CD, and cloud-credential problem.
That is the good-news version of the story. The less comforting version is that coordinated disclosure also creates a post-patch race. Once the patch is out, researchers, criminals, brokers, and defenders can all examine what changed. For kernel bugs, patch diffing can reveal the vulnerable code path, the object lifetime mistake, and sometimes enough structure to begin exploit development.
The advisory itself is deliberately sparse. It does not name a specific kernel subsystem, driver interface, or call path. That restraint is normal for Microsoft kernel advisories, and it is defensible when no exploitation is known. But sparse advisories also force defenders to make decisions from severity, CVSS, exploitability assessment, affected products, and the privilege outcome.
In this case, those signals are enough. The bug is confirmed. The impact is SYSTEM. The remediation is available. Waiting for a proof of concept before acting would be a poor bargain.
The danger of routine is flattening. A kernel EoP, a spoofing issue, a browser bug, and a low-impact information disclosure can all become rows in the same dashboard. But not all rows carry the same operational meaning.
CVE-2026-42984 should be triaged as a privilege-escalation enabler. It is most relevant on systems where low-privileged code execution is plausible and where SYSTEM compromise would materially worsen the blast radius. That includes shared endpoints, remote desktop hosts, developer machines, application servers, management servers, and security-sensitive infrastructure.
The best patch programs do not simply sort by Critical versus Important. They ask what an attacker would do with the bug after landing in the environment. By that standard, this vulnerability deserves more attention than its non-Critical label might suggest.
The second task is ring discipline. Push the update into pilot groups, validate login, VPN, endpoint detection, printing, line-of-business apps, virtualization, and storage behavior, then expand. Kernel patches can have wide effects, but indefinite deferral creates its own outage: the security kind.
The third task is detection posture. Because Microsoft says exploitation is not known, defenders should not expect a neat IOC list tied to CVE-2026-42984. Instead, watch for the behaviors that make local privilege escalation useful: suspicious child processes from user contexts, unexpected service creation, token manipulation, driver loading attempts, EDR tampering, credential dumping, and sudden SYSTEM-level execution from ordinary user activity.
Finally, administrators should not ignore least privilege just because a patch exists. Local admin sprawl, permissive service accounts, shared workstation credentials, and weak application controls make every EoP bug more damaging. Patching removes this particular known path; hardening reduces the value of the next one.
Power users and enthusiasts have a more familiar dilemma. Kernel updates can occasionally collide with niche drivers, overclocking tools, anti-cheat systems, storage utilities, VPN clients, or older hardware management software. That risk is real, but it is usually smaller than the accumulated risk of sitting on a known kernel elevation-of-privilege bug.
The sensible compromise is backup, update, verify. Create a restore point or system image if the machine is critical, apply the update, confirm the build number, and watch for driver or performance weirdness. If something breaks, troubleshoot from a patched baseline rather than treating the patch itself as optional.
For WindowsForum readers, the build numbers are useful sanity checks. Windows Update history and
Microsoft’s “Important” Label Still Describes a Dangerous Prize
CVE-2026-42984 is not a remote wormable bug, and it is not the kind of vulnerability that lets an anonymous attacker knock on a server from across the internet and immediately seize it. Microsoft’s own scoring says the attack vector is local, the attack complexity is high, and the attacker needs low privileges before exploitation. That is why the headline severity lands at Important rather than Critical.But the prize is SYSTEM, and that changes the operational reading. A local elevation-of-privilege flaw is the tool an attacker reaches for after phishing, credential theft, malicious scripting, browser compromise, exposed RDP, or abuse of a low-privileged service account. In that second stage of an attack, “local only” is not comforting; it is the whole point.
The vulnerability sits in the Windows Kernel, the boundary that decides whether a user-mode process remains a user-mode process or crosses into the operating system’s most privileged territory. Microsoft’s summary is short but consequential: a use-after-free condition in the kernel allows an authorized attacker to elevate privileges locally. The advisory’s own FAQ adds the critical exploit note: successful exploitation requires winning a race condition.
That phrasing matters because it separates this bug from the clean, deterministic exploits that defenders dread most. Race conditions are finicky. They may depend on timing, system load, processor behavior, object lifetime, and kernel scheduling details. But finicky does not mean irrelevant, especially once exploit developers have a patch to diff and a kernel primitive to study.
The Bug Is Confirmed, Even If Exploitation Is Not
The user-supplied MSRC metric language about report confidence is more than boilerplate in this case. Microsoft marks CVE-2026-42984 as confirmed, meaning the vendor acknowledges that the vulnerability exists and that the technical basis is credible. This is not rumor, scanner speculation, or a dangling CVE with no public substance behind it.That confirmation does two things at once. It gives defenders confidence that patching is addressing a real issue, not theoretical noise. It also tells attackers that the advisory is worth studying because a real kernel defect was fixed in real code.
The exploitability assessment is more restrained. Microsoft lists the vulnerability as not publicly disclosed, not exploited, and “Exploitation Unlikely” at the time of publication. That is a temporal statement, not a lifetime guarantee. It reflects what Microsoft knew on June 9, 2026, and how it judged the practical exploitability of the issue when the update shipped.
The gap between confirmed vulnerability and unlikely exploitation is where mature patch management lives. A confirmed kernel bug with no known exploitation usually belongs in the planned-but-fast lane: test quickly, deploy through rings, watch for regressions, and do not wait for exploit chatter to become incident response.
Use-After-Free Is Old, Boring, and Still Potent
A use-after-free bug occurs when software continues to use memory after it has been released. In user-mode applications, that can lead to crashes, data corruption, or code execution. In kernel-mode code, the consequences can be much more severe because the vulnerable component runs with privileges that ordinary applications do not have.The Windows Kernel is full of object lifetimes, reference counts, callbacks, handles, and synchronization boundaries. A race condition in that environment can create a narrow moment in which one thread frees or changes an object while another thread still assumes it is valid. If an attacker can influence what occupies that freed memory next, the bug may become a path to corrupt privileged state.
Microsoft’s CVSS vector captures this shape neatly: local attack vector, high attack complexity, low privileges required, no user interaction, unchanged scope, and high impact to confidentiality, integrity, and availability. That is the profile of a bug that is hard to trigger reliably but severe when it lands. The attacker does not need a second user to click anything once they already have low-privileged code running on the machine.
The “high attack complexity” field deserves a plain-English translation. Microsoft says successful exploitation requires winning a race condition. That usually means the attacker must line up kernel behavior precisely enough to hit the vulnerable timing window, and that reliability work is often what separates a crash from a usable exploit.
The Race Condition Is the Sand in the Gears
Race conditions are a paradox for defenders. On one hand, they can make exploitation unreliable enough that opportunistic attackers ignore the bug. On the other hand, once a race is engineered into a repeatable exploit, it can become a powerful local privilege escalation primitive with little warning.Attackers have gotten better at this. Modern exploit development can spray objects, pin CPU affinity, manipulate thread priorities, create load patterns, and repeatedly trigger vulnerable code paths until the right timing appears. Endpoint security products may catch crude attempts, but kernel race exploitation does not always look like a classic file-based malware event.
That is why Microsoft’s “Exploitation Unlikely” assessment should be read as a prioritization aid, not a permission slip. It tells administrators this is not currently in the same category as an actively exploited zero-day. It does not say the bug is harmless, and it certainly does not say a motivated actor could never build working exploit code.
For enterprise defenders, the practical question is not whether every workstation is likely to be popped by CVE-2026-42984 tomorrow. It is whether unpatched local privilege escalation remains available long enough to be chained with the first successful foothold. In that chain, one weak link is often enough.
The Affected List Is Broad Because the Kernel Is Shared
The update applies across a wide Windows estate: Windows 10, Windows 11, and multiple Windows Server releases, including Server Core installations. The affected list includes Windows 10 1809, 21H2, and 22H2; Windows 11 23H2, 24H2, 25H2, and 26H1; Windows Server 2019; Windows Server 2022; and Windows Server 2025. That breadth is not surprising for a kernel vulnerability, but it does increase the coordination burden.The patch mappings are split across several KB articles. Windows 11 26H1 systems receive KB5095051, while Windows 11 24H2 and 25H2 receive KB5094126. Windows 11 23H2 receives KB5093998, Windows 10 21H2 and 22H2 receive KB5094127, Windows Server 2019 and Windows 10 1809 receive KB5094123, Windows Server 2022 receives KB5094128, and Windows Server 2025 receives KB5094125.
Those KB numbers matter for administrators because vulnerability scanners, WSUS reporting, Intune deployment status, and change tickets often speak in update packages rather than CVE prose. The CVE is the security story; the KB is the thing operations teams actually have to move through the environment.
The fixed build numbers also show the spread. Examples include build 10.0.19045.7417 for Windows 10 22H2, 10.0.22631.7219 for Windows 11 23H2, 10.0.26100.8655 for Windows 11 24H2, 10.0.26200.8655 for Windows 11 25H2, 10.0.20348.5256 for Windows Server 2022, and 10.0.26100.32995 for Windows Server 2025. Windows 11 26H1 is listed at 10.0.28000.2269.
Windows 10’s Long Goodbye Makes This Patch More Awkward
The presence of Windows 10 in the affected list lands differently in mid-2026 than it would have a few years ago. Windows 10 is no longer the comfortable default client platform it once was; it is a legacy operating system many organizations are still carrying for hardware, application, procurement, or user-disruption reasons. That makes every kernel CVE a reminder that “still in the fleet” means still in the patch program.For consumer users, the answer is boring and direct: install the cumulative update offered through Windows Update if the device is eligible to receive it. For managed environments, the answer is more tangled. Windows 10 machines may sit in special-purpose pools, shared workstations, labs, manufacturing cells, kiosk deployments, or remote branches where reboots are negotiated rather than assumed.
The vulnerability does not appear to require special configuration, and Microsoft’s advisory does not advertise a workaround. That pushes remediation back to the standard Windows update machinery. If a device is affected and supported, the fix is the update; if a device is out of support or stuck on an unsupported servicing state, the security conversation becomes larger than this CVE.
This is where local privilege escalation bugs expose asset-management reality. The machines most likely to lag on patching are often the ones with the messiest operational constraints. Attackers do not need every endpoint to be vulnerable; they need one foothold, one neglected system, and one path from low privilege to high.
Server Core Is Not a Free Pass
Server Core appears in the affected list for Windows Server 2019, 2022, and 2025. That is a useful reminder that reducing the graphical shell and trimming the user interface does not remove kernel attack surface. Server Core is an excellent hardening choice for many roles, but it is not a magical boundary against kernel defects.The risk model for servers is also different. A local attacker on a server may already have compromised a service account, abused a web application, landed through a management tool, or gained code execution via another vulnerability. A kernel elevation-of-privilege bug can then transform constrained access into control over the host.
That does not mean every server patch must be rushed into production without testing. Kernel updates deserve caution because regressions can hit drivers, endpoint agents, storage stacks, virtualization components, and security products. But caution is not the same as delay without a plan.
A good server response is ringed deployment with aggressive validation. Patch non-critical systems first, watch for boot and workload anomalies, move through application clusters, and prioritize internet-facing, multi-user, and high-value infrastructure. Domain controllers, virtualization hosts, management servers, jump boxes, and security tooling infrastructure should not be left at the end of the queue simply because the CVE is “only” Important.
The Advisory Says “Unlikely,” the Attacker Says “Chainable”
Security teams live with a constant mismatch between vendor severity labels and attacker incentives. Vendors score individual vulnerabilities. Attackers assemble chains.CVE-2026-42984 is not a full intrusion story by itself. It does not provide initial access, and Microsoft says the attacker must already be authorized with low privileges. In a clean CVSS model, that narrows the risk.
In the real world, low-privileged access is not rare. Phished users, stolen tokens, malicious Office macros, poisoned developer dependencies, browser sandbox escapes, exposed credentials, and misconfigured remote access all create situations where an attacker can run code but still needs to escalate. A local kernel EoP is the bridge from “I am on the box” to “I own the box.”
That is why defenders should treat the advisory’s exploitability language as one signal among several. The absence of public exploit code on release day is reassuring. The presence of an official fix, a confirmed root class, and a clear SYSTEM outcome is enough to justify prompt deployment.
This is especially true for environments with many interactive users or developer workstations. Developers often have compilers, scripts, virtualization tools, package managers, and credentials that make endpoints unusually valuable. A kernel EoP on such a machine is not just an endpoint problem; it can become a source-code, CI/CD, and cloud-credential problem.
The Acknowledgement Points to Coordinated Research, Not Chaos
Microsoft credits Younggi Park, Hwiwon Lee, and Jongseong Kim of the SEC-agent team for reporting the issue. That acknowledgement matters because it suggests the vulnerability moved through coordinated disclosure rather than public surprise. Coordinated reporting generally gives Microsoft time to investigate, patch, and ship before technical details become widely available.That is the good-news version of the story. The less comforting version is that coordinated disclosure also creates a post-patch race. Once the patch is out, researchers, criminals, brokers, and defenders can all examine what changed. For kernel bugs, patch diffing can reveal the vulnerable code path, the object lifetime mistake, and sometimes enough structure to begin exploit development.
The advisory itself is deliberately sparse. It does not name a specific kernel subsystem, driver interface, or call path. That restraint is normal for Microsoft kernel advisories, and it is defensible when no exploitation is known. But sparse advisories also force defenders to make decisions from severity, CVSS, exploitability assessment, affected products, and the privilege outcome.
In this case, those signals are enough. The bug is confirmed. The impact is SYSTEM. The remediation is available. Waiting for a proof of concept before acting would be a poor bargain.
Patch Tuesday Is a Process Test, Not a News Event
The June 9, 2026 release date places CVE-2026-42984 in the familiar rhythm of Microsoft’s monthly security updates. That rhythm can make even meaningful vulnerabilities feel routine. Administrators see a queue of CVEs, cumulative update packages, reboots, maintenance windows, and helpdesk risk.The danger of routine is flattening. A kernel EoP, a spoofing issue, a browser bug, and a low-impact information disclosure can all become rows in the same dashboard. But not all rows carry the same operational meaning.
CVE-2026-42984 should be triaged as a privilege-escalation enabler. It is most relevant on systems where low-privileged code execution is plausible and where SYSTEM compromise would materially worsen the blast radius. That includes shared endpoints, remote desktop hosts, developer machines, application servers, management servers, and security-sensitive infrastructure.
The best patch programs do not simply sort by Critical versus Important. They ask what an attacker would do with the bug after landing in the environment. By that standard, this vulnerability deserves more attention than its non-Critical label might suggest.
Where Administrators Should Look First
The immediate task is inventory. Administrators should confirm which Windows versions are present, which KB packages apply, and whether the June 2026 cumulative updates have landed successfully. In mixed fleets, that means checking both client and server channels, x64 and ARM64 devices, and Server Core deployments that may not show up in the same operational dashboards as full GUI servers.The second task is ring discipline. Push the update into pilot groups, validate login, VPN, endpoint detection, printing, line-of-business apps, virtualization, and storage behavior, then expand. Kernel patches can have wide effects, but indefinite deferral creates its own outage: the security kind.
The third task is detection posture. Because Microsoft says exploitation is not known, defenders should not expect a neat IOC list tied to CVE-2026-42984. Instead, watch for the behaviors that make local privilege escalation useful: suspicious child processes from user contexts, unexpected service creation, token manipulation, driver loading attempts, EDR tampering, credential dumping, and sudden SYSTEM-level execution from ordinary user activity.
Finally, administrators should not ignore least privilege just because a patch exists. Local admin sprawl, permissive service accounts, shared workstation credentials, and weak application controls make every EoP bug more damaging. Patching removes this particular known path; hardening reduces the value of the next one.
Home Users Get the Simple Version, Power Users Get the Annoying One
For ordinary Windows users, CVE-2026-42984 should translate into a simple action: take the June 2026 security update when Windows Update offers it, reboot, and do not postpone indefinitely. There is no indication from Microsoft that the flaw is being exploited in the wild, so this is not a panic scenario. It is a keep-current scenario.Power users and enthusiasts have a more familiar dilemma. Kernel updates can occasionally collide with niche drivers, overclocking tools, anti-cheat systems, storage utilities, VPN clients, or older hardware management software. That risk is real, but it is usually smaller than the accumulated risk of sitting on a known kernel elevation-of-privilege bug.
The sensible compromise is backup, update, verify. Create a restore point or system image if the machine is critical, apply the update, confirm the build number, and watch for driver or performance weirdness. If something breaks, troubleshoot from a patched baseline rather than treating the patch itself as optional.
For WindowsForum readers, the build numbers are useful sanity checks. Windows Update history and
winver will not always tell the whole servicing story, but build information plus installed KB history gives a practical view of whether the fix is present.The June Kernel Fix in One Operational Pass
This vulnerability is not the loudest kind of Windows security failure, but it is exactly the sort of bug that rewards disciplined maintenance. Treat it as a privilege-escalation fix with real post-compromise value, not as an abstract CVSS row.- Microsoft published CVE-2026-42984 on June 9, 2026, and rates it Important with a CVSS 3.1 base score of 7.0.
- The vulnerability is a Windows Kernel use-after-free flaw that can allow an authenticated local attacker to gain SYSTEM privileges.
- Microsoft says exploitation requires winning a race condition, which explains the high attack complexity rating.
- Microsoft lists the issue as not publicly disclosed, not exploited, and unlikely to be exploited at the time of release.
- The affected platform list spans Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, Windows Server 2025, and Server Core installations.
- The practical mitigation is installing the relevant June 2026 security update and verifying the resulting fixed build.
References
- Primary source: MSRC
Published: 2026-06-09T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
