Laboratory shows code execution in Windows SFAPE enclave (CVE-2026-83498) and patch

Researchers at the Doyensec firm have shown in laboratory that it is possible to run code chosen by an attacker within a portion of Windows memory that should remain sealed even when the rest of the system has been compromised. The affected component is a VBS (Virtualization-Based Security) library used by Microsoft's Enhanced Phishing Protection function - specifically the SFAPE.dll enclave - and Microsoft fixes vulnerability in the cumulative patch published on September 8, 2026 (KB5124008). The failure appears as CVE-2026-83498, was described by Microsoft as "lifting privileges" with critical severity (CVSS 7.8) and, according to the company, had not been exploited in real environments or was public before the arrangement; Microsoft also detected the same problem internally.

From a technical point of view, the VBS architecture isolates signed bookstores - enclaves - within a world of greater confidence managed by the Windows hyperviewer (VTL1 or Isolated User Mode). A system process in the ordinary world (VTL0), such as LSASS.exe - which handles credentials and runs like SYSTEM - can load the enclave but not read or modify its memory. The purpose is to protect critical secrets (e.g. password hashes for anti-phishing protection) even if an attacker has obtained privileges in the kernel or SYSTEM.

What the researchers got was not a remote entrance door, but an escalation from the inside: the operation requires that local code already exist with low access to the equipment and the possibility to invoke the enclave loaded by LSASS. Doyensec documents a chain of chained failures: a second call to the Initiative function causes the enclave to write a fixed error value of four bytes in a direction controlled by the calling process; that second call omits a check that does make the first invocation. This writing alone is limited, but if it affects the data the enclave uses to distinguish its own memory from that of the host, the safety checks stop working. From there, a timing bug in another function allows you to force a controlled deletion that redirects an internal search, resulting in readings and scriptures that allow you to replace the function table that decides which code can run the enclave. The final result described by Doyensec is the execution of code chosen by the attacker within the enclave.

It is important to separate confirmed facts from extrapolations: is shown in laboratory that the vulnerable enclave can be manipulated to run arbitrary code, and Microsoft and Doyensec agree that mitigation corrects these vectors. There is no public evidence of exploitation in real environments or of proven password theft from this failure; Microsoft defines impact as possible data filtration or code execution within the enclave. Doyensec's research also does not claim to have recovered hashes of user passwords on real equipment - that remains unconfirmed - but control of the enclave opens that theoretical risk if combined with other attack conditions.

Microsoft published the correction in its cumulative update for Windows 11 (versions 24H2 and 25H2) on September 8, 2026 and, according to Doyensec, the patched file adds the pre-first write direction check and hardens the function affected by the race condition. In addition, the update installs a policy that prevents loading the old and vulnerable version of SFAPE.dll, so that updated systems do not run the unsafe enclave. There is no separate alternative procedure: the recommended action for all users is to install the corresponding update.

However, there remains a gap in the overall mitigation strategy: Windows does not have a global lock list for vulnerable enclaves, similar to the one it keeps for drivers. The mitigation applied in September blocks only the affected version of SFAPE.dll; Doyensec warns that other signed enclaves with known failures can continue to be loaded - for example, a Microsoft Edge enclave with CVE-2023-36880 that had a reading / writing vulnerability remains, according to Doyensec, allowed. This difference can leave open the tactic known as "bringing your own vulnerable enclave," in which an attacker deliberately loads a signed but flawed enclave to hide code or data in front of security tools, a technique discussed in previous industry work.

Who does this affect? In practical terms, the greatest risk is for environments where an attacker can run code with low-to-medium privileges on the target machine - for example, through a local explosion, a poorly configured service or physical access - and where LSASS or other privileged process charges the vulnerable enclave. Isolated equipment and systems without exposed local accounts are less likely to be objective, but in organizations with users that reach local elevation with relative ease (later phisings, bad RDP configurations, or software that allows code execution), the vector is relevant.

Specific and verifiable recommendations: first and foremost, install the KB5124008 update or apply the Windows Update policies your organization uses; that is the only measure offered by Microsoft to mitigate this defect. Check the update status on servers and endpoints running Windows 11 24H2 / 25H2 and prioritize machines with administrative accounts or services that load enclaves. For business environments, integrate the patch into your patch management cycle and confirm the presence of the policy that blocks the old version of SFAPe.dll.

More defensive measures that reduce the probability and impact of such attacks include limiting privileged local access, disabling unnecessary services that allow code execution, applying the principle of lesser privilege, and deploying EDR solutions that monitor loads and calls to sensitive processes such as LSASS. Activating and maintaining up-to-date Virtualization-Based Security (HVCI) mitigation and using application allowlisting control help reduce the attack surface. For critical equipment, audit the loaded enclaves and contrast signatures and versions with official sources after the patch.

Finally, it is necessary to follow two fronts: on the one hand, to confirm the installation of the patch on all endpoints and servers; on the other, to press manufacturers to implement a centralized locking mechanism for faulty signed enclaves, as it exists for drivers, so that "bring your own vulnerable enclave" techniques are not available. For technical documentation on VBS and the isolation provided by the enclaves, Microsoft keeps material on its documentation portal: https: / / learn.microsoft.com / en-us / windows / security / virtualization-based-security /. The Doyensec research is published by the firm and is available on its site as a reference on methodology and analysis: https: / / doyensec.com /.

In summary: the finding shows that, even in layers designed to contain secrets in front of a compromised kernel, logical and synchronization errors can allow the attacker to scale up his presence and hide code within that reliable level. Mitigation exists and must be urgently implemented; open discussion is how to prevent other signed and vulnerable enclaves from being available for similar holdings in the future.