CVE-2026-56649

What it actually does

This vulnerability is a race condition in the Windows Network File System implementation. An unauthenticated remote attacker can send carefully timed concurrent NFS/RPC requests that cause the service to access shared state without proper synchronization. If the race is won, the service may enter an unsafe state that can result in remote code execution or service instability; the published CVSS impact emphasizes high availability impact, so defenders should treat exploitation as potentially service-disruptive and potentially code-executing on systems with the Windows NFS role exposed.

Why it matters to the business

Organizations using Windows systems as NFS servers could experience disruption of file-sharing services, loss of access to shared storage, application outages that depend on NFS mounts, and possible compromise of affected Windows hosts if exploitation achieves code execution. The risk is lower than many commodity remote flaws because exploitation is rated high-complexity, EPSS is currently low, it is not in CISA KEV, and no public exploit maturity is reported, but internet- or partner-exposed NFS services should still be prioritized because the attack is unauthenticated and network reachable.

How an attack unfolds

An attacker first identifies a Windows host exposing NFS-related services, typically RPC portmapper and NFS service ports. They then issue large numbers of concurrent or precisely timed NFS/RPC operations designed to force two or more service threads to manipulate the same shared resource at the same time. Because the vulnerable code path does not synchronize that shared resource correctly, one thread can observe or modify inconsistent state created by another. A successful attempt may crash or hang the Windows NFS service, causing denial of service to NFS clients, and may allow attacker-controlled execution depending on the reachable code path and memory state. Exploitation is expected to be unreliable and timing-sensitive, which aligns with the high attack complexity and currently low EPSS, but repeated attempts over the network may be observable as bursts of NFS traffic, service crashes, Windows Error Reporting events, or abnormal processes spawned by the NFS service.

How to fix it

Apply the applicable Microsoft security update or latest cumulative update for all affected Windows versions, including Windows 10 1607/1809/21H2/22H2, Windows 11 24H2/25H2/26H1, and Windows Server 2012/2016/2019/2022/2025. No exact fixed build numbers were provided in the input, so remediation should be validated against Microsoft’s official update guidance for CVE-2026-56649 and the relevant Windows release channel. If immediate patching is not possible, reduce exposure by disabling the Windows Server for NFS role where not required, blocking NFS/RPC access from untrusted networks, restricting NFS to known client subnets, filtering TCP/UDP 2049 and RPC-related ports at host and network firewalls, and placing NFS servers behind VPN or private network controls. Because exploitation is unauthenticated, do not rely on NFS export permissions alone as the primary mitigation.

How to confirm the fix worked

Confirm that affected Windows hosts have installed the Microsoft security update or cumulative update that supersedes the vulnerable NFS components. Inventory systems with the Windows Server for NFS role enabled and verify that patched build numbers match Microsoft’s release documentation. Validate that TCP/UDP 2049 and RPC-related ports are not reachable from untrusted networks using authenticated vulnerability scanning and network port checks. Confirm that the NFS service remains stable after patching and that legitimate NFS clients can still mount and access required exports. Where mitigation rather than patching is used, test firewall rules from an untrusted network segment to ensure NFS and RPC access is blocked.

Typical attack path

1. Scan networks for Windows systems exposing NFS/RPC services, especially TCP/UDP 2049 and RPC endpoint mapping on TCP/UDP 111 or 135.
2. Confirm that the target is running the Windows Server for NFS role or related Services for NFS components.
3. Send concurrent NFS/RPC requests that exercise the vulnerable shared-resource code path.
4. Repeat and tune request timing to trigger the race condition reliably.
5. On success, cause the NFS service to crash, hang, or potentially execute attacker-controlled code in the service context.
6. If code execution is achieved, establish persistence, move laterally, or use the host’s file-sharing role to disrupt dependent workloads.

How to detect it

To determine whether exploitation may have already occurred, review Windows hosts running Server for NFS or Services for NFS for signs of abnormal NFS service instability and suspicious network activity. Key log sources include Windows System logs for Service Control Manager events, Application logs for application faults, Windows Error Reporting artifacts, NFS operational logs if enabled, EDR process telemetry, firewall logs, NetFlow, and packet-capture metadata for NFS/RPC ports. Look for repeated crashes or restarts of the NFS service, faulting modules associated with NFS components, WerFault activity shortly after bursts of NFS requests, unusually high concurrency from a single remote address, malformed or failed NFS/RPC calls, and any unexpected child process launched from an NFS service context. If code execution is suspected, triage for post-exploitation behavior such as command shells, PowerShell, rundll32, regsvr32, or network tools spawned by service processes; new services; scheduled tasks; suspicious outbound connections; credential-access tooling; and lateral movement from the NFS server. There are no public exploit-specific indicators provided, so detections should focus on behavioral evidence around NFS service crashes, race-triggering traffic patterns, and abnormal process ancestry.

• TCP/2049
• UDP/2049
• TCP/111
• UDP/111
• TCP/135
• UDP/135
• NfsService
• Server for NFS
• Services for NFS
• Microsoft-Windows-ServicesForNFS-Server
• Microsoft-Windows-NFS-Server
• Service Control Manager
• Event ID 7031
• Event ID 7034
• WerFault.exe
• Faulting application name: NfsService.exe
• Faulting application name: nfssvc.exe
• Faulting module name: nfssvc.exe
• Faulting module name: nfsserver.sys
• C:\Windows\System32\WerFault.exe
• C:\ProgramData\Microsoft\Windows\WER\ReportArchive
• C:\ProgramData\Microsoft\Windows\WER\ReportQueue
• cmd.exe spawned by NfsService
• powershell.exe spawned by NfsService
• rundll32.exe spawned by NfsService
• regsvr32.exe spawned by NfsService
• certutil.exe spawned by NfsService

What your security team should do

• Prioritize patching Windows servers that run the Server for NFS role and are reachable from non-management, partner, DMZ, or internet-adjacent networks.
• Immediately inventory Windows hosts exposing NFS services and confirm whether the role is required.
• Restrict TCP/UDP 2049 and RPC-related access to approved NFS clients only; block exposure from untrusted networks.
• Enable and retain Windows System, Application, Windows Error Reporting, service control, and NFS operational logs on systems providing NFS.
• Create detections for repeated NFS service crashes, NfsService restarts, abnormal WerFault activity involving NFS components, and unusual child processes spawned by NFS service processes.
• Review recent NFS/RPC traffic for spikes in concurrent requests, repeated failed sessions, or probing from unfamiliar source IPs.
• Because this is not currently KEV-listed and has low EPSS, track vendor and threat-intelligence updates, but escalate urgency if public exploit code or active exploitation emerges.