Researchers Execute Code in Windows SmartScreen Enclave via Four-Byte Write and Timing Bug

Enclave Compromise Demonstrated

Security researchers from Doyensec successfully executed their own code within a protected part of Windows, specifically a Virtualization-Based Security (VBS) enclave. This enclave, designed to remain isolated even if the main operating system is compromised, handles password protection for the Windows Defender SmartScreen's Enhanced Phishing Protection feature.

Vulnerability Details and Patch

The vulnerability, identified as CVE-2026-83498, was rated by Microsoft as a critical elevation-of-privilege issue with a CVSS score of 7.8. Microsoft released a fix for this flaw on September 8, 2026. The company stated that the issue was not publicly known or exploited before the patch and was also discovered internally.

The attack was developed as a proof of concept in a lab setting and has not been observed in real-world attacks. Doyensec published their research on October 13, following the release of Microsoft's patch.

Understanding VBS Enclaves

VBS enclaves are signed libraries loaded by Windows programs, but their memory is kept in a more trusted environment (VTL1 or Isolated User Mode) by the Windows hypervisor. This design prevents ordinary code in the normal operating environment (VTL0) from accessing or altering the enclave's contents, even if an attacker gains SYSTEM privileges or compromises the kernel. The significance of this research lies in demonstrating code execution within this supposedly isolated environment.

Targeted Enclave and Attack Vector

The specific enclave targeted was SFAPE.dll, which is part of Microsoft Defender SmartScreen. This component monitors typed or pasted text to warn users if they enter their Windows sign-in password into an insecure location. To achieve this, Windows stores a hashed version of the user's password within the enclave. The lsass.exe process, which handles sign-in credentials and runs as SYSTEM, loads this enclave on Windows 11 systems.

The attack is local, requiring a program already running on the machine that loads and interacts with the enclave. It is not a remote exploit and requires low-level access without user interaction. This means the vulnerability allows existing malware with a foothold to escalate privileges into the more trusted VBS environment.