Researchers Run Their Own Code Inside a Windows SmartScreen Enclave

Researchers at the security firm Doyensec managed to run their own code inside a part of Windows that is meant to stay sealed off even after an attacker has taken over the rest of the machine. The target is a VBS enclave — an isolated slice of memory where the operating system guards secrets.

The enclave they broke into handles passwords for a protective feature. It is SFAPE.dll, the component behind Enhanced Phishing Protection in Microsoft Defender SmartScreen. The feature watches what you type or paste and warns you if you enter your Windows sign-in password somewhere unsafe, such as Notepad or a phishing page. To avoid storing the password in the clear, Windows intercepts it at login and keeps it hashed inside the enclave. On Windows 11 the process that loads this enclave is lsass.exe, which runs as SYSTEM.

What an enclave is, and why this matters

A VBS enclave is a signed library that an ordinary program loads but can neither read nor change once it is running. The Windows hypervisor keeps its memory in a more trusted world — VTL1, or Isolated User Mode — that normal-world code (VTL0) cannot reach. The design is meant to hold even if an attacker already controls the kernel or runs as SYSTEM. That is precisely why running attacker-chosen code inside that world is notable.

The attack does not work remotely: it needs a program already running on the machine that loads and calls the enclave (for SFAPE, that's LSASS). Microsoft rates the flaw (CVE-2026-83498) as a Critical, local elevation-of-privilege issue with a CVSS score of 7.8. In short, it is a way for code that already has a foothold to reach into the more trusted world next to it.

A chain built from a small mistake

Doyensec started from a minor bug and widened it step by step. Calling the enclave's Initialize function a second time makes it write a fixed four-byte error value to an address the caller controls, skipping the address check the first call performs. The researchers themselves concede that calling this an arbitrary write "would be a huge overstatement." Aimed at the right spot, though, that single write corrupts the value the enclave uses to tell its own memory from the host's, so its safety check stops working. From there a timing bug in another function triggers a controlled wipe, which redirects how the enclave looks up a stored object and lets the researchers replace the table that decides which code the enclave may run.

The work broke the enclave's isolation; it did not show that a user's password was read or stolen.

The fix, and the gap left behind

Microsoft fixed the flaw in its September 8, 2026 cumulative update (KB5124008) for Windows 11 versions 24H2 and 25H2; the company says it found the same issue internally and that the bug was never exploited in the wild. The patch adds the missing address check and blocks the old, vulnerable version of the enclave from loading.

One problem outlives the fix. Windows has no general blocklist for vulnerable enclaves like the one it keeps for drivers, and the September policy only blocks the old SFAPE file. An older Microsoft Edge enclave with a similar flaw (CVE-2023-36880) is still allowed to load — leaving open the known "bring your own vulnerable enclave" trick that earlier Akamai and Outflank research used to hide code from security tools.

Source: The Hacker News