← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-33825 · CWE-1220 · Disclosed 2026-04-14

Insufficient granularity of access control in Microsoft Defender

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a burglar using your own alarm company’s master key once they’re already inside

CVE-2026-33825 is a local privilege escalation in the Microsoft Defender Antimalware Platform. Microsoft and NVD show affected versions as Defender platform builds before 4.18.26030.3011, with the fix released on 2026-04-14. Public reporting and Huntress analysis tie this to the BlueHammer exploit chain, which abuses Defender’s own scan/update workflow to read sensitive files and pivot from a low-privileged local user into SYSTEM.

Microsoft’s HIGH 7.8 label is directionally right, but the raw CVSS still overstates reachability and understates urgency. In practice this is not remote initial access; it requires local code execution as a normal user and a fairly delicate race-condition chain. But it is also KEV-listed, publicly weaponized, and confirmed in real intrusions, so it stays firmly in HIGH rather than dropping into routine local-privesc backlog.

"Actively exploited, but still a post-compromise local privesc—not an internet edge fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land low-priv code execution on a Windows host

The attacker first needs ordinary user-level execution on a Windows system running vulnerable Microsoft Defender platform code. BlueHammer is not an entry vector; it is the second-stage privilege escalator used after phishing, drive-by malware, stolen user credentials, or another foothold lands code locally.
Conditions required:
  • Windows host with Microsoft Defender Antimalware Platform < 4.18.26030.3011
  • Attacker already has local code execution as a standard or otherwise low-privileged user
  • Defender is installed and active
Where this breaks in practice:
  • This is post-initial-access by definition; no foothold, no exploit
  • Modern email filtering, application control, and EDR should stop many precursor infection paths
  • VDI/kiosk/non-persistent systems reduce payoff even if exploited
Detection/coverage: Version-based vulnerability scanners and EDR inventory can catch this step well. External scanners are useless because the flaw is not network-reachable.
STEP 02

Synchronize Defender into a vulnerable scan state

Per Huntress, the public BlueHammer tooling uses oplocks, a fake Cloud Files sync provider, and a known-malicious test artifact to coerce Defender into scanning controlled content and holding a scan thread in a predictable window. That gives the attacker timing control over a normally narrow race condition.
Conditions required:
  • Ability to create files and user-space artifacts in writable locations
  • Defender real-time protection and relevant scan/update paths are enabled
  • Host behavior matches the vulnerable timing window
Where this breaks in practice:
  • Race-condition exploits are less reliable than straightforward logic bugs
  • Behavior may vary by hardware speed, Defender state, and competing I/O load
  • Some hardening stacks will flag unusual Cloud Files registration or odd temp-path activity
Detection/coverage: Behavioral detection is better than vuln scanning here: watch for suspicious Cloud Files sync-root registration, unusual WinDefend-driven VSS activity, and short-lived temp-path junction/reparse abuse.
STEP 03

Abuse Defender update/import logic to read protected data

The exploit then steers Defender’s internal update/import handling toward attacker-controlled paths and swaps those paths into a VSS-backed view of protected files. Huntress describes the result as Defender reading the SAM database as if it were a definition file and writing attacker-readable output.
Conditions required:
  • Successful timing control over Defender’s file handling
  • Access to staged update-like files and path redirection primitives
  • Vulnerable Defender platform behavior present
Where this breaks in practice:
  • This is the most delicate part of the chain and easiest to break operationally
  • Security tooling that alerts on junctions, object manager links, or sensitive file access can expose it
  • If Defender platform already auto-updated, the chain dies here
Detection/coverage: Look for Defender or MpCmdRun touching VSS paths, SAM-adjacent files, or abnormal definition import activity. Some EDRs will also catch reparse-point abuse and suspicious access to \Device\HarddiskVolumeShadowCopy*.
STEP 04

Turn credential material into SYSTEM

BlueHammer’s published chain parses recovered credential material, changes targeted user passwords, creates admin-capable sessions, and ultimately duplicates a SYSTEM token. The impact is full local takeover of the host and a springboard for credential theft, defense impairment, and lateral movement.
Conditions required:
  • Recovered or derivable credential material is usable
  • A practical path exists from harvested credentials to an administrative context on the host
  • Attacker can spawn follow-on processes locally
Where this breaks in practice:
  • Best payoff depends on useful credential material or privileged local context already existing on the host
  • Tier-0 admin hygiene, PAM, and workstation admin separation reduce blast radius
  • Host isolation by EDR can cut the chain before follow-on actions
Detection/coverage: Good detections include unexpected password changes, token theft/process creation anomalies, Sysmon events around privileged process launches, and Defender tampering or post-exploit credential access behaviors.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusConfirmed exploited. NVD marks the CVE as present in CISA KEV, and Huntress reported suspected in-the-wild BlueHammer activity in mid-April 2026.
KEV statusYES. Added to CISA KEV on 2026-04-22 with a federal due date of 2026-05-06.
Proof-of-concept availabilityPublic PoC exists. Reporting ties the exploit to the BlueHammer repository/tooling published by Chaotic Eclipse / Nightmare-Eclipse in early April 2026.
EPSS0.07069 from the user-supplied intel; third-party mirrors tracking FIRST data place it around the low-90s percentile in mid-May 2026. Even without EPSS, KEV status is the stronger signal here.
CVSS interpretationAV:L/AC:L/PR:L/UI:N means local, low-complexity, low-privilege, no click required. That is dangerous for post-compromise escalation, but it is still not an external edge exploit.
Affected versionsNVD lists Microsoft Defender Antimalware Platform versions before 4.18.26030.3011 as affected.
Fixed versionMicrosoft shipped the fix in Defender platform 4.18.26030.3011 on 2026-04-14; Microsoft Update Catalog associates that release with KB4052623.
Exposure realityShodan/Censys style internet-exposure data is mostly irrelevant because this is a host-local bug in an endpoint security component. Your real exposure metric is fleet patch drift, not open ports.
Disclosure timelinePublic PoC activity appeared in early April 2026; Microsoft published/fixed the CVE on 2026-04-14; KEV listing followed on 2026-04-22.
Research/reporting attributionThe public exploit chain is widely attributed in reporting to Chaotic Eclipse / Nightmare-Eclipse; Huntress provided the best technical public teardown of the BlueHammer chain.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.3/10)

The decisive amplifier is real-world exploitation plus public weaponization against a product deployed on an enormous share of Windows endpoints. The decisive brake is that the bug still requires low-privileged local execution and a multi-step race-condition chain, so this is a serious post-compromise escalator, not a remotely reachable catastrophe.

HIGH Affected version range and fixed build
HIGH KEV listing and active exploitation status
MEDIUM Operational reliability of the public exploit across varied enterprise hosts

Why this verdict

  • Started from Microsoft’s 7.8 HIGH baseline because the end state is full local compromise of the host, including potential SYSTEM-level execution.
  • Upward pressure: KEV + public exploit + real intrusion reporting add urgency that plain CVSS misses; this is not hypothetical lab-only privesc research anymore.
  • Downward pressure: requires local code execution first. That implies the attacker is already on the box, which compounds downward pressure because the reachable population is limited to machines where another control already failed.
  • Downward pressure: no internet-facing attack surface. NGFW, WAF, and perimeter scanners are irrelevant because there is no direct remote edge path into the bug.
  • Slight upward pressure: huge installed base. Defender is common enough that once an attacker has a foothold, the exploit economics are good and operationalization cost is low.

Why not higher?

This does not justify CRITICAL because it is neither unauthenticated remote code execution nor wormable network exposure. The attacker must already be on the host with local execution, then land a somewhat finicky exploit chain to convert that foothold into SYSTEM.

Why not lower?

This does not fall to MEDIUM because the exploitation signal is too strong. KEV inclusion, public PoC, and Huntress reporting of in-the-wild activity mean defenders should treat it as a live post-compromise privilege-escalation primitive, not ordinary patch debt.

05 · Compensating Control

What to do — in priority order.

  1. Verify Defender platform version fleet-wide — Enumerate AMProductVersion or the installed Defender platform directory across all Windows endpoints and isolate anything below 4.18.26030.3011. Because this CVE is KEV-listed and actively exploited, do this immediately, within hours, not during the next routine inventory cycle.
  2. Force the Defender platform update — Do not assume auto-update worked everywhere; explicitly trigger/update/check the Defender antimalware platform release tied to KB4052623 / 4.18.26030.3011 on lagging systems. With KEV status, apply this immediately, within hours.
  3. Tighten low-privilege execution paths on high-risk tiers — Use WDAC/AppLocker, script control, and user-writable path execution restrictions to make the initial low-priv local foothold harder to land or reuse on admin workstations, jump boxes, and servers. Treat this as compensating control to deploy immediately, within hours where patch verification is incomplete.
  4. Hunt for BlueHammer tradecraft — Add detections for suspicious Cloud Files sync provider registration, Defender-driven VSS activity, junction/reparse abuse, SAM/VSS access anomalies, and abnormal password reset/token-duplication sequences. Stand this up immediately, within hours because exploitation is already public.
  5. Reduce privileged credential residue — Limit cached admin usage on workstations, enforce admin separation, and keep privileged accounts off lower-trust endpoints so a local privesc yields less reusable authority. This is not the primary fix, but it reduces blast radius and should be prioritized immediately, within hours on crown-jewel tiers.
What doesn't work
  • A WAF, proxy, or perimeter IPS does not help; there is no remote HTTP edge path to block.
  • Updating signatures only is not enough; this is a platform vulnerability, so definition freshness alone does not guarantee safety.
  • Relying on EDR after the fact is not a mitigation strategy by itself; the exploit abuses a trusted Windows security component and can move quickly once local code already exists.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows host or remotely over WinRM/PowerShell Remoting with a user that can query Defender status; local admin is preferred for consistency. Save it as check-CVE-2026-33825.ps1 and run: powershell.exe -ExecutionPolicy Bypass -File .\check-CVE-2026-33825.ps1 -MinVersion 4.18.26030.3011.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-CVE-2026-33825.ps1

# Purpose: Determine whether the local Microsoft Defender Antimalware Platform

#          is vulnerable to CVE-2026-33825 based on platform version.

# Output : VULNERABLE / PATCHED / UNKNOWN

# Exit   : 1 = vulnerable, 0 = patched, 2 = unknown/error


[CmdletBinding()]
param(
    [Parameter(Mandatory = $false)]
    [string]$MinVersion = '4.18.26030.3011'
)

function Get-PlatformVersion {
    # First try the supported Defender cmdlet.

    try {
        Import-Module Defender -ErrorAction SilentlyContinue | Out-Null
        $status = Get-MpComputerStatus -ErrorAction Stop
        if ($status -and $status.AMProductVersion) {
            return [string]$status.AMProductVersion
        }
    }
    catch {
        # Fall through to filesystem-based detection.

    }

    # Fallback: inspect installed platform directories.

    try {
        $base = Join-Path $env:ProgramData 'Microsoft\Windows Defender\Platform'
        if (Test-Path -LiteralPath $base) {
            $dirs = Get-ChildItem -LiteralPath $base -Directory -ErrorAction Stop |
                Where-Object { $_.Name -match '^\d+\.\d+\.\d+\.\d+$' } |
                Sort-Object { [version]$_.Name } -Descending

            if ($dirs -and $dirs.Count -gt 0) {
                return [string]$dirs[0].Name
            }
        }
    }
    catch {
        # Ignore and return null below.

    }

    return $null
}

try {
    $installed = Get-PlatformVersion

    if (-not $installed) {
        Write-Output 'UNKNOWN - unable to determine Microsoft Defender platform version'
        exit 2
    }

    try {
        $installedVer = [version]$installed
        $fixedVer = [version]$MinVersion
    }
    catch {
        Write-Output ("UNKNOWN - version parsing failed (installed='{0}', fixed='{1}')" -f $installed, $MinVersion)
        exit 2
    }

    if ($installedVer -lt $fixedVer) {
        Write-Output ("VULNERABLE - Microsoft Defender platform {0} is older than fixed version {1}" -f $installed, $MinVersion)
        exit 1
    }
    else {
        Write-Output ("PATCHED - Microsoft Defender platform {0} is at or above fixed version {1}" -f $installed, $MinVersion)
        exit 0
    }
}
catch {
    Write-Output ("UNKNOWN - unexpected error: {0}" -f $_.Exception.Message)
    exit 2
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a live post-compromise escalator: pull a fleet-wide version report for Defender platform, force or verify rollout of 4.18.26030.3011 or later, and put temporary hardening/detections around low-priv execution and BlueHammer tradecraft on high-risk Windows tiers. Because this CVE is KEV-listed and actively exploited, override the normal HIGH mitigation clock and patch / mitigate immediately, within hours; that is your noisgate mitigation SLA here. For formal closure, keep any stragglers inside the HIGH noisgate remediation SLA of ≤180 days, but in practice anything still below the fixed platform version after the first day should be treated as an exception requiring escalation.

Sources

  1. NVD CVE-2026-33825
  2. Microsoft Security Update Guide advisory
  3. Microsoft Defender release notes
  4. Microsoft Update Catalog KB4052623
  5. CISA Known Exploited Vulnerabilities Catalog
  6. Huntress BlueHammer intrusion analysis
  7. FIRST EPSS project
  8. BleepingComputer coverage of KEV addition and public PoC
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.