Microsoft is aware of an elevation of privilege in the Microsoft Malware Protection Engine in Microsoft…

CVE-2026-69414, publicly called ShieldBreak, is a local privilege escalation zero-day in the Microsoft Malware Protection Engine (MpEngine.dll) powering Microsoft Defender. It is a bypass of the July 2026 patch for CVE-2026-50656 (RoguePlanet). The exploit abuses Cloud Filter API user-mode callback hooks to interfere with Defender's cloud-hydration scan workflow: it plants an EICAR trigger file, uses Object Manager symbolic links and CLFS log manipulation to redirect Defender into locking C:\Windows\system32\phoneinfo.dll, swaps in a malicious replacement, and then waits for the built-in QueueReporting scheduled task to run wermgr.exe -upload at SYSTEM — which loads the attacker-controlled DLL and spawns a SYSTEM shell via conhost.exe. The PoC is public on GitHub (MSNightmare/ShieldBreak), confirmed working by Will Dormann and Kevin Beaumont, with a claimed 100% success rate on Windows 11 25H2, Server 2025, and Canary builds. Windows 10 and its server editions are also vulnerable but the PoC does not yet automate them. No patch exists as of 2026-08-17.

Microsoft rates this HIGH at 7.8, which is technically accurate for the CVSS:3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) but dramatically underweights reality. Defender is not optional middleware — it is the default kernel-mode security agent on every Windows endpoint in most enterprises. Gaining SYSTEM through the security agent itself is not just privilege escalation; it is defense evasion at fleet scale, because the very tool meant to detect post-exploitation is the tool being weaponized. Combined with public PoC availability, zero-day status, and a 100% success rate, the vendor's 7.8 is dangerously conservative.

Why this verdict

• Zero-day with public PoC and no patch: The exploit is on GitHub with a claimed 100% success rate, confirmed by independent researchers. Microsoft has no fix available. The window of exposure is indefinite.
• Role multiplier — kernel-mode security agent: Microsoft Defender runs as SYSTEM on virtually every Windows endpoint in the enterprise. This is not a niche application; it IS the security stack. Gaining SYSTEM through the AV agent means the attacker simultaneously escalates privileges AND neutralizes the primary detection layer. On domain controllers, this chain ends in domain admin. On any host, the detection plane is blind. ≥90% of Windows installs use Defender as primary AV, making this canonically a high-value-role component with fleet-scale blast radius.
• Low friction, high reliability: The attack requires only low-privilege local access (PR:L) with no user interaction. The PoC is automated and reportedly 100% reliable. Minor PoC modifications bypass signature-based detection, per Kudelski. The only real friction is obtaining initial local access — which is table stakes for any post-compromise toolkit.
• Patch bypass lineage: This is a confirmed bypass of a recently patched vulnerability (CVE-2026-50656). Organizations that believed they were protected after the July engine update are not. This erodes confidence in the remediation timeline.

Why not higher?

A 9.1 already places this at CRITICAL. It is not a 10.0 because the attack vector is local (AV:L), requiring the attacker to first obtain code execution on the target host through a separate chain. It does not provide remote code execution or initial access. The Scope in CVSS is technically Unchanged, though the real-world cross-component impact (Defender→SYSTEM→fleet) argues for a higher effective score than the raw 7.8.

Why not lower?

Downgrading below CRITICAL is blocked by the hard rule: the affected component is a kernel-mode security agent (Microsoft Defender) that runs as SYSTEM on ≥90% of the installed Windows base. The chain succeeds in every deployment role — workstations, member servers, domain controllers — and the blast radius is fleet-scale defense evasion plus SYSTEM access. The zero-day status with public PoC and no available patch eliminates any temporal relief. Even the PR:L requirement is weak friction; any phishing landing or RDP session satisfies it.

1. Deploy a 0-byte phoneinfo.dll placeholder in system32 — This blocks the file-substitution step the exploit depends on. Tanium and other endpoint management tools can push this as a Guardian policy. Deploy within 3 days per noisgate mitigation SLA for CRITICAL. Test on a small cohort first — phoneinfo.dll is used by Windows Error Reporting and the placeholder may suppress WER uploads.
2. Monitor wermgr.exe child processes and phoneinfo.dll writes — Create detection rules for: (1) child processes of wermgr.exe -upload, especially conhost.exe; (2) any non-TrustedInstaller write to C:\Windows\system32\phoneinfo.dll; (3) non-SYSTEM processes writing Report.wer to WER ReportQueue paths. Deploy within 3 days.
3. Enable Tamper Protection and ensure cloud connectivity — Tamper Protection prevents local SYSTEM-level changes to Defender settings. While it does not block the initial escalation, it raises the bar for post-exploitation Defender disablement. Ensure endpoints maintain cloud connectivity for Tamper Protection enforcement.
4. Layer a second EDR alongside Defender — If Defender is your only detection agent, a successful ShieldBreak exploit blinds you completely. A secondary EDR (CrowdStrike, SentinelOne, etc.) with independent kernel telemetry will detect the post-exploitation activity even if Defender is compromised.
5. Restrict QueueReporting scheduled task — Disable or modify the QueueReporting task via GPO to prevent wermgr.exe -upload from running automatically. This breaks the DLL-loading trigger. Trade-off: Windows Error Reporting uploads will stop, reducing Microsoft telemetry. Deploy within 3 days.

Run this script on each target Windows host as any user with read access to the Defender engine directory. No admin privileges required for the version check; admin required for the phoneinfo.dll mitigation check. Example: powershell -ExecutionPolicy Bypass -File .\Check-ShieldBreak.ps1

#Requires -Version 5.1
# Check-ShieldBreak.ps1 — CVE-2026-69414 (ShieldBreak) vulnerability & mitigation check
# Run on target Windows hosts. No admin needed for vuln check; admin needed for mitigation check.
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$ErrorActionPreference = 'Stop'

try {
    # Check if Defender is the active AV
    $defenderStatus = Get-MpComputerStatus -ErrorAction SilentlyContinue
    if (-not $defenderStatus) {
        Write-Host "UNKNOWN — Cannot query Defender status. Defender may not be installed or accessible."
        exit 2
    }

    $engineVersion = $defenderStatus.AMEngineVersion
    Write-Host "Defender Engine Version: $engineVersion"
    Write-Host "Defender Enabled: $($defenderStatus.AntivirusEnabled)"
    Write-Host "Real-Time Protection: $($defenderStatus.RealTimeProtectionEnabled)"
    Write-Host "Tamper Protection: $($defenderStatus.IsTamperProtected)"

    if (-not $defenderStatus.AntivirusEnabled) {
        Write-Host "UNKNOWN — Defender is disabled. Vulnerability requires Defender to be active."
        exit 2
    }

    # As of 2026-08-17 there is NO patched engine version for ShieldBreak.
    # Engine 1.1.26060.3008 (RoguePlanet fix) is BYPASSED by ShieldBreak.
    # When Microsoft ships a fix, update $patchedEngineVersion below.
    $patchedEngineVersion = $null  # SET THIS WHEN PATCH SHIPS

    $mitigated = $false
    # Check phoneinfo.dll mitigation (0-byte placeholder)
    $dllPath = "$env:SystemRoot\system32\phoneinfo.dll"
    if (Test-Path $dllPath) {
        $dll = Get-Item $dllPath
        if ($dll.Length -eq 0) {
            Write-Host "Mitigation detected: 0-byte phoneinfo.dll placeholder is in place."
            $mitigated = $true
        }
    }

    # Check QueueReporting task status
    try {
        $task = Get-ScheduledTask -TaskName 'QueueReporting' -TaskPath '\Microsoft\Windows\Windows Error Reporting\' -ErrorAction SilentlyContinue
        if ($task -and $task.State -eq 'Disabled') {
            Write-Host "Mitigation detected: QueueReporting task is disabled."
            $mitigated = $true
        } else {
            Write-Host "QueueReporting task is enabled (exploit trigger active)."
        }
    } catch {
        Write-Host "Could not query QueueReporting task status."
    }

    if ($patchedEngineVersion) {
        if ([version]$engineVersion -ge [version]$patchedEngineVersion) {
            Write-Host "PATCHED — Engine version $engineVersion meets or exceeds fix version $patchedEngineVersion."
            exit 0
        }
    }

    if ($mitigated) {
        Write-Host "VULNERABLE (mitigated) — No patch available, but compensating controls detected."
        exit 1
    }

    Write-Host "VULNERABLE — Defender is active, no patch exists for CVE-2026-69414 (ShieldBreak), and no compensating controls detected."
    exit 1

} catch {
    Write-Host "UNKNOWN — Error during check: $($_.Exception.Message)"
    exit 2
}

Sources

1. BleepingComputer — Microsoft working on Defender patch for ShieldBreak zero-day
2. The Hacker News — ShieldBreak Zero-Day PoC Claims Defender Patch Bypass
3. Kudelski Security — RoguePlanet Zero Day MS Defender Privilege Escalation
4. Morphisec — Microsoft Defender Zero Day RoguePlanet
5. Tanium — ShieldBreak Mitigation Guidance
6. SecurityWeek — Nightmare Eclipse Drops ShieldBreak
7. GitHub — MSNightmare/ShieldBreak PoC
8. ThreatLocker — ShieldBreak exploits same weakness as RoguePlanet