RedSun and UnDefend – The Defender Zero-Days Under Active Exploit
Active Exploitation – Immediate Verification Required
CISA added both CVEs to the Known Exploited Vulnerabilities (KEV) catalog. The federal remediation deadline was June 3, 2026.
If you manage Microsoft Defender endpoints and haven’t verified fleet versions yet – skip to the Verification Playbook section now and come back. Safe versions: Engine 1.1.26040.8 (CVE-2026-41091 / RedSun) Platform 4.18.26040.7 (CVE-2026-45498 / UnDefend)
The Incident That Made This Urgent
In mid-April 2026 before Microsoft had shipped a single patch attackers were already using a two-CVE chain against live Windows environments. Huntress incident responders documented the first confirmed real-world case: an attacker entered the network through a compromised FortiGate VPN account, then ran standard post-access reconnaissance commands to map their position.
Then, before escalating, they deployed the exploit pair in sequence. Here’s what made it genuinely dangerous: the targeted device showed as active and healthy in Microsoft Defender’s portal throughout the entire attack. Real-time protection appeared on. The engine appeared current. Windows Security showed no warnings. The Intune compliance report showed the device as protected.
That was by design. That’s exactly what UnDefend does.
The Two CVEs – At a Glance
| CVE-2026-41091 | CVE-2026-45498 | |
| Alias | RedSun | UnDefend |
| Component | Malware Protection Engine (mpengine.dll) | Defender Antimalware Platform |
| CVSS Score | 7.8 – HIGH | 4.0 – Medium |
| Impact | Privilege escalation to SYSTEM | Silently blocks definition updates – device goes blind |
| Privileges Needed | Low – any local foothold | None – standard user sufficient |
| Patched In | Engine 1.1.26040.8 | Platform 4.18.26040.7 |
| CISA KEV | YES – June 3, 2026 federal deadline | YES – June 3, 2026 federal deadline |
| Active Exploit | Confirmed – Huntress IR case (mid-April 2026) | Confirmed – CISA + Microsoft advisory |
How the Exploit Chain Works
The sophistication of this pair isn’t in either CVE individually, it’s in the sequencing. UnDefend creates the blind spot first. RedSun then exploits it.
Step 1 – UnDefend Silences the Sensor (CVE-2026-45498)
UnDefend carries a CVSS score of 4.0. That number will lead some teams to deprioritise it. That would be a mistake.
The vulnerability triggers a denial-of-service condition in the Defender Antimalware Platform. A standard user account – no administrative privileges required, can exploit this to silently block Defender from receiving definition updates.
The engine keeps running. The real-time protection toggle stays green. Windows Security shows no alerts. The Intune Antivirus Agent Status report shows the device as protected.
But the definition feed is dead. Any malware, exploit code, or post-exploitation tooling written after the last successful update is now completely invisible to the engine. The sensor is running blind while reporting full health.
Why the CVSS Score Is Misleading Here
A 4.0 CVSS reflects impact in isolation – UnDefend doesn’t escalate privileges or exfiltrate data on its own. But in this chain, it’s not trying to. Its only job is to ensure the weapon that follows (RedSun) isn’t detected. Always evaluate chained vulnerabilities as a system, not as isolated scores.
Step 2 – RedSun Escalates to SYSTEM (CVE-2026-41091)
With the definition feed cut, the attacker deploys RedSun. This is a link-following vulnerability in mpengine.dll, the core of the Malware Protection Engine that handles file scanning, detection, and cleaning.
When Defender scans a file, it resolves symbolic links and directory junctions as part of that operation. The flaw (CWE-59 – Improper Link Resolution Before File Access) means the engine doesn’t validate the final target of those link resolutions before performing the file operation.
An attacker plants a crafted symbolic link in a location the engine will access during a scan. Because mpengine.dll performs that write operation under elevated service permissions, an attacker can redirect those writes into protected system directories – directories that normally require SYSTEM-level access to touch.
The result: privilege escalation from any low-privilege local foothold to SYSTEM – the highest privilege level Windows grants.
Step 3 – Post-Exploitation
Once SYSTEM-level access is in hand, the playbook is standard. In the confirmed Huntress case, post-exploitation focused on credential harvesting the earlier cmdkey /list reconnaissance had already mapped the credential store, followed by lateral movement preparation. Ransomware deployment was the presumed objective.
Why Security Software Is the Highest-Value Target Now
Compromising the security layer doesn’t just compromise one application, it disables the entire detection layer. Attackers don’t need to be stealthy if nothing is watching. This is why endpoint security tooling has become the primary target for sophisticated threat actors, and why CVEs in Defender carry outsized real-world risk relative to their CVSS scores.
Who Released These
Both vulnerabilities were publicly disclosed on GitHub in April 2026 by a researcher known as “Nightmare Eclipse” (also referenced as Chaotic Eclipse). The researcher published proof-of-concept code for both CVEs before Microsoft had shipped any patch. Their GitHub account was subsequently taken down; they have since moved to GitLab. The PoC code did not disappear, it migrated.
Two critical points for every enterprise security team:
- Exploit code was publicly available for six weeks before Microsoft patched. Huntress documented active exploitation within days of the public disclosure. The window between “PoC published” and “being used in live attacks” is getting shorter with every major Defender CVE.
- Microsoft has not formally confirmed the nicknames RedSun or UnDefend in their advisories but the vulnerability descriptions align directly with the published PoC. The names are widely used in threat intel feeds and will appear in your SIEM alerts.
Also in This Patch Batch – Don’t Miss CVE-2026-45584
The same engine update (1.1.26040.8) that patches RedSun also addresses CVE-2026-45584, a heap-based buffer overflow in mpengine.dll with a CVSS score of 8.1.
This one allows remote code execution without requiring user interaction. No active exploitation has been confirmed yet, but at CVSS 8.1 it’s technically the most severe vulnerability in this patch batch. If you’re pushing engine updates for RedSun and UnDefend and you should be CVE-2026-45584 is resolved by the same build. There is no reason to be selectively patched against two of these three.
Why Auto-Update Is Not Enough
The standard enterprise response to a Defender CVE disclosure is: “auto-update handles this.” Under ideal conditions, that’s true. But there are several failure modes worth understanding and one of them is structural to this specific attack:
- UnDefend breaks the auto-update channel deliberately. If an attacker deploys UnDefend before you’ve detected and evicted them, the definition feed on that device is already dead. The device will report as healthy. Auto-update cannot fix a device where the update mechanism has been intentionally disabled.
- Remote workers and devices that are regularly off the corporate network may have stale engine versions. Auto-update requires connectivity to Microsoft Update endpoints. Engine builds don’t come via WNS push the device needs to reach Microsoft.
- Co-managed environments where Configuration Manager is handling Windows Update policy may not receive the Defender engine update through the same channel as Intune-only devices. Verify your update ring configuration covers engine and platform updates.
- Devices that haven’t recently checked in show their last-known state in Intune compliance reporting, not their current state. A device offline for a week could be running any engine version and you won’t know until it phones home.
The only reliable answer is active verification across the fleet. Here is how to do it.
Verification Playbook: Find the Laggards
Three methods – I recommend running all three, as they cross-validate each other. The Intune report gets you a fleet-level snapshot in minutes. Advanced Hunting uses Defender’s own vulnerability intelligence. PowerShell is your single-device triage tool.
Method 1 – Intune Antivirus Agent Status Report
The fastest fleet-level view. No query language required.
| 1 | Sign in to intune.microsoft.com |
| 2 | Navigate to Reports > Microsoft Defender Antivirus |
| 3 | Select the Reports tab, then click Antivirus agent status |
| 4 | Click Generate report (allow 30–60 seconds) |
| 5 | Export to CSV – sort by Engine version ascending to surface the laggards |
Look for devices where Engine Version is below 1.1.26040.8 or Platform Version is below 4.18.26040.7. The report also surfaces real-time protection state, signature freshness, and Tamper Protection status – check all of these while you have the data in front of you.
Pro Tip: Filter by ‘Signature out of date = True’ first
If any device shows signatures as out of date, that’s your highest-priority target. A device that has been successfully hit with UnDefend will show up here first, the definition feed starves before the engine version shows as outdated.
Method 2 – Advanced Hunting in Defender XDR
Three KQL queries. Run them in Defender XDR under Hunting > Advanced Hunting. Requires Microsoft Defender for Endpoint Plan 2 or Microsoft 365 Defender licensing.
Query 1 – Devices Exposed by CVE (Authoritative)
This query uses Threat & Vulnerability Management data tables, which are populated by Defender’s built-in vulnerability scanner. If these CVEs surface for a device here, it means Defender’s own assessment engine has confirmed exposure. This is your most authoritative source.
// KQL — Defender XDR Advanced Hunting
// Query 1: Devices still exposed to RedSun (CVE-2026-41091) or UnDefend (CVE-2026-45498)
// Uses Defender TVM data — most authoritative source for confirmed exposure
DeviceTvmSoftwareVulnerabilities
| where CveId in ("CVE-2026-41091", "CVE-2026-45498")
| summarize
CVEs = make_set(CveId),
CVECount = dcount(CveId),
MaxSeverity = max(VulnerabilitySeverityLevel)
by DeviceName, OSPlatform
| extend ChainExposure = iff(CVECount == 2,
"FULL CHAIN — Prioritise Immediately",
"Partial Exposure")
| order by CVECount desc, DeviceName asc
A device returning CVECount = 2 has confirmed exposure to the complete exploit chain. Treat these as priority-one targets. Any result here at all warrants immediate remediation action.
Query 2 – Fleet Version Check Against Safe Thresholds
Direct version comparison against the patched thresholds using the DeviceInfo table. Useful for catching devices that the TVM scanner hasn’t assessed yet due to check-in timing, and for getting the exact version strings to confirm remediation.
// KQL — Defender XDR Advanced Hunting
// Query 2: Fleet-wide Defender engine and platform version check
// Surfaces devices running below the patched version thresholds
DeviceInfo
| where Timestamp > ago(1d)
| summarize arg_max(Timestamp, *) by DeviceId
| where isnotempty(AntivirusEngineVersion)
| extend
EngineStatus = iff(AntivirusEngineVersion < "1.1.26040.8",
"OUTDATED", "OK"),
PlatformStatus = iff(AntivirusPlatformVersion < "4.18.26040.7",
"OUTDATED", "OK")
| where EngineStatus == "OUTDATED" or PlatformStatus == "OUTDATED"
| project
DeviceName,
AntivirusEngineVersion, EngineStatus,
AntivirusPlatformVersion, PlatformStatus,
OSPlatform,
LastSeen = Timestamp
| order by DeviceName asc
Query 3 – Behavioural Hunt: Anomalous SYSTEM Processes via MsMpEng
This is your post-exploitation hunt. If RedSun has been used on a device, the symptom is unexpected SYSTEM-level child processes initiated in the context of MsMpEng.exe, the engine process. This query flags processes that shouldn’t be there.
// KQL — Defender XDR Advanced Hunting
// Query 3: Post-exploit behavioural hunt — SYSTEM processes via Defender engine context
// RedSun escalates through mpengine.dll; look for unexpected SYSTEM-level children
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName has_any ("MsMpEng.exe", "mpengine")
| where AccountName =~ "SYSTEM"
| where FileName !in~ (
"MsMpEng.exe", "NisSrv.exe", "MpSigStub.exe",
"MpCopyAccelerator.exe", "MpDefenderCoreService.exe",
"SecurityHealthService.exe", "WerFault.exe"
)
| project
Timestamp,
DeviceName,
FileName,
ProcessCommandLine,
AccountName,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp desc
Any results from Query 3 warrant immediate investigation. An empty result set does not mean the device is clean, it means no behavioural trail is visible in the last seven days. Combine this with the version queries for a complete picture.
Method 3 – PowerShell: Single Device Verification
For individual device triage or confirming that a sync has successfully applied the update. Run in an elevated PowerShell session on the device, or deploy via an Intune remediations script.
// PowerShell — Run on Device or via Intune Remediation
# Defender patch verification — CVE-2026-41091 (RedSun) & CVE-2026-45498 (UnDefend)
# Safe thresholds: Engine >= 1.1.26040.8 | Platform >= 4.18.26040.7
$status = Get-MpComputerStatus
$engineOK = [Version]$status.AMEngineVersion -ge [Version]'1.1.26040.8'
$platformOK = [Version]$status.AMProductVersion -ge [Version]'4.18.26040.7'
[PSCustomObject]@{
EngineVersion = $status.AMEngineVersion
EngineStatus = if ($engineOK) { 'SAFE' } else { 'OUTDATED — PATCH REQUIRED' }
PlatformVersion = $status.AMProductVersion
PlatformStatus = if ($platformOK) { 'SAFE' } else { 'OUTDATED — PATCH REQUIRED' }
RealTimeEnabled = $status.RealTimeProtectionEnabled
TamperProtected = $status.IsTamperProtected
SignatureAge = "$($status.AntivirusSignatureAge) day(s)"
What To Do With the Devices You Find
If your queries or the Intune report surfaces devices running outdated engine or platform versions, work through these steps:
- Trigger an Intune sync for all outdated devices. In the Intune admin centre, navigate to Devices > select the device > Sync. For bulk remediation, use the Intune PowerShell SDK or Microsoft Graph API to iterate the device list and push syncs.
- Verify Tamper Protection is enabled fleet-wide. Tamper Protection makes UnDefend significantly harder to execute an unprivileged user cannot stop or degrade Defender services when it is active. Check the Tamper Protection column in your Antivirus Agent Status report. It should be Enabled across every managed device.
- Treat any Query 3 results as a potential compromise, not just an outdated version. If you see anomalous SYSTEM-level processes alongside an outdated engine version, isolate the device in Defender XDR first (Devices > Isolate device), then investigate. Do not rely on a patch to remediate a potentially compromised endpoint.
- Check definition update sources for devices that consistently stay outdated. Verify Microsoft Update endpoints are reachable. For co-managed environments, confirm the engine update has been approved and distributed in your SCCM/WSUS update ring.
- Add engine and platform version checks to your ongoing fleet hygiene. Defender engine versions update frequently. The Antivirus Agent Status report should be a standing item in your regular compliance review, not only a response to CVE disclosures.
The Scudra Takeaway
Don’t Just Patch. Verify.
The real lesson from RedSun and UnDefend isn’t about zero-days – it’s about detection confidence.
Most organisations assume that if Defender shows as healthy, the device is protected. UnDefend invalidates that assumption in the most practical way possible: it targets the update mechanism rather than the engine itself, so everything looks fine from the outside while the sensor quietly goes blind. Auto-update is not a substitute for fleet-wide verification. The Intune Antivirus Agent Status report takes five minutes to generate. Advanced Hunting Query 1 takes two. Run them today and then build them into your regular cadence.
References
CVE-2026-41091 (RedSun) – Microsoft Security Response Center – Malware Protection Engine elevation of privilege
CVE-2026-45498 (UnDefend) – Microsoft Security Response Center – Defender Antimalware Platform denial-of-service
CVE-2026-45584 – Microsoft Security Response Center – mpengine.dll heap-based buffer overflow, CVSS 8.1 (same patch batch)
CISA Known Exploited Vulnerabilities Catalog – federal remediation deadline June 3, 2026
Huntress Incident Response – first confirmed real-world exploit chain documented mid-April 2026
Nightmare Eclipse / Chaotic Eclipse – original PoC researcher, GitHub account removed, migrated to GitLab
Intune Antivirus Agent Status Report – Reports > Microsoft Defender Antivirus > Reports tab > Antivirus agent status