Safeguard
Vulnerability Analysis

Microsoft Defender Had Three of Its Own Vulnerabilities Confirmed Exploited

Security software is software first: two local privilege-escalation bugs and a denial-of-service flaw in Microsoft Defender itself were confirmed exploited in the wild.

Safeguard Research Team
4 min read

Microsoft Defender, the security software running on a very large share of Windows endpoints worldwide, had three of its own vulnerabilities confirmed exploited over the past year — a reminder that security software is software first, and inherits every category of risk that implies.

CVE-2026-33825, CVSS 7.8, added 22 April 2026, is insufficient granularity of access control in Defender. CVE-2026-41091, CVSS 7.8, added 20 May 2026, is a link-following vulnerability. CVE-2026-45498, CVSS 4.0, added the same day, is a denial-of-service issue.

Why vulnerabilities in the defensive tool itself matter differently

A vulnerability in a typical business application affects that application's own confidentiality, integrity, or availability. A vulnerability in the endpoint security software running across an entire fleet raises a different question: what happens to an organization's actual security posture, and its confidence in that posture, if the tool responsible for detecting threats can itself be manipulated, degraded, or used as a local privilege-escalation path.

Two of these three CVEs — the access-control granularity issue and the link-following vulnerability — describe local privilege-escalation mechanisms: an attacker with some existing foothold using a flaw in Defender itself to gain more privilege than they should have. That's a particularly uncomfortable category of finding, because it means the security tool, running with elevated privileges by necessity to perform its scanning and remediation functions, becomes part of the attack path rather than a barrier to it.

The denial-of-service entry deserves its own consideration

CVE-2026-45498's lower severity score reflects a denial-of-service classification rather than code execution, but disabling or degrading endpoint security coverage — even temporarily — is a meaningful outcome in its own right for an attacker executing a broader intrusion. A brief window where Defender's protection is degraded or unavailable is exactly the kind of opportunity a sophisticated attacker would use to establish additional persistence or move laterally while detection capability is reduced, which is why a "merely" denial-of-service finding against security software deserves more attention than an equivalent DoS bug in a less security-critical application.

What to check this week

Patch Defender updates with the same urgency applied to any other security-critical software, resisting any instinct to treat updates to the security tool itself as lower priority than updates to the systems it protects.

Review what other endpoint privileges or access an attacker could gain by exploiting the two privilege-escalation CVEs specifically, given that Defender's own elevated operating privileges are precisely what makes a flaw in it valuable to an attacker already present on a system.

Maintain layered detection that doesn't depend entirely on any single security product, including Defender, given that any endpoint security tool can in principle become a target or be temporarily degraded — a defense-in-depth posture is what limits the consequence of exactly this kind of finding.

What this means for third-party endpoint security tools too

Nothing about this pattern is specific to Microsoft — any endpoint security product, from any vendor, runs with elevated privileges by necessity and is therefore an equally plausible home for a local privilege-escalation or access-control bug of its own. Organizations running third-party endpoint detection and response tools alongside or instead of Defender should apply the same scrutiny to that vendor's own advisory history rather than assuming a security product is inherently exempt from carrying vulnerabilities of its own.

A closing note on detection blind spots

Security teams should specifically verify that Defender's own event logging continued functioning correctly during any period a vulnerable, unpatched version was in use — a security tool degraded by its own vulnerability may also produce less reliable evidence of what happened during that same window.

A final consideration on update automation specifically

Because Defender updates are frequently applied through the same automatic mechanism as broader Windows updates, confirm explicitly that endpoint update automation isn't quietly failing on a subset of the fleet — a security tool silently falling behind on its own updates while appearing "managed" is a common and easily overlooked gap.

How Safeguard helps

Safeguard's continuous inventory tracks security software itself with the same rigor applied to every other category of deployed software, recognizing that a security tool's own vulnerabilities are not a lower-priority category of finding simply because of what the tool is meant to do — a lesson this Defender cluster makes directly rather than abstractly.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.