CVE-2026-49167

What it actually does

This is a local Windows Kernel use-after-free vulnerability. An authenticated local attacker with low privileges can trigger incorrect kernel object lifetime handling so that memory is reused after it has been freed. Successful exploitation can corrupt kernel memory and, according to the assigned impact, is most relevant for causing a denial-of-service or system crash. Because exploitation occurs in kernel context, any reliable exploit would interact with privileged OS memory, but the published CVSS vector indicates no confidentiality or integrity impact and high attack complexity.

Why it matters to the business

A successful attack can crash affected Windows workstations or servers, disrupting user productivity, hosted applications, and operational availability. The issue requires local authenticated access and has no known exploitation or CISA KEV listing, so immediate internet-scale risk is lower than for remotely exploitable flaws; however, it still matters on multi-user systems, shared servers, VDI environments, and endpoints where an attacker has already obtained a foothold. Affected platforms include multiple supported Windows 10, Windows 11, and Windows Server releases, so the potential operational footprint can be broad.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user on an affected Windows system, such as through stolen credentials, malware execution, or access to a shared interactive environment. The attacker then runs a purpose-built program that exercises the vulnerable Windows Kernel code path and manipulates object allocation and deallocation timing to create a use-after-free condition. If the race or memory-layout requirements are met, the kernel dereferences freed memory that may have been reallocated or corrupted by the attacker-controlled process. Based on the published impact, the expected practical outcome is a kernel fault or bugcheck that crashes the host, causing denial of service. No public exploit maturity or known active exploitation has been reported in the provided data.

How to fix it

Apply the Microsoft security update that addresses CVE-2026-49167 for the affected Windows release as soon as it is available through Windows Update, Microsoft Update Catalog, WSUS, Microsoft Configuration Manager, or the relevant enterprise patch-management system. Prioritize shared servers, remote desktop hosts, VDI pools, jump boxes, developer workstations, and systems where untrusted or many users can execute local code. No exact fixed build numbers were provided in the input, so validate the applicable KB and OS build against Microsoft’s official Security Update Guide for Windows 10 1809, 21H2, 22H2; Windows 11 24H2, 25H2, 26H1; Windows Server 2019, 2022, and 2025. Where immediate patching is not possible, reduce exposure by restricting interactive logon rights, limiting local code execution, enforcing least privilege, using application control, isolating high-risk multi-user systems, and monitoring for unusual crash patterns.

How to confirm the fix worked

Confirm that each affected Windows host has installed the Microsoft security update or cumulative update that remediates this vulnerability for its specific OS version and architecture. Use enterprise patch inventory, Windows Update history, installed hotfix queries, and OS build verification to compare systems against Microsoft’s Security Update Guide. Validate that reboot requirements have been completed, because kernel fixes typically do not take effect until after restart. For exposure checks, inventory all Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 systems and identify those missing the relevant cumulative update. For functional validation, confirm normal system stability after patching and verify that previously vulnerable builds are no longer present in vulnerability-management scan results.

Typical attack path

1. Gain authenticated local access to an affected Windows workstation or server.
2. Stage or compile a local proof-of-concept program targeting the vulnerable kernel code path.
3. Run the program under a low-privileged user context.
4. Manipulate timing, object lifetime, and memory allocation patterns to trigger use-after-free behavior in the kernel.
5. Cause kernel memory corruption that results in a system crash or denial of service.
6. Optionally repeat the crash on reboot or across additional accessible systems to disrupt operations.

How to detect it

Look for evidence of local execution followed by kernel crashes or repeated unexpected reboots. Relevant log sources include Windows System event logs, Application event logs, Windows Error Reporting, crash dump directories, EDR process telemetry, command-line execution logs, file-creation telemetry, and authentication logs showing recent local or remote interactive logons before a crash. Hunt for repeated bugcheck events, Event ID 1001 from BugCheck or Windows Error Reporting, Event ID 41 from Kernel-Power, Event ID 6008 for unexpected shutdowns, and suspicious newly created executables run shortly before the crash. Correlate crashes with low-privileged user sessions, unusual process launches from temporary or user-writable directories, and repeated attempts across multiple hosts. Because no public exploit indicators, threat actors, or exploit filenames were provided, detection should focus on behavioral evidence rather than fixed signatures.

• Event ID 1001
• BugCheck
• Windows Error Reporting
• Event ID 41
• Kernel-Power
• Event ID 6008
• The previous system shutdown was unexpected
• C:\Windows\MEMORY.DMP
• C:\Windows\Minidump\
• C:\ProgramData\Microsoft\Windows\WER\ReportArchive\
• C:\ProgramData\Microsoft\Windows\WER\ReportQueue\
• %TEMP%\*.exe
• \AppData\Local\Temp\*.exe

What your security team should do

• Inventory affected Windows client and server versions and map them to the applicable Microsoft cumulative update or KB.
• Patch multi-user, business-critical, internet-adjacent administration, VDI, and remote desktop systems first, then complete rollout to the remaining endpoint and server fleet.
• Require reboots after patch installation and track systems that are pending restart.
• Restrict local interactive access and code execution on systems that cannot be patched immediately.
• Monitor Windows crash, bugcheck, and unexpected reboot telemetry for clusters that may indicate attempted exploitation or reliability testing.
• Use EDR to alert on suspicious local exploit behavior, including unknown executables repeatedly causing system crashes or interacting heavily with kernel-facing device interfaces.
• Because the vulnerability is not listed in KEV, has low EPSS, and has no reported exploit maturity in the provided data, treat it as important but prioritize after actively exploited remote-code-execution and privilege-escalation issues unless the system is high availability or shared by many users.