DEV Community

jeffrey
jeffrey

Posted on

CVE-2026-70585: A Use-After-Free in the Windows NFS Client Stack

CVE-2026-70585: A Use-After-Free in the Windows NFS Client Stack

Windows can mount NFS shares as a client, and that capability pulls a remote procedure call parser into the kernel's network path. CVE-2026-70585 is a use-after-free in that parser, and it is a good example of a low CVSS score attached to a high-consequence code path.

What the record says

NVD describes CVE-2026-70585 as a use-after-free in Windows Services for NFS ONCRPC XDR Driver allowing an authorized attacker to execute code locally. The weakness is CWE-416 and the CVSS base score is 7.0. It was published on 8 September 2026.

Why the score and the description diverge from intuition

The word "locally" in the description does not mean the attacker is sitting at the console. It means the code path is reachable from the local system's network stack after a share is mounted, which in practice means an attacker who controls the NFS server can influence what the client parses.
That scenario is the one worth taking seriously. The NFS server that a Windows host mounts might be an internal file server, a NAS appliance, a lab system, or a partner's storage. Any of those can be compromised, misconfigured, or simply hostile. When the client's XDR parser mishandles a response, the client's kernel is the thing that fails.

The parsing problem, stated plainly

External Data Representation is a serialization format, and a decoder for it must make length and type decisions on the basis of bytes that came over the wire. A use-after-free in that decoder means the code touched a data structure after something else had already released it, the conventional recipe for attacker-influenced memory reuse.
The reason this sits at 7.0 rather than higher is the metrics: the attacker needs a position that lets them answer as the NFS server, and the outcome is described as local code execution. Both of those constraints are real. Neither of them makes the bug harmless in an environment where NFS mounts are common and the storage tier is not treated as a trust boundary.

Handling

Apply the September 2026 updates to any Windows host with the NFS client feature installed. Check first: the feature is often a leftover from a migration project rather than a deliberate design decision, and removing the client from hosts that do not need it eliminates the surface.
Where NFS mounts are required, pin them to specific servers rather than accepting mounts from arbitrary addresses, and treat the storage network as a security zone with its own access control. A file server that answers NFS requests to a broad address range is a server that can decide what a Windows kernel parses.
Finally, consider whether the Windows-to-NFS path needs to exist at all. SMB is the native protocol for Windows clients, and every protocol removed from the client stack is a parser that can no longer be attacked.

References

Top comments (0)