Heap-based buffer overflow in Windows Deployment Services

CVE-2026-72957 is a heap-based buffer overflow (CWE-122) in the Windows Deployment Services (WDS) server role, disclosed on 2026-09-08 as part of Microsoft's September Patch Tuesday. Despite Microsoft labeling it *Remote Code Execution*, the CVSS vector is AV:L — the attacker must already have local, authenticated access to the WDS server. With PR:L and AC:L, a low-privileged local user can trigger the overflow and escalate to SYSTEM on the WDS host. Affected versions span Windows Server 2016 through Server 2025 wherever the WDS role is installed.

Microsoft rates this HIGH at 7.8 with *exploitation more likely*, but that overstates the practical risk for most enterprises. WDS is partially deprecated — Microsoft blocked end-to-end WDS deployment for Windows 11 and Server 2025 boot media, and has been actively pushing organizations toward Intune/Autopilot. Sumble data shows roughly 11,400 organizations still running the role, a small and shrinking fraction of Windows Server deployments. The AV:L vector means an attacker has to already be sitting on the WDS box with valid credentials before the overflow is even reachable — that's a post-compromise escalation, not an initial-access vector. The vendor severity assumes the worst case in isolation; reality says this is a privilege-escalation step deep inside a kill chain that most environments will never encounter.

Why this verdict

• Local vector eliminates remote attack surface. AV:L means this cannot be triggered over the network. The attacker needs an existing foothold on the WDS server — a significant prerequisite that the vendor's 7.8 score doesn't adequately penalize in real-world terms.
• Shrinking, niche install base. WDS is partially deprecated; Microsoft blocked WDS for Windows 11/Server 2025 media and is pushing Intune/Autopilot. Roughly 11.4k organizations still run it — a small fraction of the Windows Server population. Most enterprises have migrated or are migrating away.
• No exploitation evidence or public PoC. Disclosed <48 hours ago with no known weaponization, no KEV listing, and no researcher write-ups. Heap overflows on modern Windows Server require bypassing CFG, ASLR, and heap integrity — not trivial even with AC:L.
• Role multiplier: WDS as deployment infrastructure. WDS servers *can* hold domain-join credentials in unattend.xml and serve OS images — a potential supply-chain pivot if SYSTEM is achieved. This is the strongest argument against a LOW rating. However, the chain requires local access first (AV:L), and modern hardening guidance (CVE-2026-0386) has already addressed credential exposure in the deployment pipeline. The blast radius is host-level (S:U), not domain-level, unless credentials are present AND unprotected — a conditional that weakens the multiplier. WDS is NOT a canonical high-value role like a domain controller or hypervisor; it is deployment tooling that ~0.5% of Windows Server instances run. The floor does not reach HIGH.

Why not higher?

To reach HIGH, the vulnerability would need either a network-reachable attack vector, active exploitation, or a canonical high-value role where ≥10% of installs occupy that role by definition. WDS fails all three: AV:L eliminates remote access, no exploitation is observed, and WDS is a niche, deprecated role present in a small fraction of server deployments. The supply-chain angle is theoretical and conditional on unattend.xml misconfigurations that Microsoft has already published hardening guidance against.

Why not lower?

Microsoft's own *Exploitation More Likely* assessment and the trivial exploitation complexity (AC:L/PR:L) mean a motivated attacker with local access could reliably escalate to SYSTEM. The potential for credential extraction from deployment shares and image poisoning — even if conditional — provides meaningful post-exploitation value that distinguishes this from a pure DoS or information-disclosure flaw. LOW would understate the impact for the ~11.4k orgs still running WDS.

1. Disable or remove the WDS role on servers where it is no longer actively used — Many orgs have WDS installed as a legacy artifact from migration-era deployments. Removing the role entirely eliminates the attack surface with zero functional impact. Audit your fleet and decommission within the 365-day noisgate remediation window.
2. Restrict local logon rights on WDS servers — Since the vulnerability requires AV:L, limit interactive and RDP logon to the WDS server to a named list of deployment administrators via Group Policy (Allow log on locally, Allow log on through Remote Desktop Services). This directly blocks the initial access step.
3. Network-isolate WDS to a dedicated PXE/deployment VLAN — WDS should only be reachable from PXE boot segments. Place it on a dedicated VLAN with firewall rules restricting inbound access to UDP 67-69 and 4011 from trusted subnets only. This limits lateral movement to/from the WDS server.
4. Audit and remove credentials from unattend.xml files — Follow Microsoft's CVE-2026-0386 hardening guidance to eliminate plaintext or reversibly encrypted credentials from deployment answer files. This neutralizes the highest-value post-exploitation target on the WDS server.
5. Deploy Snort/Suricata rules for WDS anomalies — Cisco Talos released Snort 2 SIDs 67036-67084 and Snort 3 SIDs 301632-301655 covering this CVE family. Deploy these on network sensors monitoring the WDS VLAN for defense-in-depth.

Run this on each Windows Server where WDS may be installed. Execute as a local administrator in an elevated PowerShell session. Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-72957.ps1

#Requires -RunAsAdministrator
<#
  Check-CVE-2026-72957.ps1
  Checks whether the Windows Deployment Services role is installed
  and whether the September 2026 cumulative update is applied.
  Output: VULNERABLE / PATCHED / UNKNOWN
#>

$ErrorActionPreference = 'Stop'

# Step 1: Check if WDS role is installed
try {
    $wdsFeature = Get-WindowsFeature -Name WDS -ErrorAction Stop
} catch {
    Write-Host "UNKNOWN - Unable to query Windows features. Is this a Server OS?"
    exit 2
}

if ($wdsFeature.InstallState -ne 'Installed') {
    Write-Host "PATCHED - WDS role is not installed. CVE-2026-72957 does not apply."
    exit 0
}

Write-Host "[*] WDS role is installed. Checking patch level..."

# Step 2: Check for September 2026 cumulative update
# Microsoft September 2026 Patch Tuesday: 2026-09-08
$patchDate = [datetime]'2026-09-08'
$hotfixes = Get-HotFix | Where-Object { $_.InstalledOn -ge $patchDate } | Sort-Object InstalledOn -Descending

if ($hotfixes.Count -gt 0) {
    $latest = $hotfixes[0]
    Write-Host "PATCHED - Found update $($latest.HotFixID) installed on $($latest.InstalledOn.ToString('yyyy-MM-dd')). CVE-2026-72957 is remediated."
    exit 0
} else {
    # Also check via Windows Update session history
    $session = New-Object -ComObject Microsoft.Update.Session
    $searcher = $session.CreateUpdateSearcher()
    $count = $searcher.GetTotalHistoryCount()
    $history = $searcher.QueryHistory(0, [Math]::Min($count, 50))
    $septUpdates = $history | Where-Object { $_.Date -ge $patchDate -and $_.Title -match '2026-09' }
    if ($septUpdates.Count -gt 0) {
        Write-Host "PATCHED - September 2026 cumulative update found in update history."
        exit 0
    }
    Write-Host "VULNERABLE - WDS role is installed and September 2026 cumulative update is NOT applied. CVE-2026-72957 is exploitable."
    exit 1
}

Sources

1. Cisco Talos – September 2026 Patch Tuesday Snort Rules
2. CrowdStrike – September 2026 Patch Tuesday Analysis
3. GBHackers – Microsoft September 2026 Patch Tuesday
4. TROOPERS26 – Windows Deployment Service: An AD Blind Spot?
5. Microsoft – WDS Hardening Guidance (CVE-2026-0386)
6. Check Point Research – PXE Dust: WDS Vulnerability Research
7. Microsoft MSRC – CVE-2026-72957 Advisory