Windows - Security - Mitigate TCP/IP Denial of Service Vulnerability ( CVE-2023-36603 )

What the TCP/IP DoS mitigation Worklet does

This Automox Worklet™ mitigates CVE-2023-36603, a critical vulnerability in Windows that allows attackers to disable the network stack through denial-of-service attacks. The Worklet disables packet queuing by setting the EnablePacketQueue registry value to 0 in the Windows Firewall policy.

Packet queuing allows the Windows network stack to scale receive-side processing for both encrypted (inbound) and decrypted (outbound) traffic in IPsec tunnel scenarios. Disabling this feature removes the attack surface that attackers exploit to crash the network stack.

The Worklet modifies two registry locations: the standard FirewallPolicy path and the Mobile endpoint Management (Mdm) path, verifying comprehensive coverage across all endpoint configurations.

Why disable packet queuing to prevent DoS attacks

Unpatched Windows endpoints remain vulnerable to network-based attacks that crash the TCP/IP stack. CVE-2023-36603 allows remote attackers to craft malicious network packets that disable endpoint networking when packet queuing is enabled. This vulnerability requires no authentication, meaning any network-connected system can exploit it to disrupt your operations.

Disabling packet queuing immediately closes this attack vector while you wait for permanent updates from Microsoft. This mitigation is recommended for all Windows workstations and servers in environments where network security is a priority.

The performance impact of disabling packet queuing is minimal for most organizations. Only highly specialized IPsec tunnel gateway deployments that rely on receive-side scaling might see reduced throughput, but the security benefit outweighs this concern.

How the CVE-2023-36603 mitigation works

1. Evaluation phase: The Worklet queries the Windows registry at SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\ and SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Mdm\ to check if EnablePacketQueue is set to 0 with the DWORD value type. If either location is missing this configuration, the endpoint is flagged as non-compliant.

2. Remediation phase: The Worklet creates or updates the EnablePacketQueue registry value in both locations, setting it to 0 (DWORD). This disables all packet queuing functionality across all receive-side scaling scenarios.

CVE-2023-36603 mitigation requirements

• Windows 10, Windows 11, or Windows Server 2016 and later

• Administrator or local system privileges required for registry modification

• Endpoint restart required to fully apply the mitigation

• No additional software dependencies or prerequisites

Expected state after DoS mitigation

After the Worklet completes successfully, the EnablePacketQueue registry value will be set to 0 in both the standard FirewallPolicy and Mdm FirewallPolicy locations. The endpoint becomes immune to CVE-2023-36603 exploitation because the packet queuing mechanism that the vulnerability targets is now disabled. You can verify compliance by inspecting the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\EnablePacketQueue to confirm the value is 0. An endpoint restart is recommended to fully apply the mitigation, though the registry change takes effect immediately for new network connections.

To verify compliance, you can inspect the registry using regedit or PowerShell and confirm that HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\EnablePacketQueue is set to 0. Subsequent Worklet runs will confirm the endpoint remains compliant, and subsequent Windows updates from Microsoft will provide permanent fixes to this vulnerability.

How to validate mitigate tcp/ip denial of service vulnerability ( cve-2023-36603 ) changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for mitigate tcp/ip denial of service vulnerability ( cve-2023-36603 ).

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Test-Registry, Write-Verbose, Write-Error.

4. Validate remediation effects from script operations such as Test-Registry, Write-Verbose, Write-Error, then rerun evaluation for compliance.