Windows NFS Server CVE-2026-69675

Requires the Windows Network File System (NFS) server role to be installed and running on the target host - this is an optional feature not present in default Windows Server installations. The attacker must also hold valid low-level local privileges (PR:L) on that host and be able to interact with the NFS service locally (AV:L); there is no network-remote or unauthenticated path per the CVSS vector. Limiting factors: local access only, pre-existing authentication required, dependence on the non-default NFS role, and impact restricted to information disclosure (no code execution, modification, or denial of service).

This is a moderate-severity, low-urgency issue - not a top priority despite the 'authorized attacker' phrasing. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5) describes a local, low-complexity attack that requires existing low-level privileges (PR:L) and yields only confidentiality impact (C:H, no integrity or availability effect) - consistent with an out-of-bounds read (CWE-125) leaking memory contents. All three signals point the same way: CISA's SSVC decision framework rates Exploitation as 'none', Automatable as 'no', and Technical Impact as only 'partial', and there is no CISA KEV listing and no public POC. EPSS data was NOT provided in the input, so exploitation probability cannot be quantified. There is no conflict among the available signals - low CVSS, no observed exploitation, not automatable, and information-only impact all agree this is a low-real-risk patch-in-normal-cycle item rather than an emergency. The one nuance to verify: exploitation requires the attacker to already have local authenticated access to a host running the Windows NFS role, which further limits practical risk.

An attacker who already has a low-privileged local account on a Windows Server with the Network File System role enabled interacts with the NFS service in a way that triggers an out-of-bounds read, causing adjacent kernel/process memory to be returned to them. The leaked memory could contain sensitive data such as credentials or address-layout information useful for chaining further attacks. No public exploit code has been identified, and the local access plus low-complexity but authorized prerequisite make opportunistic mass exploitation unlikely.