CVE-2021-24086

What it actually does

CVE-2021-24086 is a remotely reachable denial-of-service vulnerability in the Windows TCP/IP stack. An unauthenticated attacker on a network path that can send crafted traffic to an affected Windows host can trigger a failure in TCP/IP processing, causing a system crash or loss of availability. The vulnerability does not provide code execution, privilege escalation, or data access by itself, but it can forcibly interrupt affected workstations and servers.

Why it matters to the business

Successful exploitation can take Windows endpoints or servers offline without credentials or user interaction. For business-critical systems, this can cause application outages, interrupted user sessions, failed transactions, service desk volume, and potential failover or recovery events. Although it is not listed in CISA KEV and no mature public exploit is noted in the supplied data, the EPSS score is relatively elevated, so internet-exposed or untrusted-network-facing Windows systems should be treated as meaningful availability risk.

How an attack unfolds

An attacker identifies an affected Windows system that accepts network traffic over IPv6/TCP/IP. The attacker sends specially crafted packets designed to exercise the vulnerable code path in the Windows TCP/IP stack. Because the flaw is reachable without authentication and requires no user interaction, exploitation can be attempted directly over the network. If the crafted traffic is processed by an unpatched vulnerable system, the operating system may crash or become unavailable, resulting in denial of service. The attacker’s objective is disruption rather than persistence or data theft, and exploitation artifacts are likely to appear as network anomalies followed by unexpected Windows bugcheck, reboot, or service interruption events.

How to fix it

Apply the Microsoft security updates that address CVE-2021-24086 for all affected Windows versions, including Windows 10, Windows 7 where supported through extended servicing, Windows 8.1, Windows RT 8.1, Windows Server 2008, Windows Server 2012, Windows Server 2016, and Windows Server 2019. If immediate patching is not possible, reduce exposure by filtering untrusted IPv6 traffic at network boundaries, limiting access to Windows hosts from untrusted networks, and applying Microsoft-recommended TCP/IP mitigations where operationally safe. For environments that do not require IPv6 fragment reassembly, Microsoft’s documented mitigation for related February 2021 Windows TCP/IP issues was to disable IPv6 packet reassembly using `netsh int ipv6 set global reassemblylimit=0`; validate carefully before use because this can disrupt legitimate IPv6 fragmented traffic. Prefer patching over long-term workarounds.

How to confirm the fix worked

Confirm that the relevant Microsoft security update from February 2021 or later is installed on each affected Windows system. Validate through centralized patch management, Windows Update history, WSUS/SCCM/Intune compliance reporting, or by checking installed cumulative update levels against Microsoft’s security update guidance for the operating system build. Where mitigations are used, confirm the IPv6 reassembly configuration with `netsh int ipv6 show global` and verify that exposure from untrusted networks is blocked by firewall or network controls. If possible, perform non-destructive vulnerability scanning with authenticated checks rather than live exploit testing, because exploitation may crash the target.

Typical attack path

1. Scan or otherwise identify Windows hosts reachable over the network, especially systems accepting IPv6 traffic from untrusted networks.
2. Send crafted TCP/IP or IPv6-related packets to the target host to trigger the vulnerable Windows TCP/IP parsing or processing path.
3. Cause the target system to crash, reboot, or become unavailable.
4. Repeat the traffic against the same or multiple hosts to sustain disruption or create cascading operational impact.

How to detect it

To determine whether this was already exploited, correlate Windows crash and reboot telemetry with inbound network activity. Review Windows System logs for bugcheck and unexpected reboot events, including Microsoft-Windows-WER-SystemErrorReporting, BugCheck, Kernel-Power, and EventLog entries. Look for repeated crashes across multiple Windows hosts within a short time window, especially when preceded by unusual IPv6 traffic, fragmented packets, malformed packets, or traffic from the same external source. Network telemetry sources should include firewall logs, NetFlow/IPFIX, packet captures, IDS/IPS alerts, endpoint firewall logs, and load balancer logs where applicable. Because this is a denial-of-service issue rather than a post-exploitation vulnerability, host indicators are usually limited to crash dumps, event logs, and network traces rather than files, registry keys, or malware processes. Preserve memory dumps from `C:\Windows\MEMORY.DMP` or minidumps under `C:\Windows\Minidump\` for forensic review if crashes are suspected to be related.

• The computer has rebooted from a bugcheck
• Event ID 1001
• Event ID 41
• Microsoft-Windows-WER-SystemErrorReporting
• BugCheck
• Kernel-Power
• C:\Windows\MEMORY.DMP
• C:\Windows\Minidump\
• IPv6 Fragment Header
• Next Header: 44
• netsh int ipv6 set global reassemblylimit=0

What your security team should do

• Prioritize patching internet-facing, DMZ, VPN-adjacent, and untrusted-network-accessible Windows servers and endpoints.
• Use authenticated vulnerability scanning or patch compliance tooling to identify Windows systems missing the February 2021 or later security updates for this issue.
• Restrict unsolicited IPv6 traffic from untrusted networks to Windows systems that do not require it.
• Review firewall, IDS/IPS, and router controls for abnormal or malformed IPv6 fragmented traffic targeting Windows assets.
• Monitor for unexplained Windows bugchecks, sudden reboots, and clustered availability incidents that coincide with suspicious inbound network traffic.
• If patching must be delayed, evaluate Microsoft-documented mitigations such as disabling IPv6 packet reassembly only after application compatibility testing.
• Treat repeated crashes following similar network traffic patterns as potential attempted exploitation and preserve packet captures, Windows event logs, and memory dump artifacts where available.