Disable Windows packet queuing to mitigate CVE-2023-36603, the IPv6 fragmentation TCP/IP denial-of-service vulnerability
This Automox Worklet™ mitigates CVE-2023-36603, the Windows TCP/IP denial-of-service vulnerability disclosed in September 2023 and patched by Microsoft in KB5030214. The Worklet writes the EnablePacketQueue registry value (DWORD, set to 0) into the Windows Firewall policy, which disables the packet queuing path the vulnerability targets.
CVE-2023-36603 is exploited through crafted IPv6 fragments. An unauthenticated remote attacker sends a malicious fragmented IPv6 packet, and a vulnerable Windows endpoint with packet queuing enabled crashes its TCP/IP stack. The CVSS 7.5 score reflects the remote, network-adjacent, no-privileges-required attack profile. Disabling EnablePacketQueue closes the code path until the September 2023 cumulative update lands.
The Worklet writes the value into two registry locations. The first is the standard FirewallPolicy key at HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy. The second is the Mdm policy key at HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Mdm, which MDM-managed endpoints (Intune, Configuration Manager co-managed devices) consult when the device policy channel is authoritative. Writing both paths keeps the mitigation in effect regardless of which side wins the policy merge.
CVE-2023-36603 lets an unauthenticated attacker disable Windows networking with a single crafted IPv6 fragment. Microsoft shipped the fix in the September 2023 Patch Tuesday cumulative update (KB5030214 on Windows 11 22H2, with parallel KBs for Windows 10 and Windows Server). Endpoints that miss that patch cycle remain exposed, and many fleets carry a long tail of laggards: kiosks, locked-down lab machines, air-gapped servers, and roaming laptops that go weeks between check-ins. This Worklet applies Microsoft's documented pre-patch mitigation so those endpoints are protected the moment Automox evaluates them, not the day they finally take a cumulative update.
The EnablePacketQueue mitigation is durable: it persists across reboots and survives most image refreshes because the values live in the SharedAccess FirewallPolicy registry hive. What it does not survive is a baseline reset, an Intune policy reflow, or a feature update that touches the FirewallPolicy Mdm key. A recurring Automox policy keeps both registry paths pinned to 0, so a Windows 10 or Windows 11 endpoint that drifts after a CSP push is detected on its next evaluation and re-hardened before an attacker can probe the IPv6 fragment path. The same policy run covers internet-facing IIS hosts, Hyper-V hosts, and roaming laptops that miss Microsoft Update windows.
Evaluation phase: The Worklet queries HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy and the matching ...\FirewallPolicy\Mdm subkey for EnablePacketQueue. If the value is missing in either location, is not a DWORD, or is set to anything other than 0, the endpoint is flagged non-compliant and remediation is scheduled. The evaluation script also writes a verbose summary to the Automox activity log so you can see which path failed without RDP’ing into the endpoint.
Remediation phase: The Worklet opens the LocalMachine hive through [Microsoft.Win32.RegistryKey]::OpenBaseKey, calls CreateSubKey to materialize the FirewallPolicy and FirewallPolicy\Mdm paths if they do not exist, and writes EnablePacketQueue as a DWord with value 0 in both locations. The script exits 0 on success and exits 2 if the registry write fails. The change takes effect for new connections immediately; a reboot drains any in-flight queued packets and is recommended for endpoints under active load.
Windows 10, Windows 11, or Windows Server (2012 R2, 2016, 2019, and 2022 are all covered by Microsoft's CVE-2023-36603 advisory)
Administrator or local SYSTEM context for registry writes under HKLM\SYSTEM (the default Automox agent context already meets this)
PowerShell 5.1 or later available on the endpoint (default on every supported Windows build)
Endpoint reboot recommended after remediation to drain any queued packets, though not strictly required for the mitigation to take effect
If you plan to layer this on top of the September 2023 cumulative update (KB5030214 and siblings), leave the registry value in place – it is safe to keep set on patched endpoints
After the Worklet completes, EnablePacketQueue is set to 0 (DWORD) in both HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy and the Mdm child key. The IPv6 fragmentation code path that CVE-2023-36603 abuses is no longer reachable, and the endpoint is protected even before its next cumulative update window. Subsequent Worklet runs report the endpoint as compliant without re-running remediation, because the evaluation phase confirms the registry state on each policy run.
Validate the mitigation directly from PowerShell: Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy' -Name EnablePacketQueue should return 0, and the same query against the ...\FirewallPolicy\Mdm subkey should return 0 as well. For audit evidence, capture both values alongside the Automox policy run identifier and the endpoint hostname. The mitigation persists across reboots and across Windows feature updates; it is only undone if an administrator deletes the registry value or restores from a pre-mitigation backup, at which point the next evaluation flags the endpoint and the Worklet rewrites the keys. After Microsoft's permanent fix lands via the September 2023 cumulative update (KB5030214 on Windows 11 22H2 and the matching KBs on Windows 10 and Windows Server), the registry mitigation is redundant but harmless. Many security teams leave the value set so that endpoints rolled back to a pre-September 2023 image (recovery partitions, golden VHDs, system restore points) are still protected on first boot. Use Automox patch management policies to confirm KB5030214 or its successor is installed on the same fleet, and treat this Worklet as the compensating control that closes the window between disclosure and patch deployment.


Loading...
Consider Worklets your easy button
A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy
By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in