CVE-2026-34340

What it actually does

This is a local privilege-escalation flaw caused by a use-after-free condition in the Windows Projected File System component. A low-privileged, authenticated attacker who can run code on an affected Windows host may be able to trigger unsafe memory reuse in the ProjFS kernel driver/component and obtain elevated privileges, potentially up to NT AUTHORITY\SYSTEM. Successful exploitation can compromise confidentiality, integrity, and availability of the local system, but it requires local access and higher-than-trivial exploitation complexity.

Why it matters to the business

If exploited, an attacker who already has a foothold on a workstation or server could turn limited access into full control of that machine, allowing them to disable security tools, steal credentials, install persistence, tamper with data, or move laterally. The current EPSS score is low and there is no known KEV listing or public exploit maturity reported, so broad exploitation is not indicated, but the affected Windows footprint is large across supported client and server versions and privilege-escalation bugs are commonly chained with phishing, malware, or remote-code-execution vulnerabilities.

How an attack unfolds

An attacker first obtains local authenticated access to an affected Windows system, such as through malware execution, stolen credentials, an exposed interactive session, or exploitation of a separate initial-access vulnerability. The attacker then runs a crafted local program that interacts with Windows Projected File System functionality and attempts to trigger the use-after-free condition, likely relying on precise timing or object-lifetime manipulation. If the memory corruption is controlled successfully, the attacker can alter kernel execution or security context and elevate from a standard user context to highly privileged local access. After elevation, the attacker typically performs post-exploitation actions such as credential access, security-tool tampering, persistence installation, lateral movement preparation, or deployment of additional payloads.

How to fix it

Apply the Microsoft security update that addresses this vulnerability to all affected Windows versions, including Windows 10 1809/21H2/22H2, Windows 11 23H2/24H2/25H2/26H1, Windows Server 2019, Windows Server 2022, Windows Server 2022 23H2, and Windows Server 2025. Because no exact fixed build numbers were provided, use Windows Update, WSUS, Microsoft Configuration Manager, or an equivalent patch-management platform to deploy the relevant cumulative update released on or after the vendor fix date. Prioritize servers, administrator workstations, developer systems, VDI images, jump hosts, and systems where untrusted users can execute code. If immediate patching is not possible, reduce exposure by limiting local logon rights, restricting execution from user-writable paths, enforcing application control, monitoring or disabling unnecessary optional Windows features where operationally feasible, and ensuring EDR protections remain active. Mitigations should be treated as temporary because the underlying issue requires a vendor patch.

How to confirm the fix worked

Confirm remediation by verifying that each affected host is running a Windows cumulative update level that includes the fix for this vulnerability. Use centralized patch inventory, Windows Update history, WSUS/MECM compliance reports, or PowerShell commands such as Get-HotFix and system build queries to confirm update installation. Validate representative endpoints from each affected OS family, including gold images and offline or intermittently connected systems. Where possible, compare the installed ProjFS-related system driver/component versions against the versions delivered by the fixed cumulative update. Also verify that compensating controls are active: non-administrators cannot install or run unauthorized tools, local logon rights are restricted, endpoint protection is enabled, and security telemetry is being collected.

Typical attack path

1. Gain local authenticated code execution on an affected Windows workstation or server.
2. Identify that the host is running a vulnerable Windows build and that Projected File System components are present or reachable.
3. Execute a crafted local exploit that exercises ProjFS operations and triggers the use-after-free condition.
4. Achieve privilege escalation to a highly privileged local context such as NT AUTHORITY\SYSTEM.
5. Disable or evade endpoint protections, collect credentials or tokens, and establish persistence.
6. Use the elevated host as a staging point for lateral movement, data access, or additional payload deployment.

How to detect it

There are no public exploit-specific indicators provided, so detection should focus on behavioral evidence of local privilege escalation and post-exploitation. Review Windows Security logs for unusual logon and privilege events, including Event ID 4624 for unexpected local or remote interactive logons, 4672 for special privileges assigned to a new logon, 4688 for suspicious process creation, and 4673/4674 for sensitive privilege use. In Sysmon or EDR telemetry, look for a low-privileged user process that quickly results in SYSTEM-level command shells, scripting engines, service creation, credential-access tools, or security-tool tampering. Review crash telemetry, Windows Error Reporting, and System logs for bugchecks or application/kernel faults around ProjFS activity, particularly repeated crashes on systems where untrusted users can run code. Investigate unexpected enabling or use of Projected File System functionality, unusual developer or virtualization-root activity on non-developer systems, and any endpoint alerts categorized as kernel exploit, token theft, privilege escalation, suspicious driver interaction, or local exploit. Because successful exploitation may leave few unique artifacts, correlate endpoint telemetry with post-exploitation behaviors such as credential dumping, LSASS access, creation of new local administrators, scheduled tasks, services, firewall changes, Defender exclusions, or lateral-movement tooling.

What your security team should do

• Patch affected Windows client and server systems with the vendor security update; prioritize high-value servers, admin workstations, developer endpoints, VDI hosts, and systems allowing broad local user access.
• Use asset inventory to identify all affected Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 systems, including templates, images, and offline systems.
• Treat this primarily as a post-compromise privilege-escalation risk and review controls that prevent initial local code execution, including phishing defenses, application control, least privilege, and software restriction policies.
• Hunt for signs of recent local privilege escalation, especially low-privileged users spawning SYSTEM-level shells or administrative tools without expected change-control activity.
• Monitor for abnormal crashes, bugchecks, or EDR kernel-exploit alerts involving Windows file-system virtualization or ProjFS components.
• Restrict local administrator rights and interactive logon permissions, particularly on servers and privileged-access workstations.
• Ensure endpoint detection and response tooling is configured to capture process creation, token elevation, driver load, crash, and credential-access telemetry.
• Because EPSS is currently low, schedule remediation through normal accelerated patch cycles unless the host is high value, internet-adjacent through other services, or used by privileged users.