CVE-2026-108398 · .NET Framework WDAC Bypass via Untrusted Assembly Search Path

01 · The Real Story

A locksmith finds a way to open the vault door, but only in the 15% of banks that installed that particular brand of lock

CVE-2026-108398 is an untrusted search path flaw in Microsoft .NET Framework versions 3.5, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, and 4.8.1, spanning Windows 10 (21H2–22H2), Windows 11 (23H2–26H2), Windows Server 2022, and Windows Server 2025. Discovered by James Forshaw of Google Project Zero, the bug lets a local, low-privileged attacker place a crafted .NET assembly in a directory the CLR searches before trusted locations. When a WDAC-protected process loads that assembly, WDAC enforcement is bypassed and arbitrary code runs inside the protected context — allowlist policy or not. Microsoft patched it in the October 2026 Patch Tuesday rollup across roughly a dozen KBs (KB5127689–KB5127694, KB5127684–KB5127691, and others).

Microsoft rates this Important / 8.8 with a S:C (scope-changed) CVSS vector, reflecting the trust-boundary hop from user-level assembly placement into a WDAC-protected execution context. That score is *mathematically* correct, but it overstates fleet-wide risk because the entire impact chain is conditional on WDAC enforcement mode being active. Industry surveys place enforced-mode WDAC adoption at under 15% of enterprise endpoints. On the ~85% of hosts without WDAC enforced, there is literally no security boundary to cross — the bug has zero practical impact. Microsoft's own exploitability assessment says "exploitation less likely," there is no public proof-of-concept, no active exploitation, and no KEV listing. noisgate downgrades the score to 7.0 while keeping the HIGH bucket because the subset of hosts where WDAC *is* enforced tends to be the most sensitive tier in the fleet — PAWs, hardened DCs, kiosks, and compliance-scoped servers.

"WDAC bypass matters only where WDAC is enforced — patch hardened endpoints first, then sweep the fleet."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain local authenticated access

The attacker must first gain a low-privilege interactive or service-level session on the target Windows host. This can come from phishing, lateral movement, an exposed RDP session, or any prior compromise vector. The entire chain is post-initial-access; no remote exploitation path exists for this CVE alone.

Conditions required:

Valid local credentials or equivalent session (e.g., reverse shell, RDP, WinRM)
Target host runs a vulnerable .NET Framework version (3.5–4.8.1)

Where this breaks in practice:

Requires a prior compromise — filters out all unauthenticated internet-facing attackers
EDR on the endpoint should flag initial access tradecraft (e.g., beacon, implant staging)

Detection/coverage: EDR behavioral detections for initial access; Windows Security Event 4624 (logon type 10/3) for new sessions.

STEP 02

Confirm WDAC enforcement and .NET version

The attacker enumerates whether Windows Defender Application Control is enforced on the host via Get-CimInstance against the CI WMI namespace or by inspecting C:\Windows\System32\CodeIntegrity\SIPolicy.p7b. If WDAC is not enforced, the bypass is moot — the attacker can already run arbitrary code. The attacker also confirms the .NET Framework release key to ensure a vulnerable version is present.

Conditions required:

WDAC enforced in block mode on the host
Vulnerable .NET Framework version installed

Where this breaks in practice:

Under 15% of enterprise endpoints have WDAC in enforced mode — on all others, the attacker gains nothing from this CVE
WDAC audit-only mode is not a security boundary; bypassing it has no real impact

Detection/coverage: CI/CodeIntegrity audit events (3076/3077) may fire if the attacker probes with test binaries.

STEP 03

Place crafted .NET assembly in untrusted search path

The attacker writes a malicious .NET assembly (DLL) to a directory that the CLR resolves before trusted WDAC-approved locations. This exploits CWE-426: the .NET Framework's assembly resolution logic searches attacker-writable paths (e.g., application base, current directory, or a user-controlled GAC-like path) before falling back to the legitimate assembly. The attacker then registers or configures the assembly for loading — potentially via registry keys, app config XML, or DEVPATH environment variable manipulation.

Conditions required:

Write access to a directory in the CLR search order that precedes the trusted assembly location
Knowledge of which assembly name to squat (the target process must reference it)

Where this breaks in practice:

Filesystem ACLs on hardened WDAC hosts often restrict user-writable directories
AppLocker or WDAC supplemental policies may block DLL writes to certain paths
SRP or folder-level restrictions on C:\Windows and program directories

Detection/coverage: Sysmon Event ID 11 (file create) in sensitive directories; EDR file-write telemetry for DLL drops.

STEP 04

Trigger assembly load by protected process

The attacker triggers or waits for a WDAC-protected .NET process to load the squatted assembly name. Because the CLR resolves the attacker's copy first due to the untrusted search path, the malicious assembly executes within the protected process context. WDAC's code integrity policy does not block it because the load occurs through a trusted .NET Framework code path that was not properly validating the assembly origin.

Conditions required:

A WDAC-protected .NET process must load the targeted assembly name
Timing: either trigger the process or wait for periodic execution

Where this breaks in practice:

The attacker must identify a suitable target process — not all .NET processes load user-squattable assemblies
Process restart or service cycle may be required, introducing delay and detection opportunity

Detection/coverage: CI/CodeIntegrity Event 3077 (block) should NOT fire (that's the bypass); look for anomalous .NET assembly loads via ETW Microsoft-Windows-DotNETRuntime provider, Event ID 152 (AssemblyLoad).

STEP 05

Execute arbitrary code inside WDAC-protected context

With the malicious assembly loaded, the attacker now has arbitrary code execution that WDAC would have otherwise blocked. On a PAW or hardened server, this means running offensive tooling (Mimikatz, Rubeus, SharpHound) that the allowlist was specifically designed to prevent. On a domain controller, this could enable credential harvesting leading to domain compromise. The scope-change in the CVSS vector reflects this trust-boundary violation.

Conditions required:

Steps 1–4 completed successfully
The protected process context has sufficient privileges for the attacker's objective

Where this breaks in practice:

EDR behavioral detections still apply to post-exploitation activity (credential dumping, LSASS access)
Even with WDAC bypassed, Credential Guard and PPL may protect LSASS independently
Network-level detections (DCSync traffic, Kerberoasting, anomalous LDAP) remain intact

Detection/coverage: EDR process-level detections for offensive tool behavior; Windows Defender Credential Guard alerts; LSASS access monitoring (Sysmon Event 10).

03 · Compensating Control

HIGH 7.0→LOW 2.0

SEVERITY REDUCED

Prioritize patching on WDAC-enforced hosts immediately — Identify all endpoints with WDAC enforced in block mode (query CI WMI namespace or Intune compliance reports) and push the relevant October 2026 .NET Framework KB to those hosts first. These are the only hosts where the bypass has real impact. Deploy within 30 days per noisgate HIGH mitigation SLA; for Tier-0 assets (PAWs, DCs), target 7 days.

HIGH 7.0→MEDIUM 5.0

SEVERITY REDUCED

Restrict user-writable directories in CLR search paths via filesystem ACLs — Harden the .NET assembly search order by tightening NTFS ACLs on directories the CLR probes before the GAC — particularly application base directories, DEVPATH targets, and PrivateBinPath locations. Remove write access for non-admin accounts to these paths on WDAC-enforced hosts. This breaks Step 3 of the attack path. Deploy within 30 days.

HIGH 7.0→HIGH 6.5

Enable .NET assembly load logging via ETW — Turn on the Microsoft-Windows-DotNETRuntime ETW provider (keyword 0x8 for loader events) and forward AssemblyLoad events (ID 152) to your SIEM. Alert on assembly loads from non-standard paths on WDAC-enforced hosts. This doesn't prevent exploitation but gives you detection coverage for Step 4. Deploy within 30 days.

HIGH 7.0→MEDIUM 5.5

SEVERITY REDUCED

Enable Credential Guard and PPL on sensitive endpoints — Even if WDAC is bypassed, Windows Credential Guard and Protected Process Light (PPL) for LSASS independently protect credential material from in-memory extraction. This limits the blast radius of a successful bypass — the attacker gets code execution but cannot harvest LSASS credentials. Deploy within 30 days on all Tier-0 and Tier-1 hosts.

HIGH 7.0→IGNORE 0.0

SEVERITY REDUCED

Roll out fleet-wide .NET Framework patching in standard cycle — For the ~85% of hosts without WDAC enforced, this CVE has no practical impact, but the patch should still be applied as defense-in-depth. Use your standard .NET Framework patching cadence within the 180-day noisgate HIGH remediation SLA.

What doesn't work

Network segmentation — does not help because the attack is entirely local; the attacker already has a session on the host.
Web Application Firewall (WAF) — irrelevant; there is no web-facing attack surface for this CVE (AV:L).
WDAC audit-only mode — audit mode is not a security boundary; it logs but does not block. The bypass is meaningless in audit mode because nothing is being enforced. Do not confuse audit-mode WDAC deployment with actual protection.
Antivirus signature scanning — no known malware signature exists for this bypass technique; AV will not detect a crafted assembly placed in a search path unless behavioral heuristics flag the load pattern.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No active exploitation observed. Not listed in CISA KEV. Microsoft assesses "exploitation less likely." No campaigns attributed to this CVE as of 2026-10-14.
Proof-of-Concept Availability	No public PoC found. Checked pocindex.io (returned 404 for this CVE), GitHub repos named after the CVE, and ExploitDB — nothing published. The UltimateWDACBypassList repo does not yet reference CVE-2026-108398, though James Forshaw's prior WDAC/AppLocker bypass work (InstallUtil, CMSTP) is catalogued there.
EPSS Score	Not yet scored — CVE was published 2026-10-13, FIRST EPSS model typically lags 1–3 days for new CVEs. Given local-only attack vector, no PoC, and "exploitation less likely" tag, expect EPSS in the bottom quartile (<0.05) once scored.
CVSS Vector Interpretation	`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` — 8.8 HIGH. The `S:C` (scope changed) reflects the WDAC trust boundary hop. `AV:L` + `PR:L` means local auth is mandatory. No user interaction required. Full C/I/A impact within the changed scope (WDAC-protected execution context).
Affected Versions	.NET Framework 3.5, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1 across Windows 10 (21H2–22H2), Windows 11 (23H2–26H2), Windows Server 2022, Windows Server 2025. Essentially every supported Windows OS with .NET Framework installed.
Fixed Versions / KBs	October 2026 Patch Tuesday cumulative updates: KB5127689, KB5127690, KB5127691, KB5127692, KB5127693, KB5127694, KB5127684, KB5127685, KB5127666 — varies by OS and .NET version combination. No standalone backport; standard Windows Update / WSUS delivery.
Scanning / Exposure Data	Not applicable for internet-facing exposure (AV:L). GreyNoise / Shodan / Censys have no relevant scan data because the vuln requires local access. .NET Framework is installed on >99% of Windows endpoints, but WDAC enforcement (the prerequisite for impact) covers <15% of enterprise endpoints per industry estimates.
Disclosure Date	2026-10-13 — Patch Tuesday coordinated disclosure. Publicly disclosed at patch time (not a zero-day). Microsoft confirmed public disclosure but no prior exploitation.
Researcher / Reporter	James Forshaw, Google Project Zero. Forshaw is one of the most prolific Windows security researchers, with a long track record of WDAC, AppLocker, UAC, and COM-based bypasses. His involvement lends credibility to the finding — the bug is real and the mechanics are sound.
WDAC Adoption Context	<15% of enterprise endpoints have WDAC enforced in block mode. Deployments skew toward PAWs, kiosks, hardened DCs, and compliance-scoped servers — the most sensitive tier. Audit-only mode is not a security boundary; bypass is irrelevant there.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.0/10)

Why this verdict

Local auth required (AV:L/PR:L): The attacker must already have a foothold on the target host with a valid low-privilege account. This is a post-initial-access scenario — every unauthenticated remote attacker is filtered out. Downward pressure: −0.5 from baseline.
Impact gated by WDAC enforcement: The vulnerability's entire value proposition is bypassing WDAC. On the ~85% of enterprise endpoints where WDAC is not enforced, there is nothing to bypass and the CVE has zero practical impact. This is the largest single friction factor. Downward pressure: −1.0 from baseline.
No exploitation, no PoC, "exploitation less likely": Microsoft's own exploitability assessment is the lowest tier. No public PoC exists. No campaigns observed. The CVE was disclosed yesterday. Downward pressure: −0.3 from baseline.
Role multiplier: .NET Framework is ubiquitous (~99% of Windows hosts). However, the *impactful* deployment role is the WDAC-enforced high-value tier: PAWs (Privileged Access Workstations), hardened domain controllers, kiosks, and compliance-scoped servers. These represent roughly 2–10% of the installed base in security-mature organizations, exceeding the 1% floor threshold. On a PAW, the chain succeeds: local auth → WDAC bypass → run Mimikatz/Rubeus → harvest Tier-0 credentials → domain compromise. On a WDAC-enforced DC, the chain ends in credential extraction at domain scale. This high-value-role outcome (domain takeover) sets the verdict floor at HIGH. The floor prevents further downgrade despite the significant fleet-wide friction.
James Forshaw pedigree: GPZ researcher with a proven track record of weaponizable Windows bypasses. Even without a public PoC, red teams and advanced adversaries will reverse-engineer the patch delta. Expect a working exploit within 30–90 days. This prevents additional score reduction.

Why not higher?

The vuln is not CRITICAL because it requires local authenticated access (post-compromise), has no remote attack vector, no user interaction exploitation path, and no active exploitation. The impact is entirely conditional on WDAC enforcement, which covers a minority of enterprise endpoints. Microsoft themselves rate exploitability as "less likely" and severity as "Important" rather than "Critical." A CRITICAL rating would imply fleet-wide, remotely exploitable, or actively weaponized conditions — none of which apply here.

Why not lower?

The vuln cannot drop below HIGH because the floor rule is triggered: WDAC-enforced PAWs and hardened DCs represent >1% of the installed base in security-mature organizations, and on those hosts the complete chain (local auth → WDAC bypass → offensive tooling → domain compromise) is plausible with domain-scale blast radius. James Forshaw's involvement means the technical underpinning is sound and reverse-engineering of the patch is inevitable. Additionally, the S:C scope-change in the CVSS vector reflects a genuine trust-boundary violation that security-conscious orgs have invested in WDAC specifically to enforce.

06 · Verification

Crowdsourced verification payload.

Run this script on each target Windows host as a local administrator for reliable KB enumeration. Invoke with: powershell -ExecutionPolicy Bypass -File .\Check-CVE2026108398.ps1. The script checks the installed .NET Framework version, searches for the October 2026 fix KBs, and optionally reports whether WDAC is enforced (which determines real-world exploitability).

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#Requires -Version 5.1
<#
.SYNOPSIS
    Check if host is vulnerable to CVE-2026-108398
    (.NET Framework WDAC Bypass - Untrusted Search Path)
.NOTES
    Run on the TARGET Windows host as local admin.
    Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
#>

$ErrorActionPreference = 'SilentlyContinue'

# October 2026 .NET Framework fix KBs
$fixKBs = @(
    'KB5127684','KB5127685','KB5127666',
    'KB5127689','KB5127690','KB5127691',
    'KB5127692','KB5127693','KB5127694'
)

# --- Step 1: Detect .NET Framework version ---
$ndpKey = 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'
if (-not (Test-Path $ndpKey)) {
    Write-Output 'UNKNOWN - .NET Framework 4.x not found.'
    exit 2
}
$release = (Get-ItemProperty -Path $ndpKey -Name Release).Release
if (-not $release) {
    Write-Output 'UNKNOWN - Cannot read .NET Framework release key.'
    exit 2
}
$ver = switch ($true) {
    ($release -ge 533320) { '4.8.1+' }
    ($release -ge 528040) { '4.8'    }
    ($release -ge 461808) { '4.7.2'  }
    ($release -ge 461308) { '4.7.1'  }
    ($release -ge 460798) { '4.7'    }
    ($release -ge 394802) { '4.6.2'  }
    default               { '<=4.6.1'}
}
Write-Output "[*] .NET Framework version: $ver (release: $release)"

# --- Step 2: Check for fix KBs ---
$found = Get-HotFix | Where-Object { $fixKBs -contains $_.HotFixID }
if (-not $found) {
    $found = Get-CimInstance Win32_QuickFixEngineering |
        Where-Object { $fixKBs -contains $_.HotFixID }
}
if ($found) {
    $kbs = ($found | Select-Object -ExpandProperty HotFixID -Unique) -join ', '
    Write-Output "PATCHED - Fix KB installed: $kbs"
    exit 0
}

# --- Step 3: Vulnerable version check ---
$affected = @('4.6.2','4.7','4.7.1','4.7.2','4.8','4.8.1+')
if ($ver -notin $affected) {
    Write-Output "UNKNOWN - .NET Framework $ver may not be affected."
    exit 2
}

Write-Output "VULNERABLE - .NET Framework $ver present, no fix KB found."

# --- Step 4: WDAC context (informational) ---
try {
    $ci = Get-CimInstance -Namespace 'root/Microsoft/Windows/CI' `
        -ClassName MSFT_SIPolicy 2>$null
    if ($ci) {
        Write-Output '[!] WDAC policy ACTIVE - this host is directly exploitable via CVE-2026-108398.'
    } else {
        Write-Output '[i] No WDAC policy detected - bypass has no practical impact here.'
    }
} catch {
    Write-Output '[i] Could not query WDAC status (non-fatal).'
}
exit 1