- Joined
- Sep 16, 2026
- Messages
- 5
- Reaction score
- 1
Brief Description
Security flaw: an incomplete patch for CVE-2026-69414. This vulnerability in Microsoft Defender—publicly dubbed "ShieldCrash"—bypasses the September "ShieldBreak" fix; the claimed primitive is arbitrary file reading as NT AUTHORITY\SYSTEM.
___________
Technical Analysis
Affected versions: ShieldCrash has no separate CVE. Its parent, ShieldBreak, is CVE-2026-69414: Microsoft Malware Protection Engine 1.1.0.0 … < 1.1.26080.3 (the last affected version is 1.26070.7); fixed in 1.1.26080.3 (MSRC, 03.09.2026). The PoC author (Nightmare Eclipse / MSNightmare / INFINITE NIGHTMARE) claims that 1.1.26080.3 closed some paths but left a condition under which the same remediation-pipeline defect is reproducible on the September 2026 patches, all supported Windows versions. Installations where Defender is disabled or is not the active AV provider are not affected (MSRC FAQ for CVE-2026-69414). Independent reproduction of the public skeleton: Windows 11 25H2 (26200.9445), platform 4.18.26080.3, engine 1.1.26080.3, intelligence 1.459.121.0 (Howler Cell / Cyderes) — the chain reaches remediation, but the claimed read was not confirmed.
Platforms: Windows 10 / Windows 11 / Windows Server (x64), physical machines, VMs, and container hosts with active Microsoft Defender. The primitive is not kernel RCE and is not build-specific in the glibc sense: it relies on user-mode RPC MpClient.dll + privileged I/O MsMpEng.exe and on the standard Cloud Files subsystems (cldflt.sys / CldApi), NT Object Manager (\BaseNamedObjects\Restricted), and CLFS. The confirmed lab bench for the public PoC is Windows 11 25H2 x64 with engine 1.1.26080.3.
Vulnerability type: a chain of three defects, each insufficient on its own for SYSTEM-read.
TOCTOU (CWE-367) between scan and clean in Microsoft Malware Protection Engine: the path is checked at MpScanStart time, while the privileged read/copy in MpClean* occurs after the namespace has been rewritten.
Incomplete canonical path resolution (CWE-59 / CWE-284) in remediation: the engine follows an Object Manager symlink, UNC loopback (\localhost\C$), the \CLFS\ prefix, an NTFS mount point in \BaseNamedObjects\Restricted, and ADS :stream — the September fix blocked the WD_SCAN swap to System32 (arbitrary write of phoneinfo.dll in ShieldBreak), but did not close ADS+junction+object-symlink.
Substitution of Cloud Files placeholder content between hydrate (EICAR) and the subsequent FETCH_DATA (Warden.dll) via the attacker's CfApi provider. A single TOCTOU without a controlled namespace does not yield SYSTEM-read; a single reparse without bait detection does not trigger MpClean as SYSTEM.
CVSS v3.1: there is no separate CNA score for ShieldCrash. The parent CVE-2026-69414 (Microsoft): 7.8 (HIGH). Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; temporal CVSS:3.1/E
/RL:O/RC:C → 7.0. No unofficial scoring of the bypass itself has been published; the claimed primitive of the public skeleton is C:H with I/A undetermined, and the author later qualified it as full EoP via SAM.
Entry point: a local low-privilege process (PR:L), without UI and without network. The sink is Microsoft Defender RPC through MpClient.dll: MpManagerOpen → MpScanStart(MPSCAN_TYPE_RESOURCE, flags 0x60004000) on the path \.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERN, then MpCleanOpen / MpCleanStart. The attacker must be able to create a directory on NTFS, register a Cloud Files sync root, and create an object-symlink in \BaseNamedObjects\Restricted (this is available to an ordinary user). Defender must be the active provider. The leak target is specified by argv[1] (NT path, RtlDosPathNameToNtPathName).
Exploitation method:
Setup: HIGH_PRIORITY_CLASS / TIME_CRITICAL; hidden C:\ShieldCrash_<GUID> with DACL Everyone:GENERIC_ALL; CfRegisterSyncRoot provider Flubber, GUID {B196E670-59C7-4D41-9637-C62D80541321}, placeholder BERN, CfHydratePlaceholder → callback returns embedded eicar_com.zip; ADS BERN:stream is pre-filled with a copy of C:\Windows\System32\ntdll.dll.
Namespace: ObjectDir WD_TARGET_<GUID> with WD_SCAN → \CLFS\??\UNC\localhost\C$\ShieldCrash_<GUID>; shadow WD_SHADOW_<GUID> (NtCreateDirectoryObjectEx, fallback to target) with WD_SCAN → \??\UNC\localhost\C$\ShieldCrash_<GUID>.
Scan/clean: a separate thread loads %ProgramFiles%\Windows Defender\MpClient.dll, detects EICAR, enters remediation as SYSTEM (MsMpEng.exe).
Race: ReadDirectoryChangesW on %WinDir% for FILE_ACTION_ADDED TEMP\TMP*; delete shadow WD_SCAN → lookup falls through to the CLFS link, and a .BLF appears in the workdir; new shadow WD_SCAN → UNC C$\ShieldCrash_<GUID>_2.
Claimed leak: rename BERN → %TEMP%\ShieldCrash_<GUID>.BERN2 (the ADS travels with the file); CfDisconnect/Unregister; junction workdir → \BaseNamedObjects\Restricted (IO_REPARSE_TAG_MOUNT_POINT); object-symlink \BaseNamedObjects\Restricted\BERN:stream → argv[1]. SYSTEM remediation, following the junction+symlink, must read the protected file and leave a copy in a user-readable ADS; the PoC maps BERN2:stream to <target_name>.<GUID>. The discriminator between a vulnerable and a "patched" system: the ShieldBreak fix (engine 1.1.26080.3) breaks arbitrary writes to System32 via the WD_SCAN swap, but public ShieldCrash proceeds to read via ADS/CLFS/Restricted; there is no separate ShieldCrash patch.
Limitations: local only and only with active Defender (disabled Defender / third-party AV as primary — not exploitable; the presence of MpClient.dll on disk does not by itself mean vulnerability — MSRC FAQ). MFA, BitLocker "at rest," and SmartScreen do not mitigate it. The public skeleton (github.com/MSNightmare/ShieldCrash, 08.09.2026) is timing-sensitive: FSCTL_SET_REPARSE_POINT on the workdir yields ERROR_DIR_NOT_EMPTY (145) while MsMpEng holds the CLFS .BLF (DeleteFile — sharing violation, no retry); Howler Cell on engine 1.1.26080.3 against SAM/SECURITY/ELAM consistently obtained the contents of the planted ntdll.dll (~2.5 MB, PE FileDescription "NT Layer DLL") rather than a hive; the author's screenshot on ELAM is of the same order of size. The next day the author claimed full EoP (SAM "easily") and referred to BlueHammer (CVE-2026-33825) as post-read escalation via SAM hashes — this is a consequence of a working SYSTEM-read, not a second bug; a working full chain was not shown in the release. There is no trace of a SYSTEM-shell PoC; Warden.dll in the resources is a descendant of ShieldBreak (DLL write), and in the skeleton it is not carried through to System32.
Impact
A local low-privilege attacker on a host with active Microsoft Defender can (if the chain completes successfully):
Force MsMpEng.exe (SYSTEM) to read an arbitrary file that the attacker cannot access directly — SAM, SECURITY, ELAM, DPAPI, TLS keys, configs, other users' data
With a working read + SAM parsing (the BlueHammer path) — recover NT hashes of local accounts and escalate to administrator / NT AUTHORITY\SYSTEM
Use the same remediation pipeline as a candidate for arbitrary write (the ShieldBreak class: DLL into System32 on behalf of Defender) — not carried through in public ShieldCrash
Leave noisy artifacts (C:\ShieldCrash_*, Flubber, MpClient.dll outside the Defender tree), but the detection product itself is the target of the attack, so Defender signatures for the chain are not a control
Criticality for a typical desktop/server with default Defender is high: this is the third consecutive mpengine bypass (RoguePlanet CVE-2026-50656 → ShieldBreak CVE-2026-69414 → ShieldCrash), a local EoP after foothold.
Mitigation: there is no separate ShieldCrash patch; 1.1.26080.3 is mandatory against ShieldBreak, but according to the author it is insufficient — wait for an MPE engine update and check AMEngineVersion (Get-MpComputerStatus), not an OS KB. Interim: block unsigned local code (WDAC/AppLocker); alert on CfRegisterSyncRoot and LoadLibrary MpClient.dll outside MsMpEng/MpCmdRun/NisSrv; hunt for \BaseNamedObjects\Restricted\WD_* and C:\ShieldCrash_*; switching the primary AV to a third-party product removes the host from the condition.
Security flaw: an incomplete patch for CVE-2026-69414. This vulnerability in Microsoft Defender—publicly dubbed "ShieldCrash"—bypasses the September "ShieldBreak" fix; the claimed primitive is arbitrary file reading as NT AUTHORITY\SYSTEM.
___________
Technical Analysis
Affected versions: ShieldCrash has no separate CVE. Its parent, ShieldBreak, is CVE-2026-69414: Microsoft Malware Protection Engine 1.1.0.0 … < 1.1.26080.3 (the last affected version is 1.26070.7); fixed in 1.1.26080.3 (MSRC, 03.09.2026). The PoC author (Nightmare Eclipse / MSNightmare / INFINITE NIGHTMARE) claims that 1.1.26080.3 closed some paths but left a condition under which the same remediation-pipeline defect is reproducible on the September 2026 patches, all supported Windows versions. Installations where Defender is disabled or is not the active AV provider are not affected (MSRC FAQ for CVE-2026-69414). Independent reproduction of the public skeleton: Windows 11 25H2 (26200.9445), platform 4.18.26080.3, engine 1.1.26080.3, intelligence 1.459.121.0 (Howler Cell / Cyderes) — the chain reaches remediation, but the claimed read was not confirmed.
Platforms: Windows 10 / Windows 11 / Windows Server (x64), physical machines, VMs, and container hosts with active Microsoft Defender. The primitive is not kernel RCE and is not build-specific in the glibc sense: it relies on user-mode RPC MpClient.dll + privileged I/O MsMpEng.exe and on the standard Cloud Files subsystems (cldflt.sys / CldApi), NT Object Manager (\BaseNamedObjects\Restricted), and CLFS. The confirmed lab bench for the public PoC is Windows 11 25H2 x64 with engine 1.1.26080.3.
Vulnerability type: a chain of three defects, each insufficient on its own for SYSTEM-read.
TOCTOU (CWE-367) between scan and clean in Microsoft Malware Protection Engine: the path is checked at MpScanStart time, while the privileged read/copy in MpClean* occurs after the namespace has been rewritten.
Incomplete canonical path resolution (CWE-59 / CWE-284) in remediation: the engine follows an Object Manager symlink, UNC loopback (\localhost\C$), the \CLFS\ prefix, an NTFS mount point in \BaseNamedObjects\Restricted, and ADS :stream — the September fix blocked the WD_SCAN swap to System32 (arbitrary write of phoneinfo.dll in ShieldBreak), but did not close ADS+junction+object-symlink.
Substitution of Cloud Files placeholder content between hydrate (EICAR) and the subsequent FETCH_DATA (Warden.dll) via the attacker's CfApi provider. A single TOCTOU without a controlled namespace does not yield SYSTEM-read; a single reparse without bait detection does not trigger MpClean as SYSTEM.
CVSS v3.1: there is no separate CNA score for ShieldCrash. The parent CVE-2026-69414 (Microsoft): 7.8 (HIGH). Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; temporal CVSS:3.1/E
/RL:O/RC:C → 7.0. No unofficial scoring of the bypass itself has been published; the claimed primitive of the public skeleton is C:H with I/A undetermined, and the author later qualified it as full EoP via SAM.Entry point: a local low-privilege process (PR:L), without UI and without network. The sink is Microsoft Defender RPC through MpClient.dll: MpManagerOpen → MpScanStart(MPSCAN_TYPE_RESOURCE, flags 0x60004000) on the path \.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERN, then MpCleanOpen / MpCleanStart. The attacker must be able to create a directory on NTFS, register a Cloud Files sync root, and create an object-symlink in \BaseNamedObjects\Restricted (this is available to an ordinary user). Defender must be the active provider. The leak target is specified by argv[1] (NT path, RtlDosPathNameToNtPathName).
Exploitation method:
Setup: HIGH_PRIORITY_CLASS / TIME_CRITICAL; hidden C:\ShieldCrash_<GUID> with DACL Everyone:GENERIC_ALL; CfRegisterSyncRoot provider Flubber, GUID {B196E670-59C7-4D41-9637-C62D80541321}, placeholder BERN, CfHydratePlaceholder → callback returns embedded eicar_com.zip; ADS BERN:stream is pre-filled with a copy of C:\Windows\System32\ntdll.dll.
Namespace: ObjectDir WD_TARGET_<GUID> with WD_SCAN → \CLFS\??\UNC\localhost\C$\ShieldCrash_<GUID>; shadow WD_SHADOW_<GUID> (NtCreateDirectoryObjectEx, fallback to target) with WD_SCAN → \??\UNC\localhost\C$\ShieldCrash_<GUID>.
Scan/clean: a separate thread loads %ProgramFiles%\Windows Defender\MpClient.dll, detects EICAR, enters remediation as SYSTEM (MsMpEng.exe).
Race: ReadDirectoryChangesW on %WinDir% for FILE_ACTION_ADDED TEMP\TMP*; delete shadow WD_SCAN → lookup falls through to the CLFS link, and a .BLF appears in the workdir; new shadow WD_SCAN → UNC C$\ShieldCrash_<GUID>_2.
Claimed leak: rename BERN → %TEMP%\ShieldCrash_<GUID>.BERN2 (the ADS travels with the file); CfDisconnect/Unregister; junction workdir → \BaseNamedObjects\Restricted (IO_REPARSE_TAG_MOUNT_POINT); object-symlink \BaseNamedObjects\Restricted\BERN:stream → argv[1]. SYSTEM remediation, following the junction+symlink, must read the protected file and leave a copy in a user-readable ADS; the PoC maps BERN2:stream to <target_name>.<GUID>. The discriminator between a vulnerable and a "patched" system: the ShieldBreak fix (engine 1.1.26080.3) breaks arbitrary writes to System32 via the WD_SCAN swap, but public ShieldCrash proceeds to read via ADS/CLFS/Restricted; there is no separate ShieldCrash patch.
Limitations: local only and only with active Defender (disabled Defender / third-party AV as primary — not exploitable; the presence of MpClient.dll on disk does not by itself mean vulnerability — MSRC FAQ). MFA, BitLocker "at rest," and SmartScreen do not mitigate it. The public skeleton (github.com/MSNightmare/ShieldCrash, 08.09.2026) is timing-sensitive: FSCTL_SET_REPARSE_POINT on the workdir yields ERROR_DIR_NOT_EMPTY (145) while MsMpEng holds the CLFS .BLF (DeleteFile — sharing violation, no retry); Howler Cell on engine 1.1.26080.3 against SAM/SECURITY/ELAM consistently obtained the contents of the planted ntdll.dll (~2.5 MB, PE FileDescription "NT Layer DLL") rather than a hive; the author's screenshot on ELAM is of the same order of size. The next day the author claimed full EoP (SAM "easily") and referred to BlueHammer (CVE-2026-33825) as post-read escalation via SAM hashes — this is a consequence of a working SYSTEM-read, not a second bug; a working full chain was not shown in the release. There is no trace of a SYSTEM-shell PoC; Warden.dll in the resources is a descendant of ShieldBreak (DLL write), and in the skeleton it is not carried through to System32.
Impact
A local low-privilege attacker on a host with active Microsoft Defender can (if the chain completes successfully):
Force MsMpEng.exe (SYSTEM) to read an arbitrary file that the attacker cannot access directly — SAM, SECURITY, ELAM, DPAPI, TLS keys, configs, other users' data
With a working read + SAM parsing (the BlueHammer path) — recover NT hashes of local accounts and escalate to administrator / NT AUTHORITY\SYSTEM
Use the same remediation pipeline as a candidate for arbitrary write (the ShieldBreak class: DLL into System32 on behalf of Defender) — not carried through in public ShieldCrash
Leave noisy artifacts (C:\ShieldCrash_*, Flubber, MpClient.dll outside the Defender tree), but the detection product itself is the target of the attack, so Defender signatures for the chain are not a control
Criticality for a typical desktop/server with default Defender is high: this is the third consecutive mpengine bypass (RoguePlanet CVE-2026-50656 → ShieldBreak CVE-2026-69414 → ShieldCrash), a local EoP after foothold.
Mitigation: there is no separate ShieldCrash patch; 1.1.26080.3 is mandatory against ShieldBreak, but according to the author it is insufficient — wait for an MPE engine update and check AMEngineVersion (Get-MpComputerStatus), not an OS KB. Interim: block unsigned local code (WDAC/AppLocker); alert on CfRegisterSyncRoot and LoadLibrary MpClient.dll outside MsMpEng/MpCmdRun/NisSrv; hunt for \BaseNamedObjects\Restricted\WD_* and C:\ShieldCrash_*; switching the primary AV to a third-party product removes the host from the condition.
