Windows Failover Cluster EUVD-2026-73742

The target system must have the Windows Failover Cluster feature explicitly installed and the clustering service running - this feature is not enabled by default on any affected Windows version and requires deliberate installation and configuration. The CVSS vector (PR:N) confirms no authentication is required once the cluster service port is reachable. Exploitation is limited to attackers with network-layer access to cluster communication ports; properly isolated cluster VLANs or host-based firewall rules restricting inbound cluster traffic to known node IPs effectively block unauthenticated external access. The listing of Windows 10 Version 1809 as affected is notable - Failover Cluster is available only in Windows 10 Enterprise or Datacenter SKUs configured as cluster nodes, representing a very narrow deployment footprint on desktop OS builds.

The CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects unauthenticated network exploitation with high confidentiality impact and low attack complexity, which on paper places this in a high-priority remediation band. However, real-world risk is moderated by deployment context: Windows Failover Cluster is not installed or enabled by default, requires explicit feature installation and cluster configuration, and nodes are typically placed on isolated, high-trust cluster VLANs inaccessible from untrusted networks or the internet. The absence of integrity and availability impact limits the attack's utility to reconnaissance and data exfiltration, reducing its operational value to most threat actors. No EPSS data was provided in available sources. The vulnerability is not in CISA KEV and no POC is publicly known, supporting a medium-priority real-world risk posture despite the high nominal CVSS score. Organizations with cluster nodes exposed on flat or under-segmented networks face materially higher risk than those with properly isolated cluster VLANs.

An unauthenticated attacker with network reach to a Windows Failover Cluster node sends a crafted protocol request to the cluster service port, triggering the allocation and return of uninitialized heap memory in the service response. The returned payload may contain fragments of sensitive data held in the cluster service process - such as credentials, session tokens, or inter-node communication secrets - enabling further lateral movement within the cluster infrastructure. No public proof-of-concept is known at time of analysis.