Four-Byte Write and Timing Bug Let Researchers Run Code in Windows SmartScreen Enclave

Security researchers recently demonstrated the ability to execute their own code within a protected segment of Windows, known as a VBS enclave, which is designed to remain secure even if the rest of the system is compromised. This particular enclave is responsible for managing passwords for a Windows anti-phishing feature. The experiment was conducted in a controlled lab environment as a proof of concept, and there have been no reports of this vulnerability being exploited in real-world attacks. Microsoft addressed this flaw in its September 8, 2026 update. The vulnerability, identified as CVE-2026-83498, is classified by Microsoft as a critical elevation-of-privilege issue, with a CVSS score of 7.8. It was not publicly known or exploited before the patch was released. The security firm Doyensec, which conducted the research, published their findings on October 13, more than a month after the patch was issued. Microsoft also independently discovered the same issue internally. A VBS enclave is a secure library that a standard Windows program can load but cannot modify once it is operational. The Windows hypervisor ensures that the enclave's memory resides in a more trusted environment, known as VTL1 or Isolated User Mode, which is inaccessible to regular code running in the normal environment, VTL0. This design is intended to protect the enclave's contents even if an attacker has compromised the normal kernel or has SYSTEM-level access. The specific enclave targeted by Doyensec is SFAPE.dll, a component of the Enhanced Phishing Protection feature in Microsoft Defender SmartScreen. This feature monitors text input and alerts users if they enter their Windows sign-in password into an insecure location, such as Notepad or a phishing site. To achieve this securely, Windows intercepts the password at login and stores it in a hashed form within the enclave for later verification. The attack requires a program already running on the machine that can load and interact with the enclave; for SFAPE, this is the LSASS process, which manages sign-in credentials and operates with SYSTEM privileges. Microsoft's assessment confirms that the attack vector is local, requiring low-level access without user interaction. Essentially, this vulnerability allows code with existing access to penetrate the more secure environment, rather than providing an external entry point. Doyensec's attack exploited a minor error and progressively expanded it. By calling the enclave's Initialize function a second time, they caused it to write a fixed error value to a controllable address, bypassing the initial address check. Although this alone was not a significant threat, targeting the right location disrupted the enclave's memory differentiation, disabling its safety checks. A timing bug in another function then enabled a controlled wipe, which altered how the enclave accessed stored objects, allowing the researchers to replace the code execution table. The outcome was the execution of attacker-specified code within the enclave, breaching its isolation. However, the research did not demonstrate the theft or reading of user passwords, and Microsoft's advisory described the impact as data leakage or code execution within the enclave. Microsoft rectified the flaw with the September 8, 2026 cumulative update, which included additional checks and tightened functions to prevent the exploit. Despite the fix, a gap remains as Windows lacks a comprehensive blocklist for vulnerable enclaves, similar to the one for drivers. The September policy only blocks the old SFAPE file, leaving other vulnerable enclaves, like an older Microsoft Edge enclave with a similar flaw, still loadable. Whether this oversight was intentional or accidental is unclear, but it leaves open the possibility of using a "bring your own vulnerable enclave" tactic to conceal code and data from security tools.