CVE-2026-56649: Patch Windows NFS RCE in July 14 Updates

Microsoft’s July 14 security updates address CVE-2026-56649, a remote code execution vulnerability in Windows Network File System components that affects a wide range of supported Windows client and server releases. Administrators should prioritize deployment of the July cumulative updates to systems that run, or may run, NFS services—particularly Windows Server hosts used for Unix/Linux file sharing.
Microsoft’s Security Update Guide lists the flaw as a Windows Network File System Remote Code Execution Vulnerability. The National Vulnerability Database, which has imported Microsoft’s CVE record but has not yet completed its own enrichment, describes the root cause as improper synchronization of a shared resource—a race condition—combined with a use-after-free condition. An unauthenticated attacker could potentially execute code over a network.
The important qualification is exploit difficulty. Microsoft assigned CVE-2026-56649 a CVSS 3.1 score of 5.9, rated Medium, with a network attack vector and no requirement for privileges or user interaction—but with high attack complexity. The score also assigns high availability impact while listing no direct confidentiality or integrity impact in the base vector. In practice, that means the bug belongs in the patch queue now, but it is not being presented as a simple, broadly wormable network flaw.

Cybersecurity diagram showing an NFS server vulnerability patched, with exposed and secured network paths.The affected list reaches from Windows 10 to Server 2025​

Microsoft’s affected-product data covers Windows 10 1607, Windows 10 1809, Windows 10 21H2 and 22H2; Windows 11 24H2, 25H2, and 26H1; and Windows Server 2012 through Windows Server 2025. Server Core installations of Windows Server 2012, 2012 R2, 2016, 2019, and 2025 are also included.
That broad list does not mean every Windows PC is actively exposed to an NFS attack path. It means the vulnerable code is present in affected operating-system builds. Exposure is a separate operational question: whether the NFS-related feature set is installed, enabled, and reachable from networks an attacker can access.
For administrators, the cleanest first step is to deploy the July 14 cumulative update through the organization’s normal Windows Update, Windows Server Update Services, Microsoft Configuration Manager, or endpoint-management workflow. Microsoft’s published fixed-build data identifies the following remediation thresholds for several major branches:
  • Windows 11 24H2 should be updated to build 26100.8875 or later.
  • Windows 11 26H1 should be updated to build 28000.2525 or later.
  • Windows 10 22H2 should be updated to build 19045.7548 or later.
  • Windows Server 2022 should be updated to build 20348.5386 or later.
  • Windows Server 2025 should be updated to the current July servicing level identified by Microsoft’s update catalog and Security Update Guide.
The build information published with the CVE record contains at least one apparent inconsistency for Windows 11 25H2, where the listed remediation threshold does not align cleanly with the stated starting build family. That is a reason to validate compliance against the July 14 security update in your management platform rather than relying solely on a manually compared build number.

A network bug, but not an “everything on port 2049” emergency​

The difference between an installed component and an exposed service matters here. NFS is most commonly encountered where Windows Server provides file shares to Unix and Linux clients, where mixed-platform workloads need shared storage, or where an organization uses Microsoft’s NFS client capabilities. Many ordinary Windows endpoints will have no business use for it at all.
CISA’s Stakeholder-Specific Vulnerability Categorization data, published through the NVD record, currently marks exploitation as “none” and automation as “no.” It also characterizes the technical impact as partial, after an earlier record value indicated total impact. Those fields are not guarantees—an exploit can emerge after a patch is released—but they are meaningful signals that government vulnerability triage is not treating CVE-2026-56649 as an observed, automated mass-exploitation event.
Microsoft has not publicly indicated that the issue was exploited in the wild or publicly disclosed before the fix. No public proof-of-concept was associated with the advisory at publication. That status can change quickly after Patch Tuesday, especially when researchers begin comparing patched and unpatched binaries, but there is currently no basis for treating this as the next SMBv1-style emergency.
The code weakness is still worth taking seriously. Race conditions and use-after-free defects are memory-safety problems: the attacker’s challenge is to force the software into an unsafe state at exactly the right time, then turn the resulting crash or corrupted state into code execution. That complexity helps explain Microsoft’s scoring, but it does not eliminate risk for high-value servers where NFS is reachable from less-trusted network segments.

Patch first, then reduce the reachable attack surface​

Patching is the primary remediation. For environments where the normal update window cannot be met immediately, the practical compensating control is to identify Windows systems with NFS functionality enabled and restrict access to the service from only the hosts and segments that genuinely require it.
IT teams should review the following before making configuration changes:
  • Confirm whether Server for NFS or related NFS functionality is installed on Windows Server systems, rather than assuming the role is absent because it is not commonly used.
  • Check firewall policy and network segmentation around NFS-capable hosts, including paths from development, lab, partner, and virtual-desktop networks.
  • Remove unneeded NFS roles and features from servers that no longer provide cross-platform file services.
  • Treat externally reachable NFS service exposure as an urgent architecture issue, regardless of this individual CVE’s Medium severity rating.
  • Verify update deployment on Server Core as carefully as on full desktop installations, since Core variants are explicitly included in Microsoft’s affected-product data.
This is also a useful moment to distinguish NFS from SMB in asset inventories and monitoring rules. The protocols solve similar file-sharing problems but use different Windows features, services, ports, logging patterns, and hardening controls. A scan or policy that says “file sharing” without identifying the protocol can leave a blind spot precisely where a vulnerability like CVE-2026-56649 lives.

The next signal will be technical detail, not a revised severity badge​

The NVD record remains marked “Awaiting Enrichment,” so independent scoring and additional technical context may follow. Microsoft’s record confirms the vulnerability and the availability of fixes, but it does not currently provide a public mitigation beyond applying the security update, nor does it name a specific exploit precondition beyond the high-complexity network attack described by CVSS.
For Windows administrators, that leaves a straightforward near-term task: deploy the July 14 updates, verify NFS exposure on servers, and keep an eye on Microsoft’s advisory for revisions. CVE-2026-56649 is not presently a reason to shut down every Windows file server—but an unpatched NFS-enabled server on a flat network is exactly the kind of exception that should not wait for the next maintenance cycle.

References​

  1. Primary source: MSRC
    Published: 2026-07-14T07:00:00-07:00
  2. Related coverage: tomshardware.com
 

Back
Top