CVE-2026-34344

What it actually does

This is a local privilege escalation vulnerability in the Windows Ancillary Function Driver for WinSock, afd.sys. The flaw is a type confusion condition where the driver may access a resource as an incompatible object type, potentially allowing a low-privileged authenticated user or already-running local code to corrupt kernel memory and execute with elevated privileges. Successful exploitation can provide SYSTEM-level control on affected Windows client and server versions, compromising confidentiality, integrity, and availability of the host. It is not directly remotely exploitable by itself because the attacker needs local access or a prior foothold.

Why it matters to the business

If exploited, an attacker who has already gained limited access to a Windows system could take full control of that machine, disable security tooling, steal sensitive data, move laterally, or deploy additional malware. Because the affected product list spans many supported Windows desktop and server releases, exposure may be broad across enterprise endpoint, workstation, and server fleets. The vulnerability has a high severity score, but current public signals indicate lower immediate exploitation pressure: it is not listed in CISA KEV, is not identified as ransomware-used, has low and flat EPSS, and has no reported mature public exploit. Since it has been public for over 90 days, organizations should ensure it is included in completed patch cycles rather than defer it indefinitely.

How an attack unfolds

An attacker first needs authenticated local execution on an affected Windows host, commonly obtained through phishing, stolen credentials, malicious document execution, exploitation of another application, or compromise of a low-privileged account. The attacker then runs code that interacts with the Windows networking subsystem exposed through WinSock and the Ancillary Function Driver. By triggering the type confusion condition, the attacker attempts to manipulate kernel memory in a controlled way and redirect execution or modify security-relevant kernel objects. If successful, the attacker escapes the restrictions of the original low-privileged context and obtains SYSTEM-level privileges. From there, they can install persistence, dump credentials, tamper with endpoint defenses, access protected files, or use the host as a staging point for lateral movement. There is no current public indication of widespread exploitation or named threat actor use, but local privilege escalation bugs in Windows kernel drivers are commonly chained with initial-access vulnerabilities when reliable exploit code becomes available.

How to fix it

Apply the Microsoft security update that addresses this vulnerability for all affected Windows versions, including Windows 10, Windows 11, Windows Server 2012, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2022 23H2, and Windows Server 2025. Because exact fixed build numbers were not provided in the input, use the Microsoft Security Update Guide and Windows release health documentation to identify the correct cumulative update or security-only update for each operating system release. Prioritize internet-facing servers, shared administrative workstations, virtual desktop infrastructure, jump hosts, systems used by privileged users, and endpoints with elevated business sensitivity. Where immediate patching is not possible, reduce exposure by limiting interactive logon rights, removing unnecessary local administrator rights, enforcing application control, enabling endpoint detection and response protections, and preventing untrusted code execution. There is no complete configuration-only mitigation for a kernel local privilege escalation vulnerability; patching is the primary remediation.

How to confirm the fix worked

Confirm remediation by verifying that each affected Windows host has installed the applicable cumulative security update released for this issue or a later superseding update. Validate through centralized patch management, Windows Update history, Microsoft Defender Vulnerability Management, WSUS, SCCM, Intune, or equivalent endpoint inventory tools. Check that the operating system build and revision are at or above the fixed level listed by Microsoft for the corresponding Windows release. For higher-assurance validation, compare the installed afd.sys file version and signing timestamp against the version delivered by the applicable fixed update. Reboot systems where required, because kernel driver fixes may not take effect until the patched driver is loaded. For exposure assessment, inventory systems running the affected Windows versions and identify devices missing the relevant cumulative update.

Typical attack path

1. Obtain initial access to an affected Windows endpoint or server using separate means, such as stolen credentials, malware execution, or exploitation of another vulnerability.
2. Run code as a standard authenticated user or otherwise low-privileged local principal.
3. Invoke Windows networking functionality that reaches the Ancillary Function Driver for WinSock, afd.sys.
4. Trigger the type confusion condition to corrupt or manipulate kernel memory.
5. Escalate from the low-privileged user context to SYSTEM or equivalent local administrative control.
6. Disable security controls, dump credentials, access sensitive local data, establish persistence, or move laterally to other systems.

How to detect it

There are no reliable public indicators that uniquely identify exploitation of this vulnerability, and access to afd.sys is not normally logged in a way that directly proves attempted exploitation. Detection should focus on post-exploitation behavior following a local privilege escalation. Review Windows Security logs, Sysmon, EDR telemetry, Microsoft Defender alerts, service control events, PowerShell logs, and crash telemetry around suspected compromise windows. Look for low-privileged user processes unexpectedly creating SYSTEM-level child processes, spawning command shells, adding local administrators, creating services, modifying scheduled tasks, disabling security tools, dumping credentials, or loading unsigned/suspicious drivers. Relevant Windows events include process creation events such as 4688, service installation events such as 7045, scheduled task creation events such as 4698, account/group modification events such as 4720, 4732, and 4738, and security policy or defense tampering events. Sysmon events to review include process creation, driver load, file creation, registry modification, and process access events, especially where the parent process is a user-writable executable path and the resulting process runs as SYSTEM. Also review Windows Error Reporting, kernel bugcheck events, memory dumps, and EDR crash analytics for unusual afd.sys-related crashes, because failed kernel exploitation may destabilize the system. Treat any apparent privilege boundary crossing from a standard user context to SYSTEM, followed by credential access, defense evasion, persistence, or lateral movement, as suspicious even if the exact exploit cannot be confirmed from logs alone.

What your security team should do

• Prioritize deployment of the relevant Microsoft cumulative security updates across affected Windows client and server versions, especially servers, administrative workstations, VDI, and high-value endpoints.
• Use vulnerability management data to identify systems still running affected Windows releases without the superseding security update, and track remediation to completion.
• Because the flaw requires local access, pair patching with controls that reduce initial footholds: phishing-resistant authentication, endpoint protection, application control, macro/script restrictions, and least-privilege user configurations.
• Review endpoint telemetry for signs of suspicious privilege escalation, including unexpected low-privileged processes spawning SYSTEM shells, new services, security tool tampering, credential dumping, or post-exploitation activity.
• Ensure EDR and Microsoft Defender signatures, behavioral detections, and cloud-delivered protections are enabled and current.
• Harden privileged access paths by restricting local logon rights, removing unnecessary local administrators, and using separate administrative accounts for management tasks.
• For systems that cannot be patched promptly, increase monitoring and limit who can execute code locally until the update is applied.
• Do not treat the low EPSS and absence from KEV as a reason to ignore the issue; local privilege escalation vulnerabilities are often weaponized later and chained with separate initial-access techniques.