Security News Patch for Windows Defender 0-day could allow attackers to fill hard disk

[Brownie2019]

Content source

https://arstechnica.com/security/2026/07/patch-for-windows-defender-0-day-could-allow-attackers-to-fill-hard-disk/

A patch Microsoft released on Wednesday to fix a zero-day vulnerability in its Defender security engine may cause Windows machines to write files large enough to completely consume available disk space, the researcher who discovered the flaw said.

RoguePlanet, tracked as CVE-2026-50656, came to public notice in June when NightmareEclipse, the pseudonymous name used by a researcher, disclosed it along with code for exploiting it. The vulnerability allows remote attackers to gain administrative control of Windows 10 and Windows 11 machines, even when real-time protection has been disabled. Over the past few months, the anonymous researcher has published a handful of other zero-days that have sent Microsoft scrambling to develop patches.

Writing files of unlimited size​

Microsoft said Wednesday that it patched RoguePlanet with an update to the Microsoft Malware Protection Engine, which is used by the Defender antivirus app. The fix will automatically be downloaded and installed without users having to take any action. Wednesday’s update also includes “defense-in-depth updates to help improve security-related features.”

In a post on Thursday, NightmareEclipse said the defense-in-depth additions produce behavior that may allow attackers to exhaust all available space on a hard drive by writing massive amounts of data to it. The newly introduced mitigations create a problem in mpengine.dll, the driver associated with the Microsoft Malware Protection Engine, that in some cases causes it to leak 8 bytes of data when trying to open a file. New functionality in SpyNet, a cloud service that allows Microsoft Security Essentials or Forefront Endpoint Protection to send reports about suspicious software and programs to Microsoft, also plays a role in the potential mass file-writing behavior.

Defender normally places hard limits on how big a file can be written to disk when scanning and quarantining a machine.

“This implementation make [sic] sense, because quarantining a huge file will cause Defender to completely exhaust the available disk space,” the researcher wrote. “I found a small exception to this rule, apparently the spynet functions in mpengine.dll really wants [sic] to keep a local copy of Zone.Identifier ADS file and it does not matter how big this file is, Windows Defender will cache it locally anyways.”

A Zone.Identifier is a hidden metadata file, sometimes called an alternative data stream, that Windows automatically associates with files downloaded from the Internet or received in email or other external sources. The data stream allows Windows to mark the file’s origin and the security zone it should receive.

NightmareEclipse said that a malicious actor could trigger this behavior using Server Message Block, a communications protocol for sharing files over a local Windows network. The researcher explained:

You will need a special setup to exploit this, a custom SMB server that will be handling requests from Windows Defender is needed, the SMB server should serve a malicious file (a good example is mimikatz executable) followed by a massive ADS file (a good example is mimikatz.exe:Zone.Identifier), in the process of replying to the read requests, at some point the SMB server should never respond to the read request but keep the connection alive. This will cause Defender to hang and keep a lock on the offending files that holds the entire disk space.

Obviously this won’t crash the machine but windows won’t behave properly with a full disk, multiple apps and services crash randomly.
Microsoft didn’t immediately answer questions asking if it could confirm the described behavior existed.

NightmareEclipse and Microsoft have been locked in a heated dispute since at least May, when the researcher said Microsoft silently patched a vulnerability the researcher had privately reported. In the weeks following, the researcher released details and exploit code for a handful of vulnerabilities before Microsoft had a chance to patch them. Microsoft, in turn, has publicly railed against the researcher for “not responsibly” disclosing the vulnerabilities and made a veiled reference to the possibility of pursuing legal action. After a public backlash, Microsoft relented and vowed no such legal action would occur.

 

[Bot]

Summary of the technical issue

Based on the article, the flaw described (CVE-2026-50656 / RoguePlanet) is a defense-in-depth side effect introduced by the July patch for mpengine.dll. The core mechanism, as explained by the researcher, is:

• Defender normally caps the size of files it will scan/quarantine, precisely to avoid filling the disk.
• The new SpyNet-related code path apparently bypasses that cap specifically for Zone.Identifier alternate data streams (ADS).
• By serving a file over a rogue SMB share, followed by an oversized Zone.Identifier ADS, and then stalling the read response, an attacker can cause mpengine.dll to hold a lock on disk space indefinitely while attempting to cache that stream.

If accurate, this would be a denial-of-service condition rather than remote code execution on its own; the article notes it does not crash the machine outright, but a full disk can cause cascading failures in unrelated apps and services.

What can be verified vs. what cannot

I have no way to independently confirm the technical details of this claim, whether Microsoft has acknowledged it, or whether the exploit code linked in the thread works as described. The article itself notes Microsoft has not confirmed the behavior. Treat this as an unconfirmed researcher report until either Microsoft or independent analysts corroborate it.

Practical mitigations while this is unresolved

• Restrict inbound and outbound SMB traffic at the network boundary. Since exploitation requires a machine to connect to an attacker-controlled SMB server, blocking unsolicited outbound SMB (TCP 445) to untrusted networks reduces exposure significantly.
• On workstations that never need to reach external SMB shares, firewall rules blocking outbound 445 to the internet are a reasonable general hardening step regardless of this specific issue.
• Monitor free disk space with your existing monitoring tooling; a sudden, rapid drop in free space combined with MsMpEng.exe holding large file handles would be a practical indicator if this is being exploited.
• Keep Defender and Windows fully patched. If Microsoft issues a follow-up fix for this defense-in-depth regression, it would arrive the same way, through normal Windows Update / Defender engine updates.

A caution on the exploit code

The thread links to a public PoC repository. Members should not run this code on production or personal systems outside an isolated test environment. Setting up a rogue SMB server to test this is inherently risky and should only be done in a sandboxed or virtualized lab with no bridged network access.

Bottom line

This is a credible-sounding but currently unconfirmed disk-exhaustion issue tied to Defender's handling of Zone.Identifier ADS over SMB. Until Microsoft confirms or issues a fix, network-level SMB restrictions and disk-space monitoring are the most reasonable precautions available.