Microsoft Defender Zero-Days CVE-2026-41091 and CVE-2026-45498: What Health Care IT Should Verify This Week
Microsoft confirmed on May 20 that two Defender vulnerabilities are being actively exploited in the wild. Both were added to CISA's Known Exploited Vulnerabilities (KEV) catalog the same day, with a June 3 remediation deadline for federal agencies under BOD 22-01. Health care organizations are not bound by that deadline, but the urgency is real. One of the two flaws is a local privilege escalation that produces SYSTEM-level access through Microsoft's own antivirus engine.
The good news is that the fix arrives through the same channel as Defender signatures: automatically, in most environments, with no IT intervention. The less convenient news is that "most environments" is not "all environments." If you manage Windows endpoints in a health care setting, you owe yourself a verification pass before you assume the problem is solved.
What Got Patched
CVE-2026-41091 is a local privilege escalation flaw in the Microsoft Malware Protection Engine, the scanning component shared across Microsoft Defender Antivirus, System Center Endpoint Protection, and Security Essentials. CVSS score is 7.8. The root cause is a CWE-59 link-following bug. An authorized local user can plant a symbolic link from a writable location to a sensitive system file, and the Protection Engine follows it while running as SYSTEM. The publicly documented attack chain targets the SAM hive, which is precisely how an attacker with a low-privilege foothold gets to local admin and then to credential theft.
Affected versions: Malware Protection Engine 1.1.26030.3008 and earlier. Fixed in 1.1.26040.8.
CVE-2026-45498 is a denial-of-service vulnerability in the Microsoft Defender Antimalware Platform, the user-mode binaries and kernel drivers that sit on top of Windows. CVSS score is 4.0. Microsoft has not published technical detail beyond confirming the DoS impact and the in-the-wild exploitation. The practical effect is that an attacker can disable or destabilize Defender on a target system. That is not a breach by itself, but it is a useful precursor to one.
Affected versions: Antimalware Platform 4.18.26030.3011 and earlier. Fixed in 4.18.26040.7.
Microsoft credited several researchers for the privilege escalation flaw but none for the DoS bug, which suggests the latter was discovered in the wild rather than reported responsibly.
These two are part of a longer chain of Defender issues the security community has been working through over the past two months. In early April, a researcher using the handle Nightmare Eclipse (also Chaotic Eclipse) published proof-of-concept exploits for three Defender flaws named BlueHammer, RedSun, and UnDefend. BlueHammer was patched in April as CVE-2026-33825 and added to KEV shortly after. Huntress has reported observing the original PoCs being used by attackers since then. These two CVEs appear to continue activity in that same area of Defender.
Why Health Care IT Should Care
Defender is the default endpoint protection on nearly every Windows installation in a health care environment. Even where organizations have layered third-party EDR products on top, the Defender stack is usually still running underneath. The affected components are present whether you actively manage them or not. The exception is environments where Defender is explicitly disabled by policy, in which case the binaries remain on disk but are not exploitable. Vulnerability scanners will still flag those systems, and that is expected behavior, not a bug to chase.
The HIPAA Security Rule does not name specific products, but it does require covered entities and business associates to protect against any reasonably anticipated threats or hazards to the security or integrity of electronic protected health information under 45 CFR 164.306(a)(2) and to conduct ongoing risk analysis under 45 CFR 164.308(a)(1)(ii)(A). An actively exploited zero-day in the default Windows antivirus, with proof-of-concept code in circulation and confirmed in-the-wild use, fits the definition of a reasonably anticipated threat. The risk analysis documentation should reflect it, and so should the risk management activities that flow from 45 CFR 164.308(a)(1)(ii)(B), which requires implementation of security measures sufficient to reduce risks to a reasonable and appropriate level.
The downstream impact is more specific. CVE-2026-41091 grants SYSTEM privileges on the affected endpoint. Once an attacker has SYSTEM, they have access to the local SAM hive, the ability to use credential-dumping tooling, and the keys to lateral movement across a Windows environment. In a health care setting, that lateral path typically leads to whatever workstation or server runs your EHR client, your imaging viewer, your medication dispensing interface, or your back-office databases. These systems fall under the technical safeguards in 45 CFR 164.312, including access control under 164.312(a) and audit controls under 164.312(b). A SYSTEM-level compromise undermines both.
CVE-2026-45498 is more limited in scope but worth thinking through. If an attacker can silence Defender on a clinical workstation before deploying ransomware or exfiltration tooling, the window for detection narrows considerably. For organizations that rely on Defender or Defender for Endpoint as their primary detection layer, this matters more than the CVSS score suggests.
What to Verify Today
For most health care environments, the patches deploy automatically. Defender does not wait for Patch Tuesday. Engine, platform, and signature updates flow continuously through the Defender update channel, often arriving within hours of release. Microsoft has stated that no manual action is required in default configurations. That is true. It is also not the whole story. The configurations health care IT teams actually run are not always default.
The verification path on a single workstation:
- Open Windows Security from the system tray or Start menu.
- Go to Virus and threat protection, then Protection updates, then Check for updates.
- After updates complete, click the gear icon and select About.
- Confirm Antimalware Client Version is 4.18.26040.7 or later, and Engine Version is 1.1.26040.8 or later.
For a fleet, PowerShell is the better approach. The following returns the relevant versions on the local machine:
Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, AntivirusSignatureVersion
Wrapped into a Configuration Manager Compliance Baseline, script-based detection works well. A simple detection that returns Compliant or Non-Compliant against the patched versions:
$Status = Get-MpComputerStatus
$EngineRequired = [version]"1.1.26040.8"
$PlatformRequired = [version]"4.18.26040.7"
$EngineCurrent = [version]$Status.AMEngineVersion
$PlatformCurrent = [version]$Status.AMProductVersion
If (($EngineCurrent -ge $EngineRequired) -and ($PlatformCurrent -ge $PlatformRequired)) {
Write-Output "Compliant"
}
Else {
Write-Output "Non-Compliant"
}
If your endpoints pull updates from a WSUS instance or a Configuration Manager Software Update Point rather than directly from Microsoft Update, there is one configuration item worth confirming explicitly. Defender content only reaches your clients if the upstream synchronization is configured to include it. The Products that need to be selected are "Microsoft Defender Antivirus" and, where applicable, "Microsoft Defender for Endpoint." The Classification must include Definition Updates. Sites that built their SUP configuration around server and client cumulative updates without thinking about endpoint protection may be filtering Defender content out unintentionally. This is the most common reason a Defender-managed fleet ends up out of sync with the rest of the world.
For environments running pure Group Policy without Configuration Manager or Intune, the relevant settings live under Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Signature Updates. The default is automatic, and the default is generally working. The point of the verification pass is to confirm that, not to take it on faith.
If you find a non-compliant endpoint that has not pulled the update through normal channels, the manual remediation is:
Update-MpSignature -UpdateSource MicrosoftUpdateServer
For systems where Defender has been intentionally disabled because a third-party AV product is in place, the binaries remain on disk in the original vulnerable version. This is documented Microsoft behavior. Scanners will flag the host. The remediation is to update the Defender components anyway, which can be done through the standard update path even when the service is disabled. Leaving vulnerable binaries on disk while the service is off does not create direct exploitability, but it complicates scanner reports and creates ambiguity in audit findings. Update the components.
Longer-Term Considerations
Endpoint protection engine and platform updates are not the same thing as signature definition updates, and they should not be treated as routine background noise on the operations side. They patch code, not signatures. When a Defender engine update lands, it deserves the same operational attention that any other kernel-mode or SYSTEM-context component update would get.
A few practical adjustments for the next ninety days:
If your written patch management procedures describe "monthly Windows Update via Configuration Manager" and nothing else, the procedure as written does not cover what just happened this week. Adjust the language so that the Defender update stream is named explicitly, with its own verification expectation. This also makes the procedure defensible against an OCR audit inquiry about how the organization responds to actively exploited vulnerabilities. These are exactly the kinds of operational details that 45 CFR 164.308(a)(1) expects covered entities to keep current as part of the Security Management Process standard.
For endpoints where Defender is disabled by policy, document the rationale and confirm the replacement security control. This is the kind of decision that should appear in your risk analysis and security incident procedures rather than being inherited from a long-departed admin.
If you rely on Defender for Endpoint as your detection layer, validate that your alerting rules cover unusual Defender service state changes and engine version regressions. A DoS exploit that silences Defender should not look the same as Defender being silent because nothing was happening.
Finally, revisit least privilege. CVE-2026-41091 requires an authorized local account to exploit. Standard users who have no business holding local administrator rights, and who do anyway because of a vendor application that demanded it three years ago, are part of the attack surface for this CVE and an entire class of others. Removing unnecessary local admin is the cheapest and most durable mitigation available, well beyond this week's news.
Bottom Line
The patches are deploying automatically in most environments. The verification work is what matters. A spot check on a representative set of endpoints, a Compliance Baseline run across the fleet, and a quick read of your patch management documentation against what actually happened this week are the right activities for the rest of this month. The June 3 federal deadline is a useful anchor even for organizations not subject to BOD 22-01.
Defender is the default. Defender is doing its job. What this week's CVEs make clear is that the default deserves the same operational discipline as everything else in the patch cycle.
Sources
- Microsoft Security Response Center, CVE-2026-41091 Microsoft Defender Elevation of Privilege Vulnerability
- Microsoft Security Response Center, CVE-2026-45498 Microsoft Defender Denial of Service Vulnerability
- CISA, Known Exploited Vulnerabilities Catalog, additions of May 20, 2026
- BleepingComputer, "Microsoft warns of new Defender zero-days exploited in attacks," May 21, 2026
- Help Net Security, "Microsoft Defender vulnerabilities exploited in the wild (CVE-2026-41091, CVE-2026-45498)," May 21, 2026
- The Hacker News, "Microsoft Warns of Two Actively Exploited Defender Vulnerabilities," May 21, 2026
- 45 CFR Part 164, eCFR current text
Compliance Disclaimer
This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.
