CVE-2026-83498 · Windows VBS Enclave (SFAPE.dll) Untrusted Pointer Dereference…

01 · The Real Story

Someone figured out how to pick the lock on one safe-deposit box inside the vault — but they already had to be inside the bank

CVE-2026-83498 is a memory corruption flaw in SFAPE.dll, the VBS enclave that powers Microsoft Defender SmartScreen's Enhanced Phishing Protection on Windows 11 (23H2 through 26H1) and Windows Server 2025. A missing pointer-validation check in the Initialize export allows a locally authenticated attacker to write the fixed value 0xC0000510 to a caller-controlled address. Doyensec researcher Adrian Denkiewicz demonstrated how to chain this constrained 4-byte write through a g_enclaveBase corruption, a TOCTOU race in ClipboardInput, a credential-context map pivot, and a Valid Target Table rewrite to achieve arbitrary code execution inside VTL1 Isolated User Mode — a hypervisor-enforced boundary that the VTL0 kernel cannot inspect.

Microsoft labelled this Critical in their maximum-severity field but scored it 7.8 HIGH on CVSS — an unusual split that overstates the practical risk. The exploit was demonstrated against a *researcher-created test enclave*, not the production LSASS-hosted instance. The target component — SmartScreen phishing password-reuse detection — is a leaf security feature, not Credential Guard (LsaIso.exe) or the Secure Kernel itself. Breaking into SFAPE lets you see hashed credential-comparison data on a single host; it does not grant domain admin, lateral movement, or fleet-scale impact. The chain requires local authenticated access (post-initial-compromise), involves a timing-dependent race, and has no public weaponized code. EPSS sits at the 24th percentile, there is no KEV listing, and no in-the-wild exploitation has been observed. The vendor severity overweights the architectural novelty of a VTL boundary crossing while underweighting the access prerequisites and blast-radius ceiling.

"VBS boundary break is architecturally novel but needs local access and a lab-grade chain to reach a leaf SmartScreen enclave."

02 · The Attack Path

6 steps from start to impact.

STEP 01

Establish local authenticated session

The attacker must already hold a low-privilege interactive session on the target host. This is the baseline for AV:L/PR:L — the chain cannot begin remotely. The attacker needs the ability to load and call exports from a VBS enclave DLL, which requires a process running in the same user session.

Conditions required:

Local interactive or RDP session on target host
Low-privilege authenticated user account

Where this breaks in practice:

Requires prior initial access — phishing, stolen creds, or adjacent compromise
EDR and login-auditing should flag anomalous interactive logons

Detection/coverage: Windows Security Event 4624 (logon type 2/10), EDR process-creation telemetry

STEP 02

Repeatedly invoke SFAPE Initialize export

The attacker calls the Initialize export of SFAPE.dll multiple times. After the first legitimate initialization, subsequent calls hit the code path with the missing pointer-validation check, allowing a fixed 4-byte value (0xC0000510) to be written at a caller-controlled address within VTL1 memory. This is an extremely constrained primitive — single value, single size.

Conditions required:

SFAPE.dll must be loaded (SmartScreen Enhanced Phishing Protection enabled)
Ability to invoke enclave exports from a host-side process

Where this breaks in practice:

SmartScreen Enhanced Phishing Protection must be enabled (default on Windows 11 consumer/enterprise, unlikely on Server 2025 headless deployments)
Kernel-mode code integrity (HVCI) restricts which binaries can call enclave exports

Detection/coverage: Unusual enclave-load events observable via ETW Microsoft-Windows-EnclaveApi provider

STEP 03

Corrupt g_enclaveBase to break IsInsideEnclave validator

The attacker targets the high DWORD of g_enclaveBase stored at image RVA 0xE86C. Writing 0xC0000510 there corrupts the base pointer so that IsInsideEnclave() misclassifies legitimate VTL1 pointers as external. This defeats the range-checking that separates trusted enclave memory from attacker-controlled VTL0 memory. The offset is version-specific and must be known in advance.

Conditions required:

Knowledge of SFAPE.dll base address and specific RVA for the target build
Successful step 2 write primitive

Where this breaks in practice:

Address-space layout varies by OS build — the RVA 0xE86C is specific to Doyensec's test build
ASLR within VTL1 adds entropy, though VBS enclaves have limited randomization surface

STEP 04

Win TOCTOU race in ClipboardInput

With IsInsideEnclave broken, the attacker exploits a time-of-check/time-of-use race in the ClipboardInput handler. The descriptor struct remains in writable VTL0 memory between validation and use. The attacker modifies the pointer and length fields between the check and the memset call, gaining an arbitrary-address zero-fill primitive. This is a timing-dependent race that must be won reliably.

Conditions required:

Corrupted validator from step 3
Ability to trigger ClipboardInput calls while racing VTL0 memory writes

Where this breaks in practice:

Race condition requires precise timing — unreliable across CPU/load profiles
Modern CPUs with speculative execution mitigations may alter timing windows

STEP 05

Pivot credential context map for read/write primitives

The attacker uses the zero-fill primitive to clear the high DWORD of the credential context map pointer, redirecting handle resolution to attacker-controlled synthetic tree nodes in VTL0 memory. This yields arbitrary read and write primitives within VTL1 enclave memory, breaking the confidentiality and integrity guarantees of the security boundary.

Conditions required:

Successful race win from step 4
Attacker-prepared synthetic data structures in VTL0

Where this breaks in practice:

Requires detailed knowledge of internal SFAPE data structures that vary between builds
Defensive memory layout changes in patched versions invalidate the primitive

STEP 06

Rewrite Valid Target Table for enclave code execution

With R/W primitives, the attacker overwrites the Valid Target Table (VTT) — the allow-list of callable VTL1 addresses — and its associated pointer and count. This lets them call arbitrary existing VTL1 functions. Using NtContinue (which restores registers from a CONTEXT structure), the attacker achieves full-argument function invocation inside Isolated User Mode. The demonstrated impact was code execution within the test enclave, enabling extraction of credential hashes held by SmartScreen.

Conditions required:

Full R/W primitive from step 5
Knowledge of VTT layout and target function addresses

Where this breaks in practice:

Demonstrated only on researcher-created test enclave, not the production LSASS-hosted SFAPE instance
LSA protection (PPL) on production systems adds an additional barrier to interacting with the LSASS-hosted enclave

Detection/coverage: PPL tampering alerts from EDR; anomalous LSASS access patterns (Sysmon Event ID 10)

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Deploy September 2026 cumulative update KB5124008 — The patch adds request-range validation to Initialize and hardens ClipboardInput handling, eliminating both the initial write primitive and the TOCTOU window. The updated VBS Code Integrity policy also rejects older SFAPE.dll images, preventing rollback attacks. This is the definitive fix. Per the noisgate remediation SLA for MEDIUM, deploy within 365 days — but given the detailed public writeup, pulling this into your next regular patch cycle (30-60 days) is prudent.

MEDIUM 5.5→LOW 3.5

SEVERITY REDUCED

Verify VBS Code Integrity policy rejects pre-patch SFAPE.dll — Microsoft shipped a CI policy update alongside KB5124008 that blocklists vulnerable SFAPE.dll hashes. Confirm via Get-CIPolicy or CiTool.exe -lp that the policy version includes the SFAPE revocation entry. This prevents an attacker from sideloading an older vulnerable DLL even on patched systems. If your CI policy deployment lags behind cumulative updates, the rollback vector remains open.

MEDIUM 5.5→LOW 3.0

SEVERITY REDUCED

Enforce LSA protection (PPL) and Credential Guard — Enable RunAsPPL for LSASS via registry or Group Policy (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1) and ensure Credential Guard is active. PPL prevents non-protected processes from opening handles to LSASS, blocking the host-side component from interacting with the production SFAPE enclave instance. This raises the bar from 'any local low-priv user' to 'attacker must also bypass PPL' — a significant friction increase.

MEDIUM 5.5→MEDIUM 5.0

Monitor ETW enclave-load events and LSASS access — Configure your EDR or Sysmon to alert on Microsoft-Windows-EnclaveApi ETW events and Sysmon Event ID 10 (process access) targeting lsass.exe. Unusual repeated enclave initialization calls or non-standard processes accessing LSASS handles are indicators of exploitation attempts. This is detection, not prevention, so it does not reduce severity but dramatically shortens dwell time.

What doesn't work

Network segmentation / firewall rules — This is a local privilege escalation; the attack never touches the network. Segmenting the host provides zero value against this chain.
Traditional antivirus scanning — The exploit executes within VTL1, which is architecturally invisible to VTL0-resident AV engines. AV cannot inspect or interdict code running inside a VBS enclave.
Disabling SmartScreen entirely — While this would unload SFAPE.dll, it removes a valuable security control (phishing protection) and is not recommended. The cure is worse than the disease at MEDIUM severity.
Application whitelisting / AppLocker — These operate in VTL0 and control which binaries load in normal user mode. They do not govern enclave loading, which is managed by VBS Code Integrity policy — a separate mechanism.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None observed. Not listed in CISA KEV. No reports from Microsoft, CrowdStrike, or Mandiant of active exploitation campaigns.
Proof-of-Concept	Detailed writeup, no weaponized code. Doyensec published a comprehensive technical blog post on 2026-10-13 (Playing It SFAPE) describing the full chain. No public exploit code found on GitHub, pocindex.io, ExploitDB, or Metasploit. The writeup functions as a roadmap but requires significant build-specific adaptation.
EPSS	0.00333 (0.31%) — 23.8th percentile. Exploitation probability is well below the median, consistent with a complex local-access chain.
KEV Status	Not listed as of 2026-10-14.
CVSS Vector	`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` — Local access, low privileges, no user interaction, unchanged scope. Microsoft rated max severity as Critical despite the 7.8 numerical score; this split suggests internal weighting of the VBS boundary crossing.
Affected Versions	Windows 11 23H2 (< 10.0.22631.7582), 24H2 (< 10.0.26100.9445), 25H2 (< 10.0.26200.9445), 26H1 (< 10.0.28000.2954), Windows Server 2025 (< 10.0.26100.33438)
Fixed Versions	September 2026 cumulative update KB5124008 (2026-09-08). VBS Code Integrity policy updated to reject older SFAPE.dll images, preventing rollback.
Scanning / Exposure	Not applicable for remote scanning — this is a local-access vulnerability. GreyNoise and Shodan have no relevant tags. Defender for Endpoint can inventory OS build versions for fleet-wide patching coverage.
Disclosure Date	Reported to MSRC on 2026-08-07 by Adrian Denkiewicz (Doyensec). Microsoft patched on 2026-09-08. MSRC noted the issue was independently identified internally.
Reporting Researcher	Adrian Denkiewicz of Doyensec. Full technical writeup published 2026-10-13.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Local-access prerequisite compounds severity downward. AV:L/PR:L means the attacker is already authenticated and on the box. This is a post-initial-access primitive — the hardest part of the kill chain (gaining that foothold) is assumed complete. For a fleet of 10,000 hosts, this vulnerability only matters after an endpoint is already compromised.
Complex, timing-dependent, build-specific chain. The exploit requires six discrete steps including corrupting a version-specific RVA, winning a TOCTOU race in ClipboardInput, and constructing synthetic data structures. The Doyensec writeup explicitly notes the demonstration targeted a test enclave instance, not the production LSASS-hosted SFAPE. Adapting this to a production exploit across diverse OS builds is non-trivial engineering.
No public weaponized code, no ITW exploitation, bottom-quartile EPSS. The detailed blog provides a roadmap but not a turnkey exploit. EPSS at the 24th percentile, no KEV listing, no GreyNoise/Shodan signals. The threat is theoretical as of today.
Role multiplier: SFAPE.dll is a leaf SmartScreen component, not a canonical high-value-role target. On *workstations* (the primary deployment): successful exploitation yields code execution inside the SmartScreen phishing-protection enclave on a single host — blast radius is *host-level*. The attacker could extract hashed credential-comparison data, but this is SmartScreen password-reuse detection data, not Credential Guard secrets (those live in LsaIso.exe, a separate trustlet). On *Windows Server 2025*: SmartScreen Enhanced Phishing Protection is a desktop UX feature rarely enabled on headless server or DC deployments — SFAPE.dll is unlikely to be loaded. No high-value role produces domain/fleet/supply-chain-scale impact. No verdict floor applies.
VBS boundary crossing warrants architectural attention but not panic. Breaking VTL0→VTL1 isolation is a meaningful research result and the technique may inform future attacks on other enclaves. This keeps the score above LOW but does not justify HIGH given the access prerequisites and limited blast radius.

Why not higher?

A HIGH or CRITICAL rating would require either remote reachability, a weaponized exploit, active exploitation, or a blast radius beyond a single host. None of those conditions are met. The affected component is SmartScreen's phishing-detection enclave — not Credential Guard, not the Secure Kernel, not a domain-controller-defining service. The chain was demonstrated only against a researcher-created test instance, and production LSASS PPL adds an additional barrier the writeup did not bypass. The architectural novelty of VTL boundary crossing does not compensate for the practical difficulty and limited impact ceiling.

Why not lower?

A LOW or IGNORE rating would undervalue the demonstrated capability to break a hypervisor-enforced security boundary. The detailed Doyensec writeup lowers the barrier for skilled attackers to reproduce and adapt the chain. Windows 11's install base is enormous, and SmartScreen EPP is enabled by default. If a motivated attacker adapts this to the production LSASS-hosted enclave, the credential-exposure impact on a compromised host would be significant, even if single-host-scoped.

06 · Verification

Crowdsourced verification payload.

Run this script on each target Windows host as a local administrator. Invoke with: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-83498.ps1. Requires admin rights to query OS build and SFAPE.dll version. Works on Windows 11 and Server 2025.

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

# Check-CVE-2026-83498.ps1
# Checks whether the host is vulnerable to CVE-2026-83498
# (Untrusted pointer dereference in Windows VBS Enclave / SFAPE.dll)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

#Requires -RunAsAdministrator

$ErrorActionPreference = 'Stop'

# Patched build numbers per OS version (from KB5124008, September 2026)
$patchedBuilds = @{
    '22631' = [version]'10.0.22631.7582'   # Win11 23H2
    '26100' = [version]'10.0.26100.9445'   # Win11 24H2 / Server 2025
    '26200' = [version]'10.0.26200.9445'   # Win11 25H2
    '28000' = [version]'10.0.28000.2954'   # Win11 26H1
}

try {
    $os = Get-CimInstance Win32_OperatingSystem
    $currentBuild = $os.BuildNumber
    $currentVersion = [version]$os.Version
    Write-Host "[*] OS: $($os.Caption)"
    Write-Host "[*] Build: $currentVersion (BuildNumber: $currentBuild)"

    # Check if this OS build is in the affected range
    if (-not $patchedBuilds.ContainsKey($currentBuild)) {
        Write-Host "[?] Build $currentBuild is not in the known affected set."
        Write-Host "UNKNOWN"
        exit 2
    }

    $requiredVersion = $patchedBuilds[$currentBuild]

    # Also check SFAPE.dll presence and version
    $sfapePath = "$env:SystemRoot\System32\SFAPE.dll"
    if (Test-Path $sfapePath) {
        $sfapeVersion = (Get-Item $sfapePath).VersionInfo.FileVersion
        Write-Host "[*] SFAPE.dll found: $sfapePath (version: $sfapeVersion)"
    } else {
        Write-Host "[*] SFAPE.dll not found — SmartScreen EPP enclave may not be present."
        Write-Host "[*] Component not loaded; attack surface absent on this host."
        Write-Host "PATCHED"
        exit 0
    }

    # Compare OS build version
    if ($currentVersion -ge $requiredVersion) {
        Write-Host "[+] OS version $currentVersion >= required $requiredVersion"
        Write-Host "PATCHED"
        exit 0
    } else {
        Write-Host "[-] OS version $currentVersion < required $requiredVersion"
        Write-Host "[-] Host is missing KB5124008 (September 2026 cumulative update)"
        Write-Host "VULNERABLE"
        exit 1
    }
} catch {
    Write-Host "[!] Error during check: $_"
    Write-Host "UNKNOWN"
    exit 2
}