CVE-2026-42987

What it actually does

CVE-2026-42987 is a network-accessible use-after-free vulnerability in Windows Deployment Services (WDS). An unauthenticated attacker can trigger unsafe memory reuse in the WDS service by sending specially crafted network traffic to a vulnerable server, potentially causing remote code execution in the context of the WDS service. Successful exploitation could allow the attacker to run arbitrary code, alter deployment content, access sensitive deployment data, or disrupt operating system deployment services. The CVSS score is 8.1 with high confidentiality, integrity, and availability impact, but attack complexity is rated high, indicating exploitation likely requires precise protocol behavior, timing, memory-state manipulation, or target-specific conditions.

Why it matters to the business

Organizations using Windows Deployment Services on affected Windows Server versions could face compromise of a trusted infrastructure service used to provision or reimage systems. If exploited, an attacker may be able to tamper with deployment workflows, interfere with workstation or server provisioning, steal deployment-related secrets or configuration data, or use the WDS server as a foothold for broader network compromise. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a low, stable EPSS score, so broad active exploitation is not indicated; however, the potential impact remains high because WDS often sits on sensitive internal infrastructure and may be reachable by unauthenticated hosts on deployment networks.

How an attack unfolds

An attacker first identifies a Windows Server host exposing Windows Deployment Services, typically through PXE or deployment-related network services. The attacker then sends crafted unauthenticated network requests that exercise the vulnerable WDS code path and cause the service to reference memory after it has been freed. By carefully shaping request content, timing, and heap layout, the attacker attempts to convert the memory corruption condition into controlled code execution rather than only a crash. If successful, attacker-controlled code runs on the WDS server with the privileges of the affected service, enabling follow-on actions such as modifying boot images, staging malicious deployment assets, collecting deployment credentials or configuration data, disabling provisioning operations, or moving laterally using access available from the compromised server. Because attack complexity is high and no public exploit maturity is reported, defenders should expect failed exploitation attempts may appear as WDS service instability, crashes, malformed PXE/TFTP traffic, or unusual bursts of deployment requests before any successful compromise.

How to fix it

Apply the Microsoft security update that addresses CVE-2026-42987 for all affected Windows Server versions, including Windows Server 2012, 2016, 2019, 2022, and 2025 where WDS is installed or enabled. No exact fixed build numbers were provided in the input, so administrators should use the relevant Microsoft Security Update Guide entry and the latest cumulative update for each supported server release. If WDS is not required, disable the Windows Deployment Services role and associated services. If WDS is required, restrict network access to deployment VLANs and known provisioning hosts, block unnecessary access to PXE/TFTP/WDS-related ports from general user networks, and ensure the WDS server is not exposed to the internet. Review and harden deployment shares, boot images, install images, prestaged device workflows, and service account permissions. Where immediate patching is not possible, reduce exposure through firewall rules, segmentation, service shutdown during non-provisioning windows, and monitoring for abnormal WDS service crashes or malformed deployment traffic.

How to confirm the fix worked

Confirm whether the Windows Deployment Services role is installed and enabled on each affected Windows Server. Verify that the applicable Microsoft security update or later cumulative update is installed for the operating system version. Validate that WDS services are either disabled where unnecessary or running only on intended deployment servers. Perform authenticated patch inventory checks, compare installed OS build and update levels against Microsoft’s fixed guidance, and verify that network controls prevent unauthorized systems from reaching WDS/PXE/TFTP services. From a network perspective, confirm that UDP 67/68, UDP 69, UDP 4011, and any WDS-related management exposure are limited to approved deployment segments. After patching or mitigation, review event logs for service stability and perform a controlled PXE/deployment test to ensure legitimate imaging workflows still function.

Typical attack path

1. Discover a Windows Server host running Windows Deployment Services or responding to PXE/TFTP/WDS-related network traffic.
2. Confirm unauthenticated reachability to WDS deployment services from the attack location.
3. Send crafted network messages designed to trigger the vulnerable use-after-free condition in WDS.
4. Manipulate protocol flow, timing, and memory layout to gain reliable control of execution instead of merely crashing the service.
5. Execute code in the context of the WDS service if exploitation succeeds.
6. Establish persistence, collect deployment-related secrets or configuration data, tamper with boot or install images, or use the server as a pivot point for lateral movement.
7. Cover tracks by removing staged files, reverting modified deployment assets, or blending activity into normal provisioning traffic.

How to detect it

To determine whether exploitation may have already occurred, review Windows System logs, Application logs, WDS operational and diagnostic logs, service-control events, crash dumps, and network telemetry for anomalous WDS behavior. Focus on unexplained crashes or restarts of the WDS service, repeated malformed or failed PXE/TFTP interactions, unexpected deployment requests from non-provisioning subnets, and changes to boot images, install images, deployment shares, scripts, or unattended installation files. Relevant log sources include Windows Event Log System channel, Application channel, Microsoft-Windows-Deployment-Services-Diagnostics/Admin, Microsoft-Windows-Deployment-Services-Server/Operational where enabled, Service Control Manager events, Windows Error Reporting events, EDR process telemetry, firewall logs, DHCP/PXE logs, and packet or flow data for UDP 67, UDP 68, UDP 69, and UDP 4011. Since there are no known public exploit indicators, no KEV listing, and no named threat actors reported in the provided intelligence, prioritize behavioral evidence: WDS crashes followed by suspicious child processes, unauthorized file writes under RemoteInstall paths, unexpected modifications to WIM/boot files, or outbound connections initiated by the WDS server after anomalous deployment traffic.

• WDSServer
• WDSServer service terminated unexpectedly
• Windows Deployment Services Server
• Microsoft-Windows-Deployment-Services-Diagnostics/Admin
• Microsoft-Windows-Deployment-Services-Server/Operational
• Event ID 7031
• Event ID 7034
• Event ID 1000
• Event ID 1001
• wdsserver.dll
• C:\RemoteInstall\
• C:\RemoteInstall\Boot\
• C:\RemoteInstall\Images\
• boot.wim
• install.wim
• wdsnbp.com
• wdsmgfw.efi
• UDP/69
• UDP/4011

What your security team should do

• Inventory all Windows Server 2012, 2016, 2019, 2022, and 2025 systems and identify where the Windows Deployment Services role is installed or enabled.
• Prioritize patching internet-exposed or broadly reachable WDS servers first, followed by WDS servers reachable from user, guest, lab, or unmanaged device networks.
• Apply the relevant Microsoft cumulative security update for each affected Windows Server version as soon as operationally feasible.
• Disable WDS on servers that do not require deployment services.
• Restrict WDS/PXE/TFTP access to approved provisioning networks and prevent access from general-purpose client networks.
• Review deployment shares, boot images, install images, task sequences, scripts, and unattend files for unauthorized changes or embedded secrets.
• Monitor for WDS service crashes, unexpected restarts, malformed PXE/TFTP traffic, and unusual deployment requests from non-provisioning hosts.
• Because EPSS is currently low and stable, balance urgency against operational testing requirements, but do not defer remediation indefinitely due to the high impact of successful remote code execution.
• Create SIEM detections for WDS instability and anomalous access to UDP 69 and UDP 4011 from unexpected sources.
• If suspicious WDS activity is observed, preserve event logs, WDS logs, memory where possible, and copies of deployment images before reimaging or rebuilding the server.