CVE-2026-45598

What it actually does

This vulnerability is a local elevation-of-privilege flaw in the Windows Ancillary Function Driver for WinSock, commonly associated with the kernel driver afd.sys. The issue is a use-after-free condition: kernel memory can be released and then accessed again under specific race conditions. A low-privileged, authenticated local attacker who can run code on an affected Windows system may be able to manipulate memory reuse and execute code with kernel-level privileges, potentially gaining SYSTEM-level control. The CVSS vector indicates local access is required, user interaction is not required, privileges are required, and successful exploitation can fully compromise confidentiality, integrity, and availability of the affected host. Exploitation complexity is high, which means reliable exploitation likely requires precise timing, memory shaping, and platform-specific knowledge.

Why it matters to the business

If exploited, this flaw can allow an attacker who already has limited access to a Windows workstation or server to take full control of that machine. In business terms, it can turn an initial foothold from phishing, stolen credentials, malware, or a compromised low-privileged account into complete host compromise. On servers, this may expose sensitive data, enable tampering with applications or security controls, and support lateral movement deeper into the network. On workstations, it can allow credential theft, endpoint protection bypass, persistence, and broader compromise. The vulnerability is not currently listed in CISA KEV, is not flagged as ransomware-associated, has low EPSS, and has no known public exploit maturity in the provided data, but it affects many supported Windows client and server versions, so broad patch coverage remains important.

How an attack unfolds

An attacker must first obtain the ability to run code locally on an affected Windows system, typically through stolen credentials, malware execution, remote desktop access, exploitation of a separate remote-code-execution issue, or abuse of an existing low-privileged account. The attacker then triggers vulnerable behavior in the Windows Ancillary Function Driver for WinSock by making carefully timed networking-related system calls that interact with afd.sys. Because the bug is a use-after-free race condition, the attacker attempts to cause the kernel to free an object and then reclaim or reshape the freed memory with attacker-controlled data before the driver uses the stale reference. If successful, the attacker can corrupt kernel memory and redirect execution or modify security-relevant kernel structures. The end result is local privilege escalation, commonly to SYSTEM or equivalent kernel-level control. From there, the attacker may disable security tooling, dump credentials, install persistence, access protected data, or move laterally.

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, and Windows Server 2025 variants listed as affected. No exact fixed build numbers were provided in the input, so organizations should rely on Microsoft Security Update Guide, Windows Update, WSUS, Microsoft Configuration Manager, Intune, or equivalent patch-management tooling to deploy the applicable cumulative update for each OS version. Prioritize internet-facing Windows servers, remote-access servers, domain-joined workstations used by administrators, virtualization hosts, jump servers, and systems where untrusted users can execute code. Where immediate patching is not possible, reduce risk by restricting local logon rights, limiting RDP and interactive access, enforcing least privilege, blocking untrusted executable content, hardening endpoint protection, and monitoring for suspicious local privilege escalation behavior. Because the vulnerable component is a core Windows networking driver, disabling the affected driver is generally not a practical mitigation on production systems.

How to confirm the fix worked

Confirm remediation by verifying that each affected Windows host has installed the relevant Microsoft cumulative/security update released for this vulnerability or a later superseding update. Use enterprise patch-management reporting, Windows Update history, vulnerability scanners, and authenticated configuration checks to confirm the OS build and patch level. Validate coverage across both client and server fleets, including older Windows Server and Windows 10 versions that may follow different servicing channels. Run authenticated vulnerability scans after patch deployment and reconcile any remaining detections against Microsoft’s fixed build information. For critical systems, confirm the loaded afd.sys file version and timestamp align with the patched Microsoft release for that OS branch. Also validate that no compensating-control exception has left high-risk systems unpatched, especially administrator workstations, jump hosts, and servers allowing local user sessions.

Typical attack path

1. Gain initial low-privileged access to an affected Windows workstation or server.
2. Confirm the target Windows version is vulnerable and that the attacker can execute local code.
3. Run a local exploit that repeatedly triggers the vulnerable afd.sys code path using crafted WinSock/AFD interactions.
4. Win the race condition by forcing freed kernel memory to be reused in an attacker-influenced way.
5. Achieve kernel memory corruption sufficient to elevate privileges.
6. Spawn or inject into a high-privileged process, commonly resulting in SYSTEM-level execution.
7. Use elevated privileges to disable defenses, harvest credentials, establish persistence, or pivot to other systems.

How to detect it

There are no reliable, vulnerability-specific indicators in the provided data, and local kernel privilege-escalation attempts against afd.sys may leave few direct logs. Detection should focus on behavioral evidence that a low-privileged process unexpectedly gained elevated privileges or performed high-risk actions shortly afterward. Review EDR telemetry, Windows Security logs, Sysmon logs, PowerShell logs, process creation events, service creation events, driver-load telemetry, crash dumps, and endpoint protection alerts. Look for suspicious transitions from ordinary user-context processes to SYSTEM-level command shells, scripting interpreters, credential dumping tools, or security-control tampering. Useful Windows events include process creation telemetry, logon events, privileged service use, scheduled task creation, new service installation, Defender tampering events, and unexpected LSASS access. Kernel exploitation attempts may also cause system instability, so review System event logs, Windows Error Reporting artifacts, and crash dumps for bugchecks around the suspected time window, especially on systems that also show suspicious local process activity. Because this issue requires prior local code execution, correlate suspected exploitation with initial-access indicators such as unusual remote logons, malicious email attachments, webshell activity, browser exploit alerts, or malware detections. No known threat actors, campaigns, KEV status, ransomware usage, or public exploit maturity were provided, so detection should remain behavior-based rather than signature-based.

What your security team should do

• Prioritize deployment of the applicable Microsoft cumulative/security updates across all affected Windows client and server versions.
• Patch high-value systems first, including domain controllers, administrative workstations, jump servers, RDP-accessible systems, application servers, and systems shared by multiple users.
• Use authenticated vulnerability scanning and patch-management telemetry to identify Windows hosts still missing the relevant update.
• Restrict local interactive access, RDP access, and ability to run arbitrary code on servers until patching is complete.
• Review endpoint telemetry for suspicious post-exploitation behavior such as unexpected SYSTEM shells, credential dumping, security tool tampering, and new persistence mechanisms.
• Treat this vulnerability as a privilege-escalation enabler: correlate possible exploitation with earlier initial-access events such as phishing payloads, webshells, remote logons, or malware alerts.
• Ensure endpoint detection and response tooling is active and tamper protection is enabled on Windows endpoints and servers.
• Monitor for abnormal use of networking-related system calls only where advanced endpoint telemetry is available, but rely primarily on behavioral indicators because no stable public exploit indicators are provided.
• Document any systems unable to patch, apply temporary access restrictions, and set a time-bound remediation plan.
• Track Microsoft advisories for fixed build details, exploit status changes, and any later evidence of active exploitation.