Windows TCP/IP IPv6 Remote Code Execution (CVE-2024-38063)

What to do

1. Confirm every Windows host has an August 2024 or later cumulative update, and September 2024 or later for Windows 10 1809, Server 2019, Server 2022 and Windows 11 21H2
2. Prioritize hosts reachable over IPv6 from the internet or untrusted segments
3. Filter inbound IPv6 at the perimeter if you do not use it externally
4. Do not disable IPv6 fleet-wide as a substitute for patching; Microsoft does not recommend it
5. Use the DisabledComponents registry value only as a temporary, tested exception for hosts that truly cannot be patched

How to check if you are affected or compromised

• Check OS build with winver or (Get-ComputerInfo).OsBuildNumber and compare to the patched builds in the Microsoft advisory
• Correlate unexpected bugchecks (BSODs) in tcpip.sys on unpatched machines with inbound IPv6 traffic
• Look for bursts of malformed IPv6 packets with destination options and fragmentation headers in network telemetry

What happened#

On Patch Tuesday, August 13, 2024, Microsoft fixed CVE-2024-38063, a remote code execution flaw in the Windows TCP/IP stack (tcpip.sys). The Microsoft advisory rates it Critical with CVSS 3.1 9.8, classifies it as an integer underflow (CWE-191), and marks it "Exploitation More Likely". Microsoft's FAQ says an unauthenticated attacker "could repeatedly send IPv6 packets, that include specially crafted packets", to achieve code execution. No user interaction or authentication is needed, which is why the Zero Day Initiative called it wormable.

On September 10, 2024, Microsoft revised the advisory: "to comprehensively address" the bug, it shipped further updates for Windows 10 1809, Server 2019, Server 2022 and Windows 11 21H2.

Who is affected#

Essentially every supported Windows client and server version at the time, from Server 2008 SP2 through Windows 11 24H2, before the August 2024 updates, per the advisory and the NVD record. Microsoft's only mitigating factor: "Systems are not affected if IPv6 is disabled on the target machine." IPv6 is on by default. IPv4-only traffic does not reach the bug.

Do you really need to act?#

Patch, yes; panic, no. Here is the exploitation reality as of October 21, 2026:

• Microsoft listed it as not publicly disclosed and not exploited at release. It is not in the CISA KEV catalog, and we found no credible report of in-the-wild exploitation.
• Public code exists. A proof of concept by ynwarcs (who credits the discovery to researcher Wei) describes the root cause: Windows coalesces IPv6 packets, an error in destination options parsing resets packet state while processing continues, and this leads to integer underflow and overflow in fragment reassembly. The author calls it "rather flaky": it depends on the network adapter and driver coalescing packets, often needs a reassembly timeout of about a minute, and is written to raise the chance of a crash, not deliver a shell.
• The attacker must deliver IPv6 packets to the host. On the internet that means a host with a routable IPv6 address and no upstream filtering; on a LAN, IPv6 link-local addressing makes adjacent attackers the more realistic threat. The PoC notes packets must reach the stack before the host firewall, so Windows Firewall rules do not save you.

Net: reliable remote code execution against a kernel network stack is hard, and two years on nobody has publicly shown it. A crash (denial of service) is the more plausible abuse. Machines on routine monthly updates have been protected since August or September 2024.

What to do now#

1. Verify patch levels. Run winver or PowerShell (Get-ComputerInfo).OsBuildNumber and compare with the advisory's fixed builds; any cumulative update from September 2024 onward covers all versions.
2. Prioritize servers with public IPv6 addresses and machines on untrusted networks.
3. Filter inbound IPv6 at the perimeter if you do not use it externally.
4. Do not disable IPv6 fleet-wide as a shortcut. Microsoft's guidance says it does not recommend disabling IPv6 because some Windows components might not function. For a host that truly cannot be patched, setting DisabledComponents to 0xFF under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters and rebooting is a temporary, tested exception, not a plan.

How to tell if you were hit#

The likely symptom on an unpatched host is an unexpected bugcheck referencing tcpip.sys. Correlate crash dumps with network telemetry showing bursts of malformed IPv6 packets carrying destination options and fragment headers. Signs of actual code execution would look like any kernel compromise; given the absence of known exploitation, focus effort on confirming patch coverage.

Timeline#

• Aug 13, 2024 — Microsoft releases fixes and the advisory.
• Aug 24, 2024 — Public proof-of-concept code appears on GitHub (repository created that day).
• Sep 10, 2024 — Microsoft revises the advisory with additional updates for four Windows versions.
• Oct 21, 2026 — Not in CISA KEV; no known in-the-wild exploitation.

Vulnerability records

• CVE-2024-38063 · Windows TCP/IP Remote Code Execution Vulnerability

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Microsoft MSRC — CVE-2024-38063 Windows TCP/IP Remote Code Execution Vulnerability msrc.microsoft.com
2. NVD — CVE-2024-38063 nvd.nist.gov
3. Zero Day Initiative — The August 2024 Security Update Review zerodayinitiative.com
4. ynwarcs — CVE-2024-38063 proof of concept (GitHub) github.com
5. Microsoft Learn — Configure IPv6 for advanced users learn.microsoft.com
6. CISA — Known Exploited Vulnerabilities Catalog cisa.gov