7 min read<\/p>\n
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.<\/strong><\/p>\n Key Takeaways<\/p>\n Related:<\/span>Time-to-exploit drops to 24\u201348 hours<\/a> \/<\/span> Cyber liability in public administration<\/a><\/p>\n What is a privilege-escalation flaw?<\/strong> A vulnerability that permits privilege escalation allows an attacker who already has limited system access to gain higher privileges \u2013 up to full control in extreme cases. It is rarely the first step in an attack, but almost always the decisive one.<\/p>\n 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 \u2013 via phishing or another flaw \u2013 can leverage it to seize full control.<\/p>\n 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 \u2013 codenamed RedSun and UnDefend.<\/p>\n 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.<\/p>\n Microsoft stresses that both vulnerabilities are being rolled out via Defender\u2019s definition updates. For most systems, no manual intervention is required. That\u2019s the good news. And it\u2019s true. But it\u2019s also where complacency begins.<\/p>\n Automatic updates only work if the mechanism functions. In practice, there are plenty of systems where it doesn\u2019t: 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.<\/p>\n 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.<\/p>\n False Sense of Security<\/p>\n Reliable Approach<\/p>\n The real lesson isn\u2019t in the two CVE numbers. It\u2019s 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\u2019s precisely what makes it a prime target. A vulnerability in the guardian is far more severe than one in any random application.<\/p>\n This isn\u2019t an argument against Defender or endpoint protection in general. It\u2019s an argument for a clear-eyed inventory. Security software belongs in the same patch and monitoring cycle as any other critical component. It doesn\u2019t deserve blind trust just because its purpose is to protect. Excluding it from vulnerability management creates a blind spot in the most sensitive area.<\/p>\n 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\u2019s a useful benchmark for any DACH organization. The question isn\u2019t whether your organization *must* meet the deadline. The question is whether it *could*.<\/p>\n 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 \u2013 and a gap won\u2019t be noticed until it\u2019s exploited.<\/p>\n 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 \u2013 not after an incident, but now. An EDR that doesn\u2019t monitor its own integrity is blind at its most critical point.<\/p>\n 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\u2019s also why such vulnerabilities persist for weeks.<\/p>\n Every question is locked. A tap unlocks the answer.<\/p>\n In most cases, no. Microsoft distributes fixes via definition updates. However, you should only rely on this after verifying the actual version status, especially on systems without continuous internet connectivity.<\/p>\n<\/details>\n With a CVSS score of 7.8, it is classified as high, but not critical. It does not allow initial infection, but rather the escalation of existing privileges. In a multi-stage attack chain, this is often the decisive step toward full system takeover.<\/p>\n<\/details>\n The privilege escalation is fixed with platform version 1.1.26040.8, and the Denial of Service with engine version 4.18.26040.7. Comparing these versions in your inventory shows whether a system is protected.<\/p>\n<\/details>\n These are zero-days disclosed in April that, according to Microsoft, overlap with the current vulnerabilities. They indicate that Defender was already a target beforehand. Its inclusion in the KEV catalog now confirms active exploitation.<\/p>\n<\/details>\n No. Every complex security software has vulnerabilities. What matters is integrating them into regular vulnerability management rather than treating them as infallible. Switching shifts the problem \u2013 it doesn\u2019t solve it.<\/p>\n<\/details>\n More from the MBF Media Network<\/p>\n\n
What is being exploited<\/h2>\n
Why Automatic Patches Aren\u2019t a Free Pass<\/h2>\n
\n
\n
The Blind Spot Is Trust<\/h2>\n
What SOCs Should Verify Now<\/h2>\n
Frequently Asked Questions<\/h2>\n
Do I need to manually patch as a Defender user?<\/strong><\/summary>\n
How dangerous is CVE-2026-41091 really?<\/strong><\/summary>\n
Which version statuses close the gaps?<\/strong><\/summary>\n
What\u2019s the deal with RedSun and UnDefend?<\/strong><\/summary>\n
Should we switch endpoint protection because of such vulnerabilities?<\/strong><\/summary>\n