On July 9, 2026, Ars Technica reported a flaw in Microsoft Defender that turned the company’s own antivirus into a denial-of-service weapon: a specially crafted file could drive Defender to fill the disk until the machine stopped functioning. It’s a tidy example of a self-defeating security bug — the protector becomes the attacker’s lever. The fix shipped in Microsoft’s monthly update cycle. This is the practical check to confirm you’re on the safe build, plus what to do if you manage a fleet.
What the bug actually did
The defect lived in how Defender processed certain inputs. Instead of safely rejecting a malformed or malicious file, the code path generated unbounded disk activity — a classic resource-exhaustion bug. On a system with limited free space, that alone is enough to take a server or laptop down without any privilege escalation. No code execution, no data theft; just a reliable way to make a machine fall over.
The reason it matters more than a typical DoS is reach. Defender runs on nearly every Windows endpoint by default and scans automatically. A file that triggers the bad path doesn’t need the user to open it — just for Defender to touch it during a routine scan. That makes the attack surface anyone who can get a file onto a disk: email attachments, downloads, mounted shares, even web caches.
Microsoft published the advisory through its Security Update Guide, the canonical place to map a CVE to a fixed build. If you run a fleet, that page — not a news article — is the source of truth for which KB number closes the hole.
Step 1 — Find your Defender platform version
The fix is delivered as a Defender platform and signature update, which on modern Windows is decoupled from the OS build. You check the version directly:
- Open Windows Security (search it from the Start menu).
- Click Virus & threat protection.
- Under Virus & threat protection updates, click Check for updates, then Open next to “Security intelligence version” if present.
- Note the Antivirus anti-malware platform version and the Engine version.
You can also pull it from a terminal, which is the right move at scale:
Get-MpComputerStatus | Select-Object AMProductVersion, AMServiceVersion, AMEngineVersion, AntispywareSignatureVersion
The AMProductVersion is the Defender platform build. Compare it against the “fixed version” listed in the MSRC advisory for this CVE. If your platform version is equal to or newer than the fixed one, you’re patched.
Step 2 — Force the update if you’re behind
Consumer and small-business machines usually pull Defender updates automatically, but “usually” isn’t a control you want to trust for a disk-fill bug. Force it:
Update-MpSignature
Then re-run the Get-MpComputerStatus check from Step 1. On managed devices, push the same via your RMM or Intune policy and verify with the same cmdlet in a compliance script. The platform update can also arrive through Windows Update, so a manual Check for updates in Settings is a reasonable consumer fallback — but the cmdlet is the only one that tells you the actual version you landed on.
Step 3 — Confirm the OS-level fix landed too
Because this class of Defender issue is sometimes addressed partly through the monthly Windows cumulative update, confirm the July 2026 Patch Tuesday rollup is installed:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
Look for the July 2026 cumulative update KB for your Windows build. If it’s missing, install it through Windows Update and reboot — some Defender platform components don’t fully activate until after a restart.
If you manage more than one machine
For a fleet, don’t hand-check. Export the version data and compare it:
Get-MpComputerStatus | Select-Object DeviceName, AMProductVersion, AMEngineVersion |
Export-Csv -Path .\defender-versions.csv -NoTypeInformation
Collect that across endpoints (via Intune, Configuration Manager, or your RMM) and flag any AMProductVersion below the fixed build. Pair it with the MSRC advisory number so the report is auditable. The goal is a single list of “not yet on fixed Defender” machines, not a vibe that “updates are on.”
The habit that prevents the next one
This bug is a reminder that the security agent is just software, and software has bugs — including bugs that make it the weakest link. Two cheap habits close most of the gap:
- Treat Defender version as a metric, not a setting. It should show up in your asset inventory alongside OS build.
- Watch free disk space as a canary. A machine suddenly losing gigabytes with no user action is exactly the signature this bug produces. Alerting on rapid free-space drop would have caught an active exploit before the machine died.
Neither requires new tooling. Both turn “we assume Defender is fine” into “we know Defender is current.” For a flaw whose entire impact is filling the disk, knowing your version — and watching your free space — is the whole defense.
