Windows Winsock CVE-2026-72927

Requires the attacker to already have local, authenticated low-privileged code execution on the target Windows host (PR:L, AV:L) - this is a privilege-escalation primitive, not a remotely reachable entry point. No user interaction is needed (UI:N) and no special product feature or non-default configuration is called out; the vulnerable Winsock (afd/socket) component is present by default across supported Windows 10 (1607-22H2), Windows 11 (23H2-26H1), and Windows Server 2012 through 2025 builds. Limiting factors: the need for an existing foothold, the reliability of heap grooming for successful kernel heap corruption, and application of the vendor patch (fixed builds listed in EUVD, e.g. Windows 11 24H2 <10.0.26100.9445, Server 2025 <10.0.26100.33438).

This is a credible but not urgent local privilege-escalation flaw. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) correctly frames it as a local attack requiring an already-authenticated low-privileged foothold, with low complexity, no user interaction, and full confidentiality/integrity/availability impact within the same scope - consistent with a heap corruption in the Winsock kernel component (CWE-122) leading to SYSTEM-level code execution. The signals are internally consistent: CISA SSVC rates Exploitation as 'none', Automatable as 'no' (as expected for a local, non-network-wormable EoP), and Technical Impact as 'total' (matching C:H/I:H/A:H and the AC:L/PR:L path). EPSS is low at 0.26% (17th percentile), there is no CISA KEV listing, and no public exploit is identified - so despite the high 7.8 score this is not evidence of imminent or widespread exploitation. The practical risk is that of a reliable post-compromise escalation primitive: an attacker who already has code execution as a normal user (via phishing, malware, or another bug) could chain this to gain SYSTEM. Because it affects the ubiquitous Windows platform, it should be patched on the normal Patch-Tuesday cadence and prioritized on multi-user/shared and internet-facing hosts, but it is not a drop-everything network-exploitable emergency. No signals conflict here; the main uncertainty is the absence of vulnerability-specific technical detail (exact Winsock code path) in the sparse Microsoft/NVD description.

A local attacker who has already obtained a low-privileged authenticated session on a Windows host (e.g., via commodity malware or a compromised standard user account) runs a crafted program that issues malformed Winsock socket operations to trigger the heap-based buffer overflow. By grooming the kernel/pool heap and corrupting adjacent structures, they escalate from the standard user context to SYSTEM. No public proof-of-concept or exploit code has been identified at time of analysis, and exploitation requires local access plus reliable heap-layout control (AC:L but non-trivial exploit engineering).