CVE-2026-33825: Windows Defender BlueHammer LPE

A time-of-check to time-of-use race in Windows Defender's threat remediation engine lets an unprivileged user turn the antivirus into an exploit primitive — oplock-paused writes redirected via NTFS junctions yield arbitrary file operations as SYSTEM. Leaked by a disgruntled researcher, the public PoC hit CISA KEV within days.

Overview

CVE-2026-33825 — nicknamed "BlueHammer" — is a local privilege escalation vulnerability in the Windows Defender threat remediation engine. The bug lets any local user escalate to SYSTEM on fully patched Windows 10 and Windows 11 by turning the antivirus itself into an exploit primitive: Defender performs privileged file operations during malware cleanup, and a race condition lets the attacker hijack those operations just before they execute.

Unusually, the vulnerability was disclosed as a full weaponised proof-of-concept by a disgruntled security researcher on 7 April 2026 — before Microsoft had shipped a patch. The first in-the-wild exploitation was observed on 10 April, with further waves on 16 April. CISA added it to the Known Exploited Vulnerabilities catalog with a 6 May federal remediation deadline.

BlueHammer is part of a cluster of three Defender exploits disclosed within a 13-day window in April 2026 — alongside "UnDefend" (which disrupts Defender's update mechanism) and "RedSun" (which abuses Defender's handling of cloud-tagged files). All three turn a defensive control into an offensive weapon.

Root Cause: Oplock + Junction = Path Hijack

The flaw is a classic filesystem TOCTOU (Time-Of-Check to Time-Of-Use) race against a privileged service. The vulnerable flow inside MsMpEng.exe (the Defender service running as NT AUTHORITY\SYSTEM) goes roughly:

Defender's real-time protection engine scans a file dropped into a user-writable location.
The scan matches a signature and triggers the remediation subsystem.
Remediation re-opens the file (by path) to quarantine or delete it.
The re-open happens with SYSTEM privileges, and the path is not re-validated against the original file identity before the privileged operation.

The exploit abuses steps 3–4. Between Defender's initial detection and its privileged re-open, the attacker swaps the directory containing the malicious file for an NTFS junction point (reparse point) pointing at a privileged location such as C:\Windows\System32\config. Defender's subsequent file operation then targets the attacker's chosen path instead of the original.

The Oplock Trick

The race window between detection and remediation is tiny on modern systems — far too narrow to win reliably by brute force. BlueHammer solves this with opportunistic locks (oplocks). An oplock is a Windows filesystem mechanism that lets a process be notified when another process wants to access a file it has "locked" — and crucially, it lets the holding process defer that access indefinitely.

The exploit requests a batch oplock on the malicious file. When Defender tries to open the file for remediation, the OS pauses Defender's file access and signals the exploit. The exploit uses that window — which can be arbitrarily long — to delete the original file, replace its parent directory with a junction point targeting a privileged location, and then release the oplock. Defender resumes its operation, but now against the attacker-chosen target.

From Arbitrary Write to SAM Access to SYSTEM

The primitive BlueHammer exposes is an arbitrary file operation as SYSTEM — useful, but not immediately equivalent to a SYSTEM shell. The public PoC converts this primitive into a SYSTEM shell via a well-established chain: obtaining an arbitrary read handle to the Security Account Manager (SAM) database, which stores local account NTLM hashes.

Use the BlueHammer primitive to copy C:\Windows\System32\config\SAM and SYSTEM hives to a user-writable location.
Parse the hives offline with secretsdump.py or mimikatz to dump the local Administrator NTLM hash.
Pass-the-hash against the local system to obtain SYSTEM.

On systems where the local Administrator account is disabled or has no useful privileges, variants of the chain write to C:\Windows\System32\ directly — dropping a DLL that gets loaded by a privileged service on next invocation.

Proof of Concept Sketch

# Pseudocode of the BlueHammer exploit flow (simplified)
# 1. Create attacker-controlled directory with EICAR-like test file
mkdir C:\Users\low\bait
echo <malicious content> > C:\Users\low\bait\trigger.bin

# 2. Request a batch oplock on trigger.bin
#    (via DeviceIoControl with FSCTL_REQUEST_BATCH_OPLOCK)
oplock = request_batch_oplock("C:\Users\low\bait\trigger.bin")

# 3. Wait for Defender to open the file for remediation;
#    the oplock pauses Defender's access and signals us
wait_for_oplock_break(oplock)

# 4. While Defender is paused:
#    delete the original file, replace 'bait' with a junction
delete("C:\Users\low\bait\trigger.bin")
rmdir("C:\Users\low\bait")
create_ntfs_junction(
    "C:\Users\low\bait",
    target="\\RPC Control\\bait")      # object-manager symlink
create_object_symlink(
    "\\RPC Control\\bait\\trigger.bin",
    target="\\??\\C:\\Windows\\System32\\config\\SAM")

# 5. Release the oplock; Defender resumes and now operates
#    against C:\Windows\System32\config\SAM as SYSTEM
release_oplock(oplock)

The two-stage redirect via \RPC Control object-manager symlinks is what gives the exploit fine-grained control over the target — standard NTFS junctions can only redirect directories, not individual files, so the object symlink does the final hop.

Why This Pattern Keeps Coming Back

BlueHammer is the latest entry in a long line of "AV-as-attack-primitive" bugs. The underlying pattern is that privileged userland services (MsMpEng.exe, various EDR agents, backup tools, Windows Installer) perform file operations on user-controlled paths as SYSTEM, and the legacy Win32 filesystem API makes proper path re-validation hard to get right.

Similar historical bugs include CVE-2020-1472 (Zerologon, a separate class but also a privileged service trust failure), CVE-2020-17087 (Windows Kernel Cryptography driver), and a long history of Windows Installer LPE bugs leveraging the same junction + oplock pattern. The systemic problem is architectural — the privileged service needs a way to open files by identity (file ID, not path) or to hold the file handle across the scan/remediate boundary. Microsoft has introduced primitives for both over the years, but legacy code paths continue to use the vulnerable pattern.

Affected Versions

Windows 10 — all supported versions prior to the April 2026 Defender platform update.
Windows 11 — all supported versions prior to the April 2026 Defender platform update.
Windows Server 2019, 2022, 2025 — running Microsoft Defender.

The fix is delivered via the Defender platform update (which auto-updates independently of monthly cumulative patches) in version 4.18.26040.x and later. Check installed platform via Get-MpComputerStatus | Select AMEngineVersion, AMProductVersion.

Remediation

Verify Defender platform is updated. The fix is in the Defender platform, not the monthly cumulative update — ensure the platform update mechanism is not disabled. Minimum patched version: 4.18.26040.x.
On managed fleets, confirm via Get-MpComputerStatus in a management agent sweep. Any host reporting an older platform version is vulnerable.
Restrict local user ability to create junctions where possible — by default, unprivileged users can create junctions in their own profile directories, which is the primary attack vector. The SeCreateSymbolicLinkPrivilege policy can restrict symbolic link creation, but junction points use a separate API path that is not fully covered.
Ensure EDR telemetry is collecting object manager and reparse point creation events — detection opportunities exist at the point of junction creation even before the oplock fires.

Detection

Unprivileged processes creating NTFS junction points (\REPARSE_POINT IRPs) in user-writable directories immediately followed by Defender remediation events on the same path.
Use of the \RPC Control object directory by unprivileged processes — legitimate applications rarely create object-manager symlinks here.
Defender alerts for files that are subsequently "not found" or produce unusual remediation errors — a symptom of the attacker deleting the bait file between detection and remediation.
SAM/SYSTEM hive file access by processes other than lsass.exe or legitimate backup tooling.

The public BlueHammer PoC uses well-known patterns — junction creation under %USERPROFILE%, oplock request on the bait file, \RPC Control\ symlink — that are straightforward to detect once defenders know what to look for. Microsoft's own EDR (Defender for Endpoint) added dedicated detections within 48 hours of the public disclosure.

CVE-2026-33825: Windows Defender "BlueHammer" LPE