Defender under fire: Two actively exploited vulnerabilities and the blind spot in the SOC

Microsoft Defender, which runs as a protective layer on millions of Windows systems, has two actively exploited vulnerabilities. One allows for local privilege escalation. CISA has added both to its catalogue of exploited vulnerabilities and set a deadline of 3 June for federal agencies. For DACH-SOCs, the case is less an alarm bell and more a reminder: even the tool that protects can become an attack surface.

Related:Time-to-exploit drops to 24–48 hours  /  Cyber liability in public administration

What is being exploited

What is a privilege-escalation flaw? A vulnerability that permits privilege escalation allows an attacker who already has limited system access to gain higher privileges – up to full control in extreme cases. It is rarely the first step in an attack, but almost always the decisive one.

The more severe of the two flaws is tracked as CVE-2026-41091 and carries a CVSS score of 7.8. It is a link-following error: under certain conditions, Defender follows a tampered shortcut and accesses a file the attacker should not have privileged access to. The result is local privilege escalation. Anyone who already has a foothold – via phishing or another flaw – can leverage it to seize full control.

The second flaw, CVE-2026-45498, is far less dangerous with a CVSS score of 4.0. It enables a Denial of Service, effectively crippling the service. Unpleasant, but not an entry point for takeover. Microsoft states that both vulnerabilities overlap with zero-days disclosed in April – codenamed RedSun and UnDefend.

The key difference is active exploitation. A theoretical flaw is a paper risk. An exploited flaw means code already exists in the wild that triggers it. CISA does not add a vulnerability to its catalogue because it could be dangerous; it does so because it is demonstrably abused. That distinction should drive prioritisation in your own environment. A 7.8-rated flaw without an exploit can wait; the same flaw with active abuse cannot.

Why Automatic Patches Aren’t a Free Pass

Microsoft stresses that both vulnerabilities are being rolled out via Defender’s definition updates. For most systems, no manual intervention is required. That’s the good news. And it’s true. But it’s also where complacency begins.

Automatic updates only work if the mechanism functions. In practice, there are plenty of systems where it doesn’t: air-gapped production networks without internet access, machines locked to specific versions, devices whose update services have been throttled for performance reasons. These are often the most critical systems. Relying on silent updates without verification confuses probability with certainty.

The relevant version numbers are documented. The patch for the privilege escalation is platform version 1.1.26040.8, while the fix for the denial of service is engine version 4.18.26040.7. A quick inventory check reveals whether the entire fleet is protected or if some systems are lagging behind.

The Blind Spot Is Trust

The real lesson isn’t in the two CVE numbers. It’s in the unspoken assumption many organizations make: that the security product itself is secure. Endpoint protection runs with high privileges, deep in the system, with access to nearly everything. That’s precisely what makes it a prime target. A vulnerability in the guardian is far more severe than one in any random application.

This isn’t an argument against Defender or endpoint protection in general. It’s an argument for a clear-eyed inventory. Security software belongs in the same patch and monitoring cycle as any other critical component. It doesn’t deserve blind trust just because its purpose is to protect. Excluding it from vulnerability management creates a blind spot in the most sensitive area.

The CISA deadline of June 3 formally applies only to U.S. federal agencies. But its signal is universal. When an agency with a mandate to act prioritizes a vulnerability, it’s a useful benchmark for any DACH organization. The question isn’t whether your organization *must* meet the deadline. The question is whether it *could*.

What SOCs Should Verify Now

The first step is an inventory check, not a knee-jerk patch. A SOC should know which Defender platform and engine versions are currently deployed. Only this overview reveals whether automatic updates have taken effect across the board or if certain segments are lagging. Without this visibility, patching is done blind – and a gap won’t be noticed until it’s exploited.

The second step involves telemetry. Local privilege escalation leaves traces: unusual access to Defender components, manipulated links, processes running with unexpectedly high privileges. These signals belong in detection rules – not after an incident, but now. An EDR that doesn’t monitor its own integrity is blind at its most critical point.

The third step is organizational. Security software needs a designated owner for its patch status, just like a database server or web gateway. As long as no one is explicitly accountable for ensuring Defender itself is up to date, this task gets lost in the assumption that the system handles it automatically. That assumption is convenient. It’s also why such vulnerabilities persist for weeks.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.