Active Exploitation Alert: Microsoft Defender LPE (CVE-2026-41091)
Hey everyone, just saw the breaking release regarding Microsoft Defender. It’s always a bad day when the security vendor becomes the attack vector, but Microsoft confirmed active exploitation of a Privilege Escalation flaw tracked as CVE-2026-41091 (CVSS 7.8).
The vulnerability stems from "improper link resolution before file access" (link following). If an attacker can plant a malicious file and trick Defender into scanning a specific path, they can leverage the link following behavior to escalate their rights up to SYSTEM. This is particularly dangerous because it turns the EDR—which usually protects us—into a weapon for privilege escalation. There is also a Denial-of-Service (DoS) flaw being exploited in the wild alongside it.
The obvious remediation is patching, but until then, detection is tricky. I've put together a basic KQL query for Defender for Endpoint to hunt for suspicious process creation patterns associated with link manipulation:
DeviceProcessEvents
| where FolderPath contains @"Microsoft Defender"
| where InitiatingProcessFileName in ("powershell.exe", "cmd.exe", "mklink.exe")
| where ProcessCommandLine contains "junction" or ProcessCommandLine contains "symlink"
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName
If you need to quickly audit your fleet for the patch status, use this PowerShell snippet:
Get-MpComputerStatus | Select-Object AntivirusSignatureVersion, NisEngineVersion, QuickScanAge
Has anyone started seeing IOC patterns related to the DoS component yet, or is everyone solely focused on the LPE right now?
Solid queries. We deployed a similar hunt rule this morning but found a lot of false positives from legitimate admin scripts. I'd suggest adding a filter to exclude processes signed by Microsoft to reduce noise while hunting for the exploit chain:
| where InitiatingProcessVersionInfoCompanyName != "Microsoft Corporation"
This helps narrow it down to third-party tools or malware trying to abuse the link resolution.
This is particularly nasty for MSPs managing remote clients. If an attacker pops a workstation with standard user rights, they can use this to own the box and potentially disable the EDR to move laterally. We're pushing the updates via Intune immediately. Make sure to verify the 'Platform' update version, not just the definitions, as the engine update is what fixes the link resolution logic.
From a pentest perspective, this is a huge win for post-exploitation. Usually, killing AV is a noisy event that gets you flagged immediately. If you can just use the AV to get SYSTEM, you maintain persistence without triggering the 'Tamper Protection' alerts that usually accompany stopping the service.
Spot on regarding the noise. To validate patch compliance across the fleet without triggering alerts, I recommend checking the MpEngine version directly. Ensure you are running a version released after the security update drop. Here is a quick PowerShell one-liner for local verification:
Get-MpComputerStatus | Select-Object AntivirusEngineVersion
Validating Tamper Protection status is crucial here, as attackers often disable it to persist after exploiting the LPE. To verify it's enforced across the fleet remotely, use this PowerShell snippet:
Get-MpComputerStatus | Select-Object TamperProtectionSource, IoavProtectionEnabled
If `TamperProtectionSource` returns null, verify your GPOs are applying correctly before relying solely on the patch rollout.
From a Kubernetes perspective, if you're running Defender as a privileged DaemonSet scanning host mounts, this vulnerability is particularly concerning. An attacker escaping a container could craft a symlink on a writable volume to trigger the LPE on the underlying node.
To quickly verify that your control plane isn't deploying vulnerable images, check the deployed Defender image tags across all namespaces:
kubectl get pods -A -l app=defender -o path='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{":\t"}{.spec.containers[0].image}{"\n"}{end}'
From a compliance perspective, verifying the installation of the specific cumulative update is key for audit trails. To quickly report on the remediation status across your endpoints, use this PowerShell command to confirm the latest security update is applied:
Get-HotFix | Where-Object {$_.Description -eq "Security Update"} | Sort-Object InstalledOn -Descending | Select-Object HotFixID, InstalledOn
This provides the necessary evidence that the vulnerability has been addressed during your next review.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access