Inside BlueHammer, the Zero-Day That Made Microsoft Defender Promote Attackers to SYSTEM
In April 2026, security researchers disclosed three zero-day vulnerabilities in Microsoft Defender. The vulnerabilities, named BlueHammer (CVE-2026-33825), RedSun, and UnDefend, share a common operational signature: they allow a local unprivileged attacker to escalate to SYSTEM by exploiting Defender’s own threat remediation engine. The antivirus, in performing its defensive function, executes a privileged file operation. The attacker uses that operation against the antivirus.
This article documents the technical mechanism, the timeline, the CISA response, and the cultural and operational implications of a class of vulnerability in which the protector becomes the threat.
The Technical Mechanism
CVE-2026-33825 is a local privilege escalation vulnerability rooted in a time-of-check to time-of-use (TOCTOU) race condition within Windows Defender’s threat remediation engine. The CVSS score is 7.8, classified as High severity.
The mechanism is elegant in the sense in which a well-designed exploit is elegant: it inverts the system’s own structure against itself.
Defender’s real-time protection engine, when it detects a file matching a threat signature, initiates a remediation sequence. The sequence includes inspection, classification, and removal. The removal involves a file operation with elevated privileges, because Defender runs in a SYSTEM-equivalent security context and is permitted to modify or delete files anywhere on the system.
The vulnerability lies in the window between Defender’s check of the target path (to confirm it is the path of the threat file) and Defender’s write operation against that path. In a properly synchronized system, the path between check and use would be locked. In the vulnerable version of Defender, it is not.
The BlueHammer exploit leverages this window with a specific Windows filesystem feature called the batch opportunistic lock (oplock). The exploit, in sequence:
- Places a file in an attacker-controlled directory that matches a Defender threat signature.
- Waits for Defender’s real-time protection to detect the file and initiate remediation.
- Acquires a batch oplock on the file at the precise moment Defender is about to perform its file operation.
- While Defender is paused waiting for the oplock to release, modifies the filesystem to replace the attacker-controlled directory with an NTFS junction point pointing to C:\Windows\System32.
- Releases the oplock.
- Defender, when resumed, performs its file operation, which is now redirected by the junction to a path in the system directory. The operation executes with SYSTEM privileges.
The result is that the attacker, starting from an unprivileged account, has caused Defender to perform a privileged operation against the system directory, on the attacker’s behalf.
This is not a Defender bug in the sense of a coding error to be patched in isolation. It is a class of vulnerability that arises whenever a privileged process performs file operations on attacker-influenced paths without atomic path validation. RedSun and UnDefend are variants of the same class.
Sources: Picus Security, BlueHammer & RedSun: Windows Defender CVE-2026-33825 Zero-day Vulnerability Explained; SecurityWeek; Bleeping Computer; Help Net Security; Penligent; SecurityOnline.
The Timeline
The disclosure of BlueHammer on April 7, 2026 was accompanied by a fully functional proof-of-concept exploit. The PoC was released, in part, as a researcher’s protest against what the researcher characterized as inadequate prior vendor response to private disclosure attempts.
Microsoft addressed CVE-2026-33825 in a Patch Tuesday update following the disclosure. The patch closed the specific BlueHammer variant.
Huntress, the managed detection and response provider, observed BlueHammer exploitation in the wild beginning April 10, 2026, three days after the public disclosure. The exploitation was opportunistic, targeting endpoints that had not yet received the Patch Tuesday update.
On April 16, 2026, the same researcher disclosed RedSun and UnDefend, two additional variants of the underlying vulnerability class. These two variants were, at the time of disclosure, unpatched and remained unpatched as of writing.
CISA added CVE-2026-33825 to its Known Exploited Vulnerabilities Catalog upon confirmation of in-the-wild exploitation. The Catalog entry includes a binding directive for Federal Civilian Executive Branch agencies to patch by May 7, 2026.
The cumulative timeline is: disclosure on April 7, exploitation in the wild on April 10, two additional variants disclosed on April 16, CISA KEV addition shortly thereafter, federal patch deadline May 7. The non-federal organization that follows the typical patch cycle of “test for 30 days, deploy” was, for much of the window between April 7 and May 7, exposed.
The Cultural Genre
There is a long literary tradition of the protector becoming the threat. The Trojan horse, the autoimmune disease, the security guard who steals from the safe, the antivirus that escalates privilege. The figure of the defense that turns against the defended is, in cultural terms, one of the oldest narrative structures.
In the cybersecurity industry, the pattern is not new either. Historic precedents include:
- Symantec / Norton vulnerabilities in the 2010s that allowed local privilege escalation through similar TOCTOU patterns
- The Sophos Central Admin RCE of 2020
- The McAfee LinuxShield vulnerabilities of 2018
- The Trend Micro OfficeScan flaws that allowed bypass and escalation
Each of these, in its moment, generated industry conversation about the security of the security stack. The conversation rarely produced structural change. The vendors patched the specific flaw, the customers redeployed the agent, the pattern continued.
BlueHammer is the 2026 contribution to the genre. It is not the last contribution. It is, however, particularly elegant in its mechanism and particularly visible in its CISA-mandated patching schedule.
The Operational Implication
The operational implication for CISO functions is that the attack surface of the organization includes the security stack itself.
In the typical risk register, Microsoft Defender (and by extension Symantec, CrowdStrike, SentinelOne, Sophos, Trend Micro, McAfee, and the rest of the endpoint protection landscape) appears under the “Controls” heading. The control is the thing that mitigates the risk. The control is, in the risk register’s logic, on the defender’s side.
BlueHammer demonstrates, with operational clarity, that the control can also be on the attacker’s side. Defender mitigated the malware threat. Defender also, via BlueHammer, became a privilege escalation vector. The same software, the same install, the same vendor.
This is not a binary “Defender is bad, do not use it” conclusion. The structural conclusion is that the security stack is part of the attack surface and must be modeled accordingly.
In practical terms:
- The risk register entries for endpoint protection products should include “vulnerabilities in the product itself” as a sub-risk, alongside “failure to detect malware” and “failure to alert”
- The patch management cycle for the security stack should be faster than the patch management cycle for general application software, because exploitation cycles for security stack vulnerabilities are documented to be days, not weeks
- The defense-in-depth principle should apply to the security stack itself: no single vendor’s product should be the only line between an unprivileged user and SYSTEM access
- The threat model for high-value endpoints should explicitly include the possibility that the protector becomes the attacker
The Quis Custodiet Problem
The Latin maxim quis custodiet ipsos custodes translates as “who watches the watchmen”, and originates in Juvenal’s Satires VI. The maxim has, in two millennia, been applied to political, military, legal, and philosophical contexts. The cybersecurity industry is its latest application.
The 2026 version of the maxim is: who watches the antivirus.
The answer, in operational terms, is that the EDR (endpoint detection and response) tooling should, in principle, watch the antivirus. The EDR tooling should detect when the antivirus performs anomalous privileged file operations on attacker-influenced paths. In practice, the EDR tooling is often the same vendor as the antivirus, or has been integrated with the antivirus to the point of sharing process privileges. The watching is, in many deployments, structurally compromised.
The proper response, in security architecture terms, is to ensure that the watching layer and the watched layer are operationally independent. The vendor independence, the process isolation, the privilege separation. None of these are technically novel. All of them are, in 2026, partially implemented in the median enterprise.
BlueHammer makes the structural gap visible. The two unpatched variants, RedSun and UnDefend, ensure that the gap will continue to be visible for the foreseeable future.
The contemporary cyber-defense stack, in 2026, is more capable than at any previous moment in its history. It is also, as BlueHammer demonstrates, structurally subject to the same class of vulnerability as the systems it protects. The protector and the protected share, at the level of code, the same risks.
The CISO who treats the security stack as a fixed asset (purchased, deployed, configured, monitored) is operating on a 2018 mental model. The 2026 mental model treats the security stack as a dynamic threat surface, with patch cycles measured in days, vendor independence measured in process isolation, and risk register entries that include the security stack itself.
This is not, in the strict sense, a new insight. It is a recurring insight that, with each new BlueHammer-class vulnerability, the cybersecurity industry collectively re-discovers.
The custodes, in 2026, have a CVE. The next CVE is, with the operational pattern of the industry, six to eighteen months away.
All my “insane” books on cybersecurity and governance are here 👉 https://www.amazon.it/stores/author/B0FB47T6Q4/allbooks