june 2026 patch tuesday: a patch-diff campaign
on this page
june 2026 was the largest microsoft patch tuesday on record: roughly 200 windows cves (over 500 counting chromium and third-party), 38 rated critical, three publicly-known zero-days, and one bug under active exploitation. this page is a working write-up of a patch-diff pass over the highest-value network-facing and kernel binaries in that release. all bug details below concern microsoft’s own already-published june 9 cves; nothing here is an undisclosed vulnerability.
method
the goal of a patch-diff is not to race the n-day. by the afternoon of patch tuesday, every researcher and exploit shop is already reversing the headline bugs, so re-deriving a now-public cve is not, by itself, a useful result. the value is twofold:
- localization — precisely root-causing the fixed bug (the changed function, the added bound, the cwe), which is the cheap part and a good calibration check.
- the unpatched-sibling / incomplete-patch hunt — once the bug class and its location are known, scanning the patched binary for a structurally identical sibling that the patch did not touch. a fix that closes one site but leaves a twin open is the classic incomplete-patch zero-day.
binary pairs were taken across the 26100.8521 (may) -> 26100.8655 (june, kb5094126) windows 11 24h2 boundary. each fixed function was localized at capstone ground truth (the disassembler is the oracle; decompiler output is only a reading aid), and the patched binary was then scanned for siblings of the fixed pattern.
the targets
| binary | headline cve(s) | class | localized fix |
|---|---|---|---|
tcpip.sys | cve-2026-45657 (9.8, “wormable”), cve-2026-42904 (eop) | oob write in a kernel wsk message transport; forwarding-path validation | an upper-bound length cap; a forwarding-entry state bit |
http.sys | cve-2026-47291 (9.8 rce), cve-2026-49160 (http/2 dos) | a request-buffer capacity counter that wrapped a 16-bit field, undersizing a pool allocation; an uncapped http/2 resource counter | a 16-bit overflow check; a new configurable header-count cap |
dhcpcore.dll | cve-2026-44815 (9.8 rce, “every os”) | a dhcp option value copied into a fixed-size buffer using the attacker-supplied option length | an exact-length check before the copy |
afd.sys | seven elevation-of-privilege cves | socket/endpoint lifecycle: a listen-irp drain, an unbind race, and related families | per-family guards under new feature gates |
dwmcore.dll | eight elevation-of-privilege cves | a desktop-composition object double-added to a ready list, leaving a stale pointer (use-after-free) | a duplicate-registration guard, with the add path centralized |
each of those localizations matched the published advisory. the sibling hunt, however, came back clean on every one of the five binaries — the june fixes are well-scoped. that is a real (if negative) result: this batch did not leave an obvious incomplete-patch twin in the binaries examined. the more interesting outcomes were two systemic observations that cut across the whole release.
observation 1: the fixes are velocity-flag-gated, but enabled by default
four of the five binaries (everything except dhcpcore.dll) do not apply their security fix unconditionally. instead, each fix is wrapped in a windows “velocity” / wil feature gate — a runtime Feature_<id>__private_IsEnabled... check — and the legacy, vulnerable code path is still compiled into the shipped binary and runs whenever the flag is off. one of the afd binaries even carries the literal string Feature_TCPIP_2025_Wave4_AfdTransmit_MSRC, making the provenance explicit.
this is the staged-rollout machinery microsoft uses to ship features gradually, now applied to security fixes. it raises an obvious question for defenders: if the fix is behind a flag, is a “fully patched” host actually protected, or could the flag ship disabled?
reading the resolved feature state directly out of kernel memory on a fully-updated host (the wil IsEnabled decode is a two-bit check: one bit for “state recorded”, one for “enabled”) answered it: on a current windows 11 25h2 build, all of the relevant fix flags read enabled by default, with no feature-management override forcing them off. the crown-jewel flag gating the wormable tcpip.sys rce fix is enabled, and the bounded code path is the one taken.
so in this case the gating is benign — staged-rollout plumbing and defense-in-depth, not a disabled-by-default fix. but it is worth knowing that the question is now a real one: a security fix being present in the binary no longer strictly implies it is active, and the honest way to confirm is to read the feature state on the patched host rather than assume.
observation 2: the “wormable” tcp/ip rce is far narrower than 9.8 implies
cve-2026-45657 was the headline: a cvss 9.8, remote, unauthenticated, “wormable” kernel remote-code-execution in tcp/ip. that framing drove a lot of urgency. the reachability tells a more specific story.
the vulnerable code is not in the classic tcp/ip receive or ip-fragment-reassembly path. it lives in a comparatively obscure kernel transport — the “port-tracker” subsystem, a winsock-kernel (wsk) message protocol whose listener is not initialized at all by default. whether it comes up is gated by a single registry value, HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PortTrackerEnabledMode, which is absent by default on both windows 11 client and windows server 2025.
that value is the wsl2 mirrored-networking feature. the port-tracker transport carries port-reservation/reflection messages between the windows host kernel and the wsl2 utility vm; the peer is the co-resident wsl2 guest on the host’s mirrored virtual network, not an arbitrary internet host. mirrored networking is opt-in (it requires wsl2 installed and networkingMode=mirrored in .wslconfig).
so the practical exposure of cve-2026-45657 is: hosts where a user has explicitly enabled wsl2 mirrored networking, attacked from the co-resident wsl2 guest or the mirrored vnet. that is a real and interesting surface — a wsl2-guest-to-windows-host-kernel boundary, relevant to developer machines — but it is a long way from “any unpatched windows box on the internet is wormable.” the 9.8 should be read as the worst case for the opted-in population, not the default fleet. (this does not change the urgency of patching; it changes who is actually exposed.)
takeaways
- n-day patch-diffing reliably yields localization and the occasional sibling; this june batch was sibling-clean across five binaries, which is itself a useful calibration data point (microsoft’s fixes here are tight).
- the real signal was structural: security fixes shipped behind velocity feature flags (enabled-by-default this month, but no longer a safe assumption), and a headline “wormable” cvss that, on inspection, is gated behind an opt-in developer feature.
- the higher-yield path for novel bugs is generally not more n-day diffing but forward-hunting fresh, less-fuzzed surfaces; a patch-diff is most useful for the targeting intelligence it provides about where a vendor is currently finding bugs.
method note: binary pairs resolved via winbindex; diffs computed from pdb-named functions and basic-block extents (the vendor function-similarity tooling under-reports in path-mode); ground truth throughout was capstone disassembly of the real shipped bytes, with feature-state reads via local kernel debugging on a patched host.