Microsoft has patched CVE-2026-56648, a high-severity elevation-of-privilege flaw in Windows Network File System (NFS) Server, in the July 14, 2026 security updates. The immediate priority is straightforward: organizations that run Server for NFS should deploy the applicable cumulative update, then verify that systems exposing NFS have actually advanced to the patched build.
Microsoft’s Security Response Center rates the issue at CVSS 7.5. The vendor describes a time-of-check, time-of-use race condition—commonly called a TOCTOU flaw—in Windows NFS that an authorized attacker could exploit over a network to elevate privileges. The National Vulnerability Database record adds a second weakness classification, use-after-free, and identifies the impact scope as high for confidentiality, integrity, and availability.
This is not an Internet-wide, unauthenticated worm scenario. Microsoft’s CVSS vector requires low privileges and assigns high attack complexity, while requiring no user interaction. But that should not be read as a reason to defer patching: an attacker with an account or otherwise valid NFS access could use a successful exploit to turn limited access into much broader control of an NFS server.
CISA’s SSVC metadata, published alongside the CVE record, currently marks exploitation as “none” and automation as “no.” In practical terms, there is no public indication as of July 15 that Microsoft or CISA has observed exploitation in the wild, and the vulnerability is not assessed as readily automatable. That lowers emergency-response pressure, but it does not change the remediation requirement for systems where the NFS role is enabled.
The useful distinction for administrators is between Windows versions listed as affected and machines that are actually exposed. Microsoft documents Server for NFS as an optional File and Storage Services role, rather than a default Windows Server component. Microsoft Learn identifies its feature name as
That means a standard Windows Server deployment that has never been configured to serve NFS shares may not have the vulnerable service active. Conversely, a server used to bridge Linux, UNIX, VMware, storage, media-rendering, engineering, or scientific workloads can be a meaningful target even if NFS is only a secondary file-sharing protocol alongside SMB.
Microsoft’s affected-product data spans a considerable range:
Windows Server 2022 receives KB5099540, advancing the OS to build 20348.5386. Microsoft’s servicing pages state that these cumulative updates include the July 2026 security fixes. Administrators should use their normal Windows Update for Business, Windows Server Update Services, Microsoft Configuration Manager, or Microsoft Update Catalog workflows rather than attempt to isolate and install an individual NFS component update.
Build verification matters, particularly in environments with staged rings, disconnected networks, or base images whose servicing level is unclear. A server can report that July updates are approved in WSUS and still be vulnerable if it has not completed installation and rebooted. Confirm the current OS build through
For Windows Server fleets, the patching order should reflect real exposure:
The NVD record’s combination of CWE-367 for TOCTOU and CWE-416 for use-after-free signals that this is not being characterized as a simple access-control misconfiguration. It points to a defect in how Windows NFS handles object lifetime or state during a sequence of operations. That is relevant to defenders because a patch is the meaningful fix; tuning an NFS export’s permissions may reduce who can attempt the attack, but it does not eliminate the underlying flaw.
The “authorized attacker” requirement deserves equal attention. NFS has historically been deployed for interoperability, often with identity mapping, export-based controls, and older operational assumptions that do not resemble a modern zero-trust boundary. An attacker may not need to be a Windows domain administrator to meet the prerequisite. A compromised Linux client, a stolen user credential, an exposed integration account, or overbroad network access to a share can be enough to move the attack from theoretical to relevant.
That makes this a good moment to review who can mount each export, which subnets can reach NFS servers, whether legacy NFS versions remain necessary, and whether service accounts have access beyond their job. Those steps are defense in depth, not substitutes for the July update.
A returned
For servers that do not need to provide NFS, removing the role is a sensible exposure-reduction step after assessing workload dependencies. Microsoft documents the Server for NFS service as optional, so its absence is a meaningful security boundary in this case. Do not disable it blindly on systems used by Linux clients, infrastructure automation, or appliances that rely on NFS mounts.
CVE-2026-56648 is therefore a focused July patching item, not a reason for blanket alarm across every Windows PC. But for the subset of organizations running Windows-based NFS servers, it is a real network privilege-escalation path with broad potential impact after authentication. The next practical milestone is clear: get exposed servers to Microsoft’s July 14 patched builds, confirm the rebooted version, and treat NFS access review as part of the closure work—not an optional afterthought.
Microsoft’s Security Response Center rates the issue at CVSS 7.5. The vendor describes a time-of-check, time-of-use race condition—commonly called a TOCTOU flaw—in Windows NFS that an authorized attacker could exploit over a network to elevate privileges. The National Vulnerability Database record adds a second weakness classification, use-after-free, and identifies the impact scope as high for confidentiality, integrity, and availability.
This is not an Internet-wide, unauthenticated worm scenario. Microsoft’s CVSS vector requires low privileges and assigns high attack complexity, while requiring no user interaction. But that should not be read as a reason to defer patching: an attacker with an account or otherwise valid NFS access could use a successful exploit to turn limited access into much broader control of an NFS server.
CISA’s SSVC metadata, published alongside the CVE record, currently marks exploitation as “none” and automation as “no.” In practical terms, there is no public indication as of July 15 that Microsoft or CISA has observed exploitation in the wild, and the vulnerability is not assessed as readily automatable. That lowers emergency-response pressure, but it does not change the remediation requirement for systems where the NFS role is enabled.
The vulnerable service is optional, but the affected list is wide
The useful distinction for administrators is between Windows versions listed as affected and machines that are actually exposed. Microsoft documents Server for NFS as an optional File and Storage Services role, rather than a default Windows Server component. Microsoft Learn identifies its feature name as FS-NFS-Service, and notes that it is not installed by default on supported Server Core configurations.That means a standard Windows Server deployment that has never been configured to serve NFS shares may not have the vulnerable service active. Conversely, a server used to bridge Linux, UNIX, VMware, storage, media-rendering, engineering, or scientific workloads can be a meaningful target even if NFS is only a secondary file-sharing protocol alongside SMB.
Microsoft’s affected-product data spans a considerable range:
- Windows Server 2012 and Windows Server 2012 R2, including Server Core installations, are affected below builds 9200.26226 and 9600.23291, respectively.
- Windows Server 2016 and Windows Server 2019 are affected below builds 14393.9339 and 17763.9020.
- Windows Server 2022 requires build 20348.5386 or later, while Windows Server 2025 and Server Core require build 26100.33158 or later.
- Windows 10 21H2 and 22H2 are affected below builds 19044.7548 and 19045.7548.
- Windows 11 24H2 and 25H2 require build 26100.8875 or later; Windows 11 26H1 requires build 28000.2525 or later.
Patch status is more important than the CVSS label
The July cumulative updates carry the fix. For the mainstream Windows 11 branches, Microsoft’s July 14 package is KB5101650, which brings Windows 11 24H2 to build 26100.8875 and Windows 11 25H2 to build 26200.8875. Windows 11 26H1 receives KB5101649, reaching build 28000.2525.Windows Server 2022 receives KB5099540, advancing the OS to build 20348.5386. Microsoft’s servicing pages state that these cumulative updates include the July 2026 security fixes. Administrators should use their normal Windows Update for Business, Windows Server Update Services, Microsoft Configuration Manager, or Microsoft Update Catalog workflows rather than attempt to isolate and install an individual NFS component update.
Build verification matters, particularly in environments with staged rings, disconnected networks, or base images whose servicing level is unclear. A server can report that July updates are approved in WSUS and still be vulnerable if it has not completed installation and rebooted. Confirm the current OS build through
winver, Settings, or PowerShell inventory after deployment, and reconcile that result against Microsoft’s affected-build thresholds.For Windows Server fleets, the patching order should reflect real exposure:
- Patch internet-reachable or partner-reachable NFS servers first, even where firewall policy is believed to limit access.
- Prioritize NFS systems whose mounts are available to broad user populations, shared service accounts, build infrastructure, or non-Windows workstation segments.
- Patch internal NFS servers next, especially where identity mapping and export permissions have accumulated over time.
- Validate mount availability and normal read/write operations after restart, because availability failures on a file-sharing tier can be as disruptive as the vulnerability itself.
A race condition can be ugly even when exploitation is hard
A TOCTOU vulnerability arises when software checks a condition—such as an object’s state, identity, or permissions—and then acts on that assumption later, after the relevant condition may have changed. Race-condition exploitation usually requires careful timing, which helps explain Microsoft’s “high” attack-complexity rating.The NVD record’s combination of CWE-367 for TOCTOU and CWE-416 for use-after-free signals that this is not being characterized as a simple access-control misconfiguration. It points to a defect in how Windows NFS handles object lifetime or state during a sequence of operations. That is relevant to defenders because a patch is the meaningful fix; tuning an NFS export’s permissions may reduce who can attempt the attack, but it does not eliminate the underlying flaw.
The “authorized attacker” requirement deserves equal attention. NFS has historically been deployed for interoperability, often with identity mapping, export-based controls, and older operational assumptions that do not resemble a modern zero-trust boundary. An attacker may not need to be a Windows domain administrator to meet the prerequisite. A compromised Linux client, a stolen user credential, an exposed integration account, or overbroad network access to a share can be enough to move the attack from theoretical to relevant.
That makes this a good moment to review who can mount each export, which subnets can reach NFS servers, whether legacy NFS versions remain necessary, and whether service accounts have access beyond their job. Those steps are defense in depth, not substitutes for the July update.
Find NFS before declaring the fleet safe
Microsoft’s deployment documentation shows that Server for NFS is installed using theFS-NFS-Service role service. On Windows Server, administrators can identify its presence with PowerShell:Get-WindowsFeature FS-NFS-ServiceA returned
Installed state should place that server in the remediation and validation queue. The same inventory process should identify hosts that may have NFS software installed but no current shares; those systems should still be patched, while the role can be removed if it is no longer required.For servers that do not need to provide NFS, removing the role is a sensible exposure-reduction step after assessing workload dependencies. Microsoft documents the Server for NFS service as optional, so its absence is a meaningful security boundary in this case. Do not disable it blindly on systems used by Linux clients, infrastructure automation, or appliances that rely on NFS mounts.
CVE-2026-56648 is therefore a focused July patching item, not a reason for blanket alarm across every Windows PC. But for the subset of organizations running Windows-based NFS servers, it is a real network privilege-escalation path with broad potential impact after authentication. The next practical milestone is clear: get exposed servers to Microsoft’s July 14 patched builds, confirm the rebooted version, and treat NFS access review as part of the closure work—not an optional afterthought.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: support.microsoft.com
MS16-016: Security update for WebDAV to address elevation of privilege: February 9, 2016 | Microsoft Support
Resolves a vulnerability in Windows that could allow elevation of privilege if an attacker uses the Microsoft Web Distributed Authoring and Versioning (WebDAV) client to send specifically crafted input to a server.support.microsoft.com - Official source: learn.microsoft.com
Add or Remove Roles and Features in Windows Server | Microsoft Learn
Learn how to add or remove roles and features in Windows Server on local, remote servers, or offline virtual hard disks (VHDs), including to multiple servers concurrently. Get step-by-step guidance.learn.microsoft.com
