Microsoft Windows Ancillary Function Driver for WinSock use-after-free enables local privilege escalation

Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.

The record identifies the following branches as affected. The < notation is preserved from the supplied version boundaries.

• Windows 10 Version 1607: 10.0.14393.0 through < 10.0.14393.9418.
• Windows 10 Version 1809: 10.0.17763.0 through < 10.0.17763.9121.
• Windows 10 Version 21H2: 10.0.19044.0 through < 10.0.19044.7663.
• Windows 10 Version 22H2: 10.0.19045.0 through < 10.0.19045.7663.
• Windows 11 Version 23H2: 10.0.22631.0 through < 10.0.22631.7517. The record contains two duplicate 23H2 entries.
• Windows 11 Version 24H2: 10.0.26100.0 through < 10.0.26100.9168.
• Windows 11 Version 25H2: 10.0.26200.0 through < 10.0.26200.9168.
• Windows 11 version 26H1: 10.0.28000.0 through < 10.0.28000.2704.
• Windows Server 2012, including Server Core installation: 6.2.9200.0 through < 6.2.9200.26280.
• Windows Server 2012 R2, including Server Core installation: 6.3.9600.0 through < 6.3.9600.23338.
• Windows Server 2016, including Server Core installation: 10.0.14393.0 through < 10.0.14393.9418.
• Windows Server 2019, including Server Core installation: 10.0.17763.0 through < 10.0.17763.9121.
• Windows Server 2022: 10.0.20348.0 through < 10.0.20348.5499.
• Windows Server 2025, including Server Core installation: 10.0.26100.0 through < 10.0.26100.33296.

The status of branches or configurations not listed is not established by this record.

The flaw is in the Windows Ancillary Function Driver for WinSock and is classified as a use-after-free. This occurs when a component continues to use an object or memory region after it has been released, potentially causing processing of invalid memory or state.

An attacker must have local access with low-level initial privileges. The record states that no separate user interaction is required, but exploitation has high complexity. The supplied evidence does not identify the specific API, request, object, lifetime sequence, or attacker-controlled data involved, so a detailed exploit chain should not be inferred. The confirmed outcome is local privilege escalation within the security authority of the affected system.

The record provides the following conditions and status:

• Reachability: Local, not a direct network attack path.
• Required privileges: The attacker must be an authorized local user with low initial privileges.
• User interaction: No interaction from another user is required.
• Complexity: High, so exploitation should not be assumed to succeed at will under every condition.
• Exploitation status: The record marks the vulnerability as known exploited and as having a public exploit. Details about exploit code, threat actor, victim, indicators of compromise, or the exploitation sequence are not provided in the available evidence.

The flaw can result in local privilege escalation after successful exploitation. Based on the impact information in the record, the resulting privilege increase may affect the confidentiality, integrity, and availability of resources managed by the same system, but the record does not specify the final privilege level or post-exploitation actions.

The attacker still needs existing local access, and exploitation has high complexity. This is therefore not evidenced as a direct network-access vulnerability, but it can amplify a compromise or local account foothold. Organizations should treat unpatched systems as more exposed when an attacker already has local access.

Successful exploitation could allow a low-privileged local user to obtain higher privileges on an affected Windows system. With higher privileges, an attacker may be able to access protected data, alter system or application state, and affect availability; the practical extent depends on the privileges obtained and the particular system.

This is an operationally significant issue because the record reports known exploitation and a public exploit. The record does not identify a specific organization, victim, campaign, or breach.

1. Deploy the applicable Microsoft security update for every affected branch. The fixed builds supplied in the record are:

• Windows 10 Version 1607 and Windows Server 2016, including Server Core: 10.0.14393.9418.
• Windows 10 Version 1809 and Windows Server 2019, including Server Core: 10.0.17763.9121.
• Windows 10 Version 21H2: 10.0.19044.7663.
• Windows 10 Version 22H2: 10.0.19045.7663.
• Windows 11 Version 23H2: 10.0.22631.7517.
• Windows 11 Version 24H2 and Windows Server 2025, including Server Core: respectively 10.0.26100.9168 and 10.0.26100.33296.
• Windows 11 Version 25H2: 10.0.26200.9168.
• Windows 11 version 26H1: 10.0.28000.2704.
• Windows Server 2012, including Server Core: 6.2.9200.26280.
• Windows Server 2012 R2, including Server Core: 6.3.9600.23338.
• Windows Server 2022: 10.0.20348.5499.

1. Verify after deployment that each system reports the exact fixed build for its product branch. Do not assume that a fixed build for one branch applies automatically to another branch.
2. If immediate patching is not possible, reduce unnecessary local access and increase monitoring for privilege-escalation activity as temporary risk-reduction measures. These are not vendor-confirmed workarounds and do not replace the security update.
3. Because the record marks the vulnerability as known exploited, prioritize endpoints and servers below the applicable fixed threshold. The record does not provide any additional product-specific mitigation beyond applying the update.

• Inventory Microsoft Windows workstations and servers, including Server Core deployments, and identify the installed operating-system branch and build.
• Compare installed builds with the affected thresholds and corresponding fixed builds in affected_summary. Prioritize systems below the applicable fixed threshold.
• Review available security telemetry for unexpected local privilege escalation and anomalous activity involving the Ancillary Function Driver for WinSock. Treat this as precautionary monitoring, not as a Microsoft-confirmed indicator.
• The record does not provide an event ID, log pattern, hash, filename, or specific exploitation signature. Absence of these generic signs must not be treated as proof that a system is safe.