Windows - Security - Mitigate CVE-2023-38149

What the CVE-2023-38149 mitigation Worklet does

This Automox Worklet™ protects Windows endpoints from CVE-2023-38149, a denial of service vulnerability in the Windows TCP/IP stack disclosed by Microsoft in the September 2023 cumulative update (KB5030214). The Worklet implements Microsoft's documented workaround by disabling router discovery on every IPv6 interface on the endpoint.

Router discovery is the mechanism IPv6 interfaces use to learn about routers on the local link from Router Advertisement messages. The CVE-2023-38149 vulnerability sits inside the code path that parses those advertisements, so disabling router discovery removes the attacker's surface entirely. The Worklet does this through Set-NetIPInterface against every entry returned by Get-NetIPInterface -AddressFamily IPv6, so it covers physical adapters, virtual adapters, VPN tunnels, and Hyper-V vSwitches in the same pass.

The Worklet ships with a Revert parameter so the same policy can roll the mitigation back after KB5030214 (or a later cumulative update that supersedes it) is installed. The evaluation script is idempotent, which lets you schedule the policy on a recurring cadence to hold the mitigation in place even after an admin runs netsh winsock reset, a driver reinstall flips the interface, or a build pipeline rolls a new image.

Why mitigate CVE-2023-38149 before patching

CVE-2023-38149 is a remote, unauthenticated denial of service against any Windows endpoint with IPv6 enabled and configured to accept Router Advertisements, which is the default for supported Windows client and server SKUs. An attacker on the same broadcast domain can send a malformed RA packet and crash or hang the TCP/IP stack. The patch in KB5030214 fixes the parser, but until the cumulative update is staged, tested, and rolled out across the fleet, every unpatched endpoint that touches an untrusted network segment remains exposed.

Patch rollouts usually leave a long tail of laptops, kiosks, and lab machines that miss the first wave. Disabling router discovery removes the vulnerable code path with no reboot and no payload to deploy, which is why Microsoft documents it as the recommended workaround. This Worklet applies the workaround consistently across every endpoint in scope until KB5030214 is verified installed.

How the IPv6 router discovery mitigation works

1. Evaluation phase: The Worklet calls Get-NetIPInterface -AddressFamily IPv6 and walks the RouterDiscovery property on every returned interface. If any interface still has RouterDiscovery set to Enabled, the endpoint is flagged non-compliant and remediation is scheduled. When the Revert parameter is true, the logic inverts: any interface still Disabled triggers remediation to restore Enabled, so the same policy handles rollback after KB5030214 lands.

2. Remediation phase: The Worklet iterates the IPv6 interface list and calls Set-NetIPInterface -InterfaceIndex <idx> -RouterDiscovery Disabled (or Enabled if reverting) against each one. Every change is written to stdout with the interface alias and ifIndex so the Automox activity log captures a per-adapter audit trail. The change is live immediately and survives reboot because Set-NetIPInterface persists to the Tcpip6 configuration store, with no Restart-Service required.

CVE-2023-38149 mitigation requirements

• Windows 10, Windows 11, or Windows Server (2016 through 2022) with IPv6 bound on at least one interface

• PowerShell 5.1 or later (the NetTCPIP module ships in-box on all supported Windows versions)

• Administrative privileges on the endpoint to modify network interface configuration (the Automox agent's default context already meets this)

• No restart required after applying changes; Set-NetIPInterface persists to the IPv6 configuration store immediately

• Policy parameter: Revert (true / false). Default false applies the mitigation; set to true after KB5030214 (or a superseding cumulative update) is installed to restore router discovery

• Test on a pilot ring first. Environments that rely on Router Advertisements for SLAAC address assignment will lose IPv6 connectivity on managed adapters until the mitigation is reverted; static or DHCPv6 configurations are unaffected

Expected IPv6 router discovery state after remediation

After a successful remediation run, every IPv6 interface on the endpoint reports RouterDiscovery as Disabled. Verify from an elevated PowerShell session with Get-NetIPInterface -AddressFamily IPv6 | Format-Table InterfaceAlias, InterfaceIndex, RouterDiscovery and confirm the RouterDiscovery column shows Disabled across the board. The next evaluation pass returns compliant without firing remediation again because the state already matches policy.

After KB5030214, or any later cumulative update that supersedes it, is installed and validated, re-run the policy with Revert set to true. RouterDiscovery returns to Enabled and SLAAC-driven IPv6 connectivity resumes. Watch endpoints with manually configured IPv6 default gateways during the mitigation window. They continue working normally, but any endpoint that depended on RA-supplied DNS server hints loses that signal until rollback.

For audit evidence, capture the Get-NetIPInterface output before and after the Worklet runs and store both alongside the Automox policy run identifier. The pre / post diff is the artifact a change advisory board or auditor will ask for, and it pairs cleanly with the cumulative update install record from Windows Update history once patching catches up.