Recently, independent security researchers Chaotic Eclipse Two Windows zero-day vulnerabilities were publicly disclosed in just two weeks. The reason is quite straightforward: “Only through public disclosure will Microsoft face up to the problem. It started on April 7 this year. Chaotic Eclipse publicly disclosed a vulnerability called BlueHammer Windows local privilege escalation zero-day vulnerability, with directly executable proof-of-concept (PoC) code.

Researchers are angry at Microsoft: MSRC will disclose vulnerabilities without responding
The researcher said that he had privately reported the vulnerability through the Microsoft Security Response Center (MSRC) before it was disclosed, but that MSRC’s response process made him “too disgusted” and ultimately decided to make it public on his own. Afterwards, a number of independent security experts confirmed that the vulnerability was genuine. Microsoft also urgently fixed it in the regular update (Patch Tuesday) of the same month and registered it as CVE-2026-33825, the CVSS risk score reaches 7.8 (high risk)。

From a technical point of view, BlueHammer drills TOCTOU (inconsistency between check and use) race condition in Windows Defender Threat Remediation Engine. The attack process is as follows:
- Attacker implants a specially crafted file that triggers Defender detection
- When Defender launched the fix, the attackerBatch opportunity lock (Oplock)Pause Defender’s file operations
- During this operation gap, the attacker creates a NTFS Junction Point, quietly redirecting Defender’s target path from an attacker-controlled staging directory to
C:\Windows\System32 - After the Oplock is released and Defender resumes operation, it will SYSTEM highest authorityWriting files along the redirected path actually overwrites the system executable file for the attacker.
- The next time the system executes the overwritten service, the attacker’s malicious program will be launched with SYSTEM privileges
In short: Defender was overturned by its own repair mechanism and became a tool for privilege escalation.
Round 2: RedSun strikes again, the cloud file API becomes a vulnerability
Microsoft thought that fixing CVE-2026-33825 would calm the storm, but Chaotic Eclipse struck again.
On April 17, he publicly disclosed a second vulnerability:RedSun, it is also a zero-day local privilege escalation, and there is also no official patch yet. This time the attack vector was changed to Windows Cloud Files API。
The attack logic of RedSun is similar to that of BlueHammer, but the entry point is different:
- After the attacker triggers Defender detection, the target file is replaced with aCloud Placeholder
- After Defender detects a file marked in the cloud, it initiates a “rollback” process in an attempt to restore it to its original location.
- The problem is: Defender when rolling backThe legality of the target path is not verified
- The attacker also uses Oplock to pause operations, insert NTFS junction points, and redirect the target path to
C:\Windows\System32 - After Defender is restored, it writes with SYSTEM permissions, and the attacker completes the privilege escalation
Affected platforms include:Windows 10(all supported versions),Windows 11(all supported versions),Windows Server 2016、2019、2022、2025,as well as Microsoft Defender Antivirus before April Patch Tuesday updates。
13 days, three Defender zero-day vulnerabilities: systemic weaknesses emerge
Picus Security, a security agency, pointed out that CVE-2026-33825 is not an isolated incident, but part of a larger problem. In just a short period of April 2026 within 13 days, three zero-day vulnerabilities targeting Windows Defender were exposed one after another:
- BlueHammer: Local privilege escalation through Defender repair logic (Fixed → CVE-2026-33825)
- UnDefend: Destroy Defender’s update mechanism and gradually weaken its protective capabilities
- RedSun: Local privilege escalation through the rollback mechanism of the Cloud Files API (not patched yet)
The combination of three vulnerabilities can form a chain attack: first use BlueHammer or RedSun to obtain the highest privileges, and then use UnDefend to gradually disable Defender to ensure that subsequent actions cannot be detected. This exposes a systemic problem at the Defender architecture level rather than an individual program error.

Has Microsoft’s MSRC “Coordinated Vulnerability Disclosure” mechanism failed?
The behavior of Chaotic Eclipse triggered a discussion on the principle of “responsible disclosure” in the information security circle.
Microsoft’s official position is to follow the “Coordinated Vulnerability Disclosure” (CVD) mechanism, requiring researchers to report privately and wait for official fixes before making it public. But Chaotic Eclipse was obviously extremely disappointed with the speed and attitude of MSRC’s response, and chose to use public disclosure as a means of pressure – and it proved effective: BlueHammer was fixed on the next Patch Tuesday after the disclosure.
This incident has once again sparked controversy: When the vulnerability has not been dealt with after being reported privately, does the researcher have the legitimacy to choose to disclose it publicly? Is Microsoft’s MSRC process designed to protect users, or is it delaying necessary fixes?
Current mitigation recommendations
There is currently no patch for RedSun, and security experts recommend that organizations implement the following measures immediately:
- Apply the April 2026 Patch Tuesday security updates now(Fixable BlueHammer/CVE-2026-33825)
- Continuously monitor the update status of Windows Defender to ensure RedSun patches are applied as soon as they are released
- Enforce the principle of least privilege on local accounts to reduce the likelihood of an attacker gaining an initial foothold.
- Pay close attention to MSRC announcements to confirm the RedSun repair schedule
Source: KOCPC Chinese