Microsoft disclosed CVE-2026-45657 on June 9, 2026, as a critical Windows Kernel remote code execution vulnerability affecting supported Windows 11 and Windows Server releases, with patches available through the June security updates and a CVSS base score of 9.8. The advisory is short, but the signal is loud: this is the kind of bug administrators cannot responsibly bury under ordinary monthly patch triage. Microsoft says exploitation is less likely and not currently known to be public or active, yet the vulnerability’s shape is uncomfortable enough to deserve priority treatment. A network-reachable kernel flaw is never just another line item in Patch Tuesday; it is a reminder that Windows’ most privileged code still sits directly in the path of hostile traffic.
The headline description is spare: a use-after-free in the Windows Kernel that could allow an unauthorized attacker to execute code over a network. That sentence does not give defenders packet captures, protocol fields, or a proof of concept. It does, however, tell us enough to understand the operational risk.
The CVSS vector is the real story. Network attack vector, low attack complexity, no privileges required, no user interaction, unchanged scope, and high impact across confidentiality, integrity, and availability is the classic shape of a critical remotely reachable vulnerability. In plain English, Microsoft is saying that a vulnerable machine could potentially be attacked from the network without a login, without convincing a user to open anything, and with consequences that reach system-level compromise.
The company’s FAQ narrows the likely path: specially crafted network traffic sent to a vulnerable Windows system could trigger a flaw in how the Windows kernel processes certain TCP/IP data. That does not necessarily mean every Windows endpoint is equally exposed to every attacker on the internet. It does mean the vulnerable code sits in a place administrators generally cannot uninstall, avoid, or meaningfully sandbox away.
There is an important tension in Microsoft’s own advisory. The exploitability assessment says exploitation is “less likely,” the bug was not publicly disclosed at publication, and Microsoft says it had not observed exploitation. But the report confidence is “confirmed,” the remediation level is “official fix,” and the root class includes use-after-free and heap-based buffer overflow. For enterprise defenders, that combination points to a familiar answer: do not panic, but do not wait.
The Windows kernel is the operating system’s core authority. It brokers memory, schedules processes, handles drivers, and sits beneath the user-mode services most administrators spend their lives managing. If an attacker can turn a network packet into code execution at or near that level, the usual assumptions about endpoint hardening become weaker.
That is why the “no user interaction” field matters so much. Modern security programs are built around reducing human-triggered compromise: phishing-resistant authentication, attachment detonation, browser isolation, endpoint detection, and least privilege. Those controls still matter, but a packet-triggered kernel bug asks a harsher question: what if the user never gets a chance to make a mistake?
The “privileges required: none” field sharpens the point. Microsoft is not describing a post-compromise local privilege escalation where an attacker must already have a foothold. It is describing a potential first move. Even if exploitation is not yet public, defenders have to assume researchers and criminals will study the patch diff, compare vulnerable and fixed binaries, and look for the code path Microsoft chose not to document in detail.
The strongest case for measured calm is that Microsoft says the vulnerability was not publicly disclosed and not exploited when the advisory was released. That buys defenders time. It does not buy complacency. The clock starts when the patch ships, because the fix itself becomes a map.
The Windows ecosystem has seen this pattern for decades. Patch Tuesday gives defenders binaries, but it gives attackers binaries too. If a vulnerability is easy to reach and the patch is clean enough to compare, a “less likely” exploit can move into proof-of-concept territory faster than change-control boards would prefer.
The CVSS temporal score of 8.5 reflects that Microsoft has an official fix and that exploit code maturity is listed as unproven. The base score of 9.8 reflects the underlying blast radius if exploitation works. For administrators, the distinction is not academic. Temporal scoring says something about today’s observable threat; base scoring says something about tomorrow’s worst case.
For Windows 11 26H1 systems, Microsoft lists the fixed build as 10.0.28000.2269 through KB5095051. Windows 11 25H2 systems receive the fix through KB5094126, moving to build 10.0.26200.8655. Windows 11 24H2 systems also receive KB5094126, moving to build 10.0.26100.8655.
Windows 11 23H2 systems are covered by KB5093998, with the fixed build listed as 10.0.22631.7219. Windows Server 2025 is covered by KB5094125, with build 10.0.26100.32995. Windows Server 2022 is covered by KB5094128, with build 10.0.20348.5256.
Those build numbers are not decorative. They are how patch management stops being an act of faith. In environments with mixed Windows 11 generations, Azure-hosted Windows Server workloads, on-prem domain infrastructure, and isolated management networks, administrators should verify the build state rather than assuming a green compliance dashboard caught every SKU.
Server Core deserves special attention. Many organizations treat Core as naturally safer because it removes large parts of the graphical and user-mode attack surface. That is generally true, but it does not help much when the vulnerable component is kernel network processing. A smaller Windows installation is not an exemption from a packet-facing kernel flaw.
For enterprise IT, the most important question becomes reachability. Which Windows systems accept untrusted traffic? Which sit on flat internal networks where any compromised endpoint can talk laterally? Which servers are exposed through firewall rules that nobody has reviewed since a migration project three years ago?
Consumer PCs are not off the hook, but they usually sit behind NAT, host firewalls, and home routers. Enterprise systems are different. Domain controllers, file servers, virtualization hosts, management boxes, jump servers, VPN-adjacent systems, and cloud-hosted Windows workloads often have more network paths than their owners realize.
The right response is not to invent a workaround Microsoft did not publish. The right response is to patch, verify, and use this advisory as a reason to re-check segmentation. A remotely reachable kernel flaw is most dangerous when the network is generous. If every workstation can talk to every server on every port, a single endpoint compromise can become a reconnaissance exercise against the entire Windows estate.
A use-after-free occurs when software continues to use memory after it has been released. In a kernel context, that can be devastating because the attacker’s job is to influence what occupies that memory next. A heap-based buffer overflow points to writing beyond an allocated memory region, another well-worn path from malformed input to corrupted state.
The broader industry lesson is not that Windows is uniquely careless. It is that large operating systems still carry massive bodies of performance-sensitive code written in languages and styles where memory ownership must be managed with precision. Networking stacks are particularly unforgiving because they parse hostile input by design.
Microsoft has spent years adding mitigations, hardening the kernel, tightening driver rules, and investing in automated vulnerability discovery. Those investments change the economics of exploitation, but they do not erase the underlying risk. A single reachable memory-safety flaw in the right parser can still matter more than dozens of less reachable vulnerabilities elsewhere.
This is why the first week after disclosure is often more important than the advisory’s initial exploitability label suggests. Attackers do not need Microsoft to publish a proof of concept. They can compare the before and after states, identify changed functions, infer the bug, and build test cases. That work is not trivial, but for a 9.8 kernel RCE, it is worth the effort.
Defenders should assume that the vulnerability becomes better understood over time. The absence of public exploitation on June 9, 2026, is useful information. It is not a permanent condition. If exploit code appears later, organizations that treated this as routine monthly noise will suddenly discover that routine monthly noise had a deadline.
There is also a communications challenge here. Microsoft’s Security Update Guide is built for precision, not persuasion. It gives administrators structured fields, affected products, CVSS data, and KB links. It does not always explain why one critical item deserves more urgency than another. That interpretive work falls to security teams, and in many organizations they will need to translate “network, no auth, no UI, kernel” into language executives understand.
Next are servers reachable from large internal populations. Domain controllers, certificate authorities, management servers, backup infrastructure, monitoring systems, and file servers are not merely assets; they are control points. A kernel-level RCE on one of these systems would be a serious event even if exploitation required additional constraints not visible in the advisory.
Client fleets should not be ignored. Windows 11 endpoints often move between networks, connect to VPNs, join hotel Wi-Fi, and carry privileged user sessions. A vulnerability that looks like a server problem can become a client problem when laptops sit on semi-trusted networks or when host firewalls have been weakened for troubleshooting and never restored.
The operational answer is staged urgency. Patch externally exposed servers first, then high-value internal servers, then broad endpoint rings, while watching for compatibility failures. But this is not a case for a leisurely 30-day rollout if your environment has meaningful Windows network exposure.
For Windows 11 24H2 and 25H2, KB5094126 covers multiple branches but lands on different build lines. For Windows Server 2025, KB5094125 is the relevant package. For Windows Server 2022, KB5094128 is the package to track. For Windows 11 23H2, KB5093998 is the one administrators should see in their reporting.
The reboot requirement is often where enterprise reality bites. Kernel fixes do not fully protect a system while the old kernel remains loaded. Maintenance windows, uptime targets, and clustering arrangements all matter, but they should be managed as risk decisions rather than treated as reasons to let vulnerable systems drift.
Administrators should also watch for machines that are technically supported but operationally neglected. Lab systems, VDI gold images, offline templates, disaster recovery servers, and rarely booted administrative workstations often reappear months later with exactly the vulnerabilities everyone thought were gone. A kernel RCE is the wrong class of bug to leave baked into images.
The advisory gives enough to prioritize: confirmed vulnerability, critical severity, network attack vector, no authentication, no user interaction, official fix, and no known exploitation at release. It withholds enough to avoid doing exploit developers unnecessary favors. That trade-off is imperfect, but in this case it is defensible.
The missing detail does create practical uncertainty. We do not know from the advisory alone whether specific network configurations reduce exposure, whether IPv4 and IPv6 paths differ, whether particular roles make exploitation more plausible, or whether host firewall defaults materially change the reachable attack surface. Without that detail, the safest administrative posture is to treat affected systems as broadly at risk until patched.
This is also where defenders should resist rumor-driven certainty. A critical Windows kernel TCP/IP vulnerability will attract speculation quickly. Unless Microsoft revises the advisory or credible researchers publish careful analysis, organizations should not base mitigations on forum theories, screenshots, or dramatic exploit names.
That is good news, but it comes with a paradox. Better internal discovery means more serious bugs may arrive as cleanly patched advisories rather than emergency zero-day fire drills. The danger is that defenders become numb because the absence of exploitation at publication makes every serious issue feel hypothetical.
CVE-2026-45657 should be treated as evidence that quiet disclosure can still carry major risk. The best version of the story is that Microsoft found or confirmed a dangerous kernel networking bug, shipped fixes before public exploitation, and gave administrators a chance to get ahead of attackers. That outcome only holds if administrators actually use the head start.
The industry often celebrates zero-day response because it is dramatic. The less glamorous work is patching the near-zero-day before it becomes one. That is where this vulnerability sits today.
Microsoft’s Quiet Advisory Carries a Loud Risk Profile
The headline description is spare: a use-after-free in the Windows Kernel that could allow an unauthorized attacker to execute code over a network. That sentence does not give defenders packet captures, protocol fields, or a proof of concept. It does, however, tell us enough to understand the operational risk.The CVSS vector is the real story. Network attack vector, low attack complexity, no privileges required, no user interaction, unchanged scope, and high impact across confidentiality, integrity, and availability is the classic shape of a critical remotely reachable vulnerability. In plain English, Microsoft is saying that a vulnerable machine could potentially be attacked from the network without a login, without convincing a user to open anything, and with consequences that reach system-level compromise.
The company’s FAQ narrows the likely path: specially crafted network traffic sent to a vulnerable Windows system could trigger a flaw in how the Windows kernel processes certain TCP/IP data. That does not necessarily mean every Windows endpoint is equally exposed to every attacker on the internet. It does mean the vulnerable code sits in a place administrators generally cannot uninstall, avoid, or meaningfully sandbox away.
There is an important tension in Microsoft’s own advisory. The exploitability assessment says exploitation is “less likely,” the bug was not publicly disclosed at publication, and Microsoft says it had not observed exploitation. But the report confidence is “confirmed,” the remediation level is “official fix,” and the root class includes use-after-free and heap-based buffer overflow. For enterprise defenders, that combination points to a familiar answer: do not panic, but do not wait.
The Kernel Is Where Remote Bugs Become Strategic
Remote code execution vulnerabilities are not all created equal. A bug in a desktop document parser can be serious, but it often needs a user, a file, a preview pane, or a mail flow. A bug in a server component can be severe, but exposure depends on whether the service is installed, enabled, and reachable. A kernel networking bug cuts closer to the foundation.The Windows kernel is the operating system’s core authority. It brokers memory, schedules processes, handles drivers, and sits beneath the user-mode services most administrators spend their lives managing. If an attacker can turn a network packet into code execution at or near that level, the usual assumptions about endpoint hardening become weaker.
That is why the “no user interaction” field matters so much. Modern security programs are built around reducing human-triggered compromise: phishing-resistant authentication, attachment detonation, browser isolation, endpoint detection, and least privilege. Those controls still matter, but a packet-triggered kernel bug asks a harsher question: what if the user never gets a chance to make a mistake?
The “privileges required: none” field sharpens the point. Microsoft is not describing a post-compromise local privilege escalation where an attacker must already have a foothold. It is describing a potential first move. Even if exploitation is not yet public, defenders have to assume researchers and criminals will study the patch diff, compare vulnerable and fixed binaries, and look for the code path Microsoft chose not to document in detail.
“Exploitation Less Likely” Is Not the Same as “Low Priority”
Microsoft’s exploitability index is useful, but it is often misunderstood. “Less likely” does not mean “unimportant,” and it certainly does not mean “safe to defer indefinitely.” It is an assessment at the time of publication, not a guarantee about the next week, the next month, or the behavior of skilled reverse engineers.The strongest case for measured calm is that Microsoft says the vulnerability was not publicly disclosed and not exploited when the advisory was released. That buys defenders time. It does not buy complacency. The clock starts when the patch ships, because the fix itself becomes a map.
The Windows ecosystem has seen this pattern for decades. Patch Tuesday gives defenders binaries, but it gives attackers binaries too. If a vulnerability is easy to reach and the patch is clean enough to compare, a “less likely” exploit can move into proof-of-concept territory faster than change-control boards would prefer.
The CVSS temporal score of 8.5 reflects that Microsoft has an official fix and that exploit code maturity is listed as unproven. The base score of 9.8 reflects the underlying blast radius if exploitation works. For administrators, the distinction is not academic. Temporal scoring says something about today’s observable threat; base scoring says something about tomorrow’s worst case.
The Affected Windows List Spans the Modern Fleet
CVE-2026-45657 affects a broad set of supported Microsoft platforms, including Windows 11 versions 23H2, 24H2, 25H2, and 26H1 across x64 and ARM64 where applicable, plus Windows Server 2022 and Windows Server 2025, including Server Core installations. That breadth matters because it puts the vulnerability across client and server estates rather than isolating it to a niche optional component.For Windows 11 26H1 systems, Microsoft lists the fixed build as 10.0.28000.2269 through KB5095051. Windows 11 25H2 systems receive the fix through KB5094126, moving to build 10.0.26200.8655. Windows 11 24H2 systems also receive KB5094126, moving to build 10.0.26100.8655.
Windows 11 23H2 systems are covered by KB5093998, with the fixed build listed as 10.0.22631.7219. Windows Server 2025 is covered by KB5094125, with build 10.0.26100.32995. Windows Server 2022 is covered by KB5094128, with build 10.0.20348.5256.
Those build numbers are not decorative. They are how patch management stops being an act of faith. In environments with mixed Windows 11 generations, Azure-hosted Windows Server workloads, on-prem domain infrastructure, and isolated management networks, administrators should verify the build state rather than assuming a green compliance dashboard caught every SKU.
Server Core deserves special attention. Many organizations treat Core as naturally safer because it removes large parts of the graphical and user-mode attack surface. That is generally true, but it does not help much when the vulnerable component is kernel network processing. A smaller Windows installation is not an exemption from a packet-facing kernel flaw.
The TCP/IP Clue Points Defenders Toward Network Exposure
Microsoft’s FAQ says the malicious packets could trigger a flaw in how the Windows kernel processes certain TCP/IP data. That phrasing is cautious, but it is useful. It suggests the vulnerable path is not an Office previewer, a browser engine, or an optional role buried deep in Server Manager. It is somewhere in the machinery every connected Windows system depends on.For enterprise IT, the most important question becomes reachability. Which Windows systems accept untrusted traffic? Which sit on flat internal networks where any compromised endpoint can talk laterally? Which servers are exposed through firewall rules that nobody has reviewed since a migration project three years ago?
Consumer PCs are not off the hook, but they usually sit behind NAT, host firewalls, and home routers. Enterprise systems are different. Domain controllers, file servers, virtualization hosts, management boxes, jump servers, VPN-adjacent systems, and cloud-hosted Windows workloads often have more network paths than their owners realize.
The right response is not to invent a workaround Microsoft did not publish. The right response is to patch, verify, and use this advisory as a reason to re-check segmentation. A remotely reachable kernel flaw is most dangerous when the network is generous. If every workstation can talk to every server on every port, a single endpoint compromise can become a reconnaissance exercise against the entire Windows estate.
Memory-Safety Classes Keep Haunting Windows Networking
Microsoft lists CWE-416, use-after-free, and CWE-122, heap-based buffer overflow, as the weakness categories. These are not exotic new bug classes. They are old, durable, and particularly unpleasant in low-level systems code because they turn memory lifetime and allocation mistakes into control-flow opportunities.A use-after-free occurs when software continues to use memory after it has been released. In a kernel context, that can be devastating because the attacker’s job is to influence what occupies that memory next. A heap-based buffer overflow points to writing beyond an allocated memory region, another well-worn path from malformed input to corrupted state.
The broader industry lesson is not that Windows is uniquely careless. It is that large operating systems still carry massive bodies of performance-sensitive code written in languages and styles where memory ownership must be managed with precision. Networking stacks are particularly unforgiving because they parse hostile input by design.
Microsoft has spent years adding mitigations, hardening the kernel, tightening driver rules, and investing in automated vulnerability discovery. Those investments change the economics of exploitation, but they do not erase the underlying risk. A single reachable memory-safety flaw in the right parser can still matter more than dozens of less reachable vulnerabilities elsewhere.
Patch Tuesday Is Also an Intelligence Release
Security updates do two things at once. They protect systems that install them, and they disclose enough information for others to start looking. Microsoft’s advisory is intentionally limited, but the patched binaries are not limited to Microsoft.This is why the first week after disclosure is often more important than the advisory’s initial exploitability label suggests. Attackers do not need Microsoft to publish a proof of concept. They can compare the before and after states, identify changed functions, infer the bug, and build test cases. That work is not trivial, but for a 9.8 kernel RCE, it is worth the effort.
Defenders should assume that the vulnerability becomes better understood over time. The absence of public exploitation on June 9, 2026, is useful information. It is not a permanent condition. If exploit code appears later, organizations that treated this as routine monthly noise will suddenly discover that routine monthly noise had a deadline.
There is also a communications challenge here. Microsoft’s Security Update Guide is built for precision, not persuasion. It gives administrators structured fields, affected products, CVSS data, and KB links. It does not always explain why one critical item deserves more urgency than another. That interpretive work falls to security teams, and in many organizations they will need to translate “network, no auth, no UI, kernel” into language executives understand.
Servers Need the Fast Lane, Clients Need the Wide Net
The most obvious first wave is internet-facing or partner-facing Windows Server systems. Even if a service is not directly related to TCP/IP processing in the way administrators imagine, the affected code is in the operating system. Exposure analysis should be conservative until the patch is deployed and confirmed.Next are servers reachable from large internal populations. Domain controllers, certificate authorities, management servers, backup infrastructure, monitoring systems, and file servers are not merely assets; they are control points. A kernel-level RCE on one of these systems would be a serious event even if exploitation required additional constraints not visible in the advisory.
Client fleets should not be ignored. Windows 11 endpoints often move between networks, connect to VPNs, join hotel Wi-Fi, and carry privileged user sessions. A vulnerability that looks like a server problem can become a client problem when laptops sit on semi-trusted networks or when host firewalls have been weakened for troubleshooting and never restored.
The operational answer is staged urgency. Patch externally exposed servers first, then high-value internal servers, then broad endpoint rings, while watching for compatibility failures. But this is not a case for a leisurely 30-day rollout if your environment has meaningful Windows network exposure.
Build Verification Beats Update Theater
Many Windows shops still confuse “update offered” with “update installed,” and “installed” with “rebooted into the fixed build.” CVE-2026-45657 is a reminder that patch management needs an evidence loop. The only state that matters is the running, fixed operating system build.For Windows 11 24H2 and 25H2, KB5094126 covers multiple branches but lands on different build lines. For Windows Server 2025, KB5094125 is the relevant package. For Windows Server 2022, KB5094128 is the package to track. For Windows 11 23H2, KB5093998 is the one administrators should see in their reporting.
The reboot requirement is often where enterprise reality bites. Kernel fixes do not fully protect a system while the old kernel remains loaded. Maintenance windows, uptime targets, and clustering arrangements all matter, but they should be managed as risk decisions rather than treated as reasons to let vulnerable systems drift.
Administrators should also watch for machines that are technically supported but operationally neglected. Lab systems, VDI gold images, offline templates, disaster recovery servers, and rarely booted administrative workstations often reappear months later with exactly the vulnerabilities everyone thought were gone. A kernel RCE is the wrong class of bug to leave baked into images.
The Advisory’s Restraint Is a Feature, Not a Flaw
Some readers will be frustrated that Microsoft does not publish the exact packet sequence, code path, or vulnerable function. That frustration is understandable, especially for defenders who want to write detections or assess exposure with surgical precision. But the restraint is also part of coordinated vulnerability disclosure.The advisory gives enough to prioritize: confirmed vulnerability, critical severity, network attack vector, no authentication, no user interaction, official fix, and no known exploitation at release. It withholds enough to avoid doing exploit developers unnecessary favors. That trade-off is imperfect, but in this case it is defensible.
The missing detail does create practical uncertainty. We do not know from the advisory alone whether specific network configurations reduce exposure, whether IPv4 and IPv6 paths differ, whether particular roles make exploitation more plausible, or whether host firewall defaults materially change the reachable attack surface. Without that detail, the safest administrative posture is to treat affected systems as broadly at risk until patched.
This is also where defenders should resist rumor-driven certainty. A critical Windows kernel TCP/IP vulnerability will attract speculation quickly. Unless Microsoft revises the advisory or credible researchers publish careful analysis, organizations should not base mitigations on forum theories, screenshots, or dramatic exploit names.
Microsoft’s Own AI Security Push Adds an Interesting Backdrop
The timing lands in a period when Microsoft has been publicly emphasizing AI-assisted vulnerability discovery and large-scale internal security work. That context does not prove anything about CVE-2026-45657’s discovery path, and the advisory credits Microsoft rather than an outside researcher. Still, it fits a broader trend: vendors are finding more deep bugs in their own code before adversaries publicly weaponize them.That is good news, but it comes with a paradox. Better internal discovery means more serious bugs may arrive as cleanly patched advisories rather than emergency zero-day fire drills. The danger is that defenders become numb because the absence of exploitation at publication makes every serious issue feel hypothetical.
CVE-2026-45657 should be treated as evidence that quiet disclosure can still carry major risk. The best version of the story is that Microsoft found or confirmed a dangerous kernel networking bug, shipped fixes before public exploitation, and gave administrators a chance to get ahead of attackers. That outcome only holds if administrators actually use the head start.
The industry often celebrates zero-day response because it is dramatic. The less glamorous work is patching the near-zero-day before it becomes one. That is where this vulnerability sits today.
The Patch Window Is the Real Security Boundary
The practical lessons from CVE-2026-45657 are not mysterious, but they are concrete enough to separate disciplined shops from hopeful ones. This is not a vulnerability that rewards theatrical mitigation plans. It rewards boring execution: update, reboot, verify, segment, monitor.- CVE-2026-45657 is a confirmed critical Windows Kernel remote code execution vulnerability disclosed on June 9, 2026, with a CVSS base score of 9.8.
- Microsoft says the vulnerability is not publicly disclosed and not known to be exploited at publication, but the attack vector is network-based and requires neither authentication nor user interaction.
- The affected platform list includes Windows 11 versions 23H2 through 26H1 and Windows Server 2022 and 2025, including Server Core installations.
- Administrators should verify fixed build numbers after reboot rather than relying only on update deployment status.
- Systems with broad network reachability, especially servers and management infrastructure, should move through patch rings faster than ordinary desktop endpoints.
- The advisory’s limited technical detail should not be mistaken for limited severity, because the available scoring already describes a high-consequence remote kernel attack path.
References
- Primary source: MSRC
Published: 2026-06-09T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
