--- title: Four-Byte Write Bug Lets Researchers Run Code in Windows SmartScreen Enclave - Capstone Technologies Group description: Doyensec chained a four-byte write in SmartScreen's SFAPE.dll enclave to run code in VTL1. Microsoft fixed CVE-2026-83498 in KB5124008; verify patching. canonical_url: https://captechgroup.com/threat-intelligence-center/four-byte-write-bug-lets-researchers-run-code-in-w-30bd88 language: en-GB date: 2026-10-14T12:37:21Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/four-byte-write-bug-lets-researchers-run-code-in-w-30bd88. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 4734 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/four-byte-write-bug-lets-researchers-run-code-in-w-30bd88. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. Security researchers at **Doyensec** ran code of their own choosing inside a Windows VBS enclave, a slice of memory the operating system is supposed to keep sealed even when an attacker already owns the kernel. The flaw is tracked as **[CVE-2026-83498](https://nvd.nist.gov/vuln/detail/CVE-2026-83498 "NVD: CVE-2026-83498")**, and Microsoft patched it in the September 8, 2026 cumulative update. A VBS enclave is a signed library that a normal program loads but cannot read or modify once it is running. The Windows hypervisor holds that memory in a more trusted world, VTL1 (also called Isolated User Mode), which ordinary code in the normal world, VTL0, cannot touch. That boundary is the whole point: secrets inside the enclave are supposed to survive a compromise of everything outside it. The enclave Doyensec attacked is SFAPE.dll, the component behind Enhanced Phishing Protection in Microsoft Defender SmartScreen. It stores a hashed copy of your Windows sign-in password so the feature can warn you when you type that password into Notepad or a phishing page. On Windows 11, the process that loads it is `lsass.exe`, which handles sign-in credentials and runs as SYSTEM. The starting point was small. Calling the enclave's Initialize function a second time writes a fixed four-byte error value to a caller-controlled address, skipping the address check the first call performs. Doyensec is blunt that this on its own is weak, writing that calling it an arbitrary write "would be a huge overstatement." Pointed at the right location, that single write corrupts the value the enclave uses to distinguish its own memory from the host's, and a timing bug in a second function extends it into full code execution inside VTL1. Scope matters here. The attack is local, requires code already running on the machine, and Microsoft says it was not exploited and not publicly known before the fix. The researchers broke isolation, they did not demonstrate reading a user's password. An older Edge enclave flaw, **[CVE-2023-36880](https://nvd.nist.gov/vuln/detail/CVE-2023-36880 "NVD: CVE-2023-36880")** from 2023, remains relevant to the broader question this work raises. ## From Four Bytes to Enclave Code Execution: The Exploitation Chain The chain starts with preconditions that bound how worried anyone should be. Microsoft scores **CVE-2026-83498** at CVSS 7.8 with a local attack vector, low privileges required, and no user interaction, which means an attacker needs code already running on the machine before any of this applies. There is no remote trigger and no phishing lure in the chain itself. The reachable surface is `SFAPE.dll`, the enclave behind Enhanced Phishing Protection. On Windows 11 that enclave is loaded and called by `lsass.exe`, the SYSTEM process that handles sign-in credentials, and it holds a hashed copy of the Windows password captured at login so typed or pasted input can be compared against it later. An attacker needs a path to drive calls into that enclave through its host process, which maps to **MITRE ATT&CK T1068 (Exploitation for Privilege Escalation)** rather than any remote access technique. The initial defect is small. Calling the enclave's Initialize function a second time causes it to write a fixed four-byte error value to an address the calling program supplies, and that second call skips the address validation the first call performs. Doyensec was blunt about the limits here, noting that describing it as an arbitrary write "would be a huge overstatement," since the value is fixed and the window is narrow. What makes the write useful is where it lands. Aimed at the variable the enclave uses to distinguish its own VTL1 memory from host memory in VTL0, those four bytes corrupt the boundary check itself. After that, the enclave can no longer reliably tell which side of the trust boundary a pointer belongs to, and its internal validation stops rejecting host-controlled addresses. From there the chain widens through a second defect: - A timing bug in another enclave function triggers a controlled wipe of enclave state. - That wipe redirects how the enclave resolves a stored object, turning a lookup into an attacker-influenced dereference. - The resulting read and write primitives are used to overwrite the table that determines which code the enclave is permitted to execute. - Replacing that table yields attacker-chosen code running inside Isolated User Mode. The attestation model is what makes this interesting rather than routine. An enclave is signed and its integrity is enforced at load time, so the host process cannot read or patch it afterward. Once execution is hijacked from inside, the signature still checks out while the code running under it does not match what Microsoft shipped. For defenders, that means an attacker operating inside an enclave sits in memory your endpoint agent cannot inspect, because VTL0 tooling has no view into VTL1. Microsoft's advisory describes the impact as data leakage from or code execution inside the enclave. The research did not demonstrate recovery of a user's Windows password, and the proof of concept stayed in a lab with no observed in-the-wild use. Precedent matters for judging where this goes. Earlier work from **Akamai** and **Outflank** showed that loading a signed but flawed enclave, a technique sometimes called bring your own vulnerable enclave, can hide code and data from security tooling. **CVE-2023-36880**, a read-and-write flaw in an older Microsoft Edge enclave from 2023, is the documented example of that class and remains loadable. ## What Enclave Compromise Means for Trust Boundaries in Windows The demonstrated impact is narrower than the headline suggests, and that matters for how you rank this internally. Microsoft's advisory describes the outcome as data leakage from or code execution inside the enclave. Researchers broke the isolation boundary. They did not show a user's Windows password being read or exfiltrated, and nobody has observed this in real attacks. What changes is an assumption many security programs quietly depend on. The entire point of an isolated enclave is that nothing in the normal world can inspect it, including your endpoint agent. That protection has no allegiance. Code an attacker places inside gets the same inspection immunity the design grants legitimate code, which means your [EDR](https://captechgroup.com/services/cybersecurity-services "Cybersecurity Services | Protect Your Business with Capstone Technologies") telemetry has a region it structurally cannot read. Think about where that lands in your risk register. If you accepted residual risk on credential theft from privileged workstations because hardware-backed isolation holds the secrets, that acceptance was written against a boundary enforced by software. Software has bugs, and this one was found in a component that handles sign-in material. The control still raises attacker cost considerably. It just stops being a line you can draw under the risk. There is a second consequence for the trust decisions your users see. Enhanced Phishing Protection exists to put a warning in front of someone typing a corporate password into the wrong window. Code running inside that enclave sits on the same side of the boundary as the logic making that judgment. The research did not demonstrate suppressed warnings, so treat that as a plausible direction rather than a proven capability, but it is the direction your awareness training implicitly assumes will keep working. The gap that outlives the patch is the one worth putting in front of your leadership. Windows maintains a blocklist for vulnerable drivers. It has no equivalent general blocklist for vulnerable enclaves. The September policy blocks one specific old file and nothing more, and Doyensec notes that an older Microsoft Edge enclave with a similar read-and-write flaw, **CVE-2023-36880** from 2023, is still allowed to load on current systems. That leaves a technique available that researchers at Akamai and Outflank documented earlier, sometimes called **bring your own vulnerable enclave**. An attacker with local code execution loads a legitimately signed but flawed enclave and uses it as a container for code and data that security tooling cannot inspect. Your fully patched Windows 11 fleet is still eligible to load that older signed component. Patching one enclave does not retire the class of problem, and whether leaving the Edge enclave loadable was deliberate or an oversight is not clear. For teams that build on the enclave model, the engineering lesson is specific. Every pointer the host supplies has to be validated on every call path, including repeated calls to initialization routines, because an attacker controls when and how often those functions run. If you ship software that stores keys or integrity checks inside an enclave, your customers are trusting your validation logic as much as they trust the hypervisor. The practical takeaway for your organization is that VBS-based protections belong in your stack as one layer among several, documented as such in your control narratives rather than cited as a terminal mitigation for endpoint compromise. ## Patching, Detection and Hardening Steps for Windows Environments Start by confirming **KB5124008** is installed on every Windows 11 24H2 and 25H2 host you run. Microsoft shipped the fix in the September 8, 2026 cumulative update, and there is no separate workaround, mitigation flag, or configuration change that substitutes for it. Installing the update is the action. That update does two things worth verifying separately. The patched enclave now validates the address before the first write and tightens the function the timing bug depended on, and the update also ships a policy that blocks the old, vulnerable SFAPE file from loading at all. A fully patched machine will not run the vulnerable enclave even if the old binary is still sitting on disk, which means your verification target is patch presence, not file removal. Work through your estate in this order: - Pull a report from your [patch management](https://captechgroup.com/services/managed-it-solutions "Comprehensive Managed IT Services | Dayton, Columbus, Cincinnati") tooling for KB5124008 across all Windows 11 endpoints and flag anything still reporting the pre-September build. - Identify hosts running Windows builds outside current servicing. Machines that no longer receive cumulative updates will never get the enclave-blocking policy. - Confirm virtualization-based security is actually enabled where you assume it is. Enclave protections only exist on systems where the hypervisor is enforcing the VTL split, and drifted or disabled VBS configurations are common on hardware that was imaged years ago. Once patching is verified, deal with the precondition. The exploit requires code already running on the machine with low privileges, so every control that limits unprivileged code execution also removes the starting point for this chain. Trim standing local administrator rights, restrict who can run unsigned binaries on endpoints, and treat any unexplained process interacting with credential-handling components as worth investigating. In environments Capstone manages, SentinelOne is where that first-stage foothold surfaces, because the attacker's code has to live in the normal world before it can reach anything isolated. Your detection strategy needs an honest note in it. Code executing inside an enclave is not visible to an endpoint agent by design, so detection has to concentrate on the normal-world side of the boundary: which processes load enclave libraries, which callers invoke enclave entry points, and whether the same initialization routine is being called more than once in a pattern no legitimate application produces. Document that limitation in your detection coverage matrix so nobody assumes endpoint telemetry covers a region it cannot see. The longer-term item is the one that outlives this CVE. Windows maintains a blocklist for vulnerable drivers but has no equivalent general blocklist for vulnerable enclaves, and the September policy only blocks the old SFAPE file. An older Microsoft Edge enclave carrying a similar read-and-write flaw, **CVE-2023-36880** from 2023, is still allowed to load. That keeps the "bring your own vulnerable enclave" technique available, the same approach earlier research from Akamai and Outflank used to hide code and data from security tooling. Practically, that means inventorying which signed enclave libraries are present and loadable on your builds, and using application control to restrict loading where your software stack does not require them. It also means adding VBS and enclave advisories to whatever list you already review for monthly patch triage, since a signed library with a known flaw remains a usable component until Microsoft explicitly blocks it. Treat enclave attestation as one control among several rather than a trust anchor your architecture rests on. Remediation sequence for the SFAPE enclave flaw 1 Pull a patch management report for the cumulative update across all Windows 11 endpoints. There is no workaround or configuration change that substitutes for installing it.KB5124008High 2 Flag machines still reporting pre-patch builds. Hosts that no longer receive cumulative updates will never get the policy that blocks the vulnerable enclave from loading.High 3 Enclave protections exist only where the hypervisor enforces the VTL split. Check for drifted or disabled virtualization-based security on older imaged hardware.Medium 4 The exploit needs low-privileged code already running. Trim standing local administrator rights and restrict unsigned binary execution on endpoints.Medium 5 Enclave code is invisible to endpoint agents by design. Monitor which processes load enclave libraries, which callers invoke entry points, and repeated initialization calls.SentinelOneMedium ## Key Takeaways for Security Teams The lesson worth carrying forward is about primitive size. A single fixed four-byte error value written to a caller-controlled address was enough to defeat a hypervisor-enforced boundary, and Doyensec themselves said calling that an arbitrary write "would be a huge overstatement." If your vulnerability triage ranks findings by how powerful the initial bug looks, this is a useful correction: the starting primitive is a poor predictor of where the chain ends. The second point is about how flawed signed code ages. Windows maintains a blocklist for vulnerable drivers, but it has no general equivalent for enclaves, and the policy shipped in September blocks only the one old SFAPE file. **CVE-2023-36880**, a read-and-write flaw in an older Microsoft Edge enclave from 2023, still loads. Earlier work from Akamai and Outflank showed that loading a signed but flawed enclave, sometimes called "bring your own vulnerable enclave," hides attacker code and data from security tooling. Blocking one file while leaving the other loadable keeps that option open to anyone who already has execution on your hosts. Context should temper how high you rank this. Microsoft says it found the same issue internally, that it was not publicly known before the fix, and that it has not been exploited. Doyensec published on October 13, more than a month after the update shipped, so your exposure window was never the kind that forces out-of-band work. The action is narrow. Confirm patch coverage for CVE-2026-83498 and CVE-2023-36880 across your Windows 11 estate, then write down in your threat model what you actually assume a VBS enclave provides, rather than treating that isolation as settled. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-10-14T12:37:21Z", "datePublished": "2026-10-14T12:37:21Z", "description": "Doyensec chained a four-byte write in SmartScreen's SFAPE.dll enclave to run code in VTL1. Microsoft fixed CVE-2026-83498 in KB5124008; verify patching.", "headline": "Four-Byte Write Bug Lets Researchers Run Code in Windows SmartScreen Enclave", "image": [ { "@type": "ImageObject", "url": "https:\/\/images.captechgroup.com\/cdn-cgi\/image\/width=1200,format=webp,quality=85\/threat-intel\/ad274ab2a2.jpg", "caption": "", "description": "Isometric diagram of Windows VBS enclave isolation broken by CVE-2026-83498 SmartScreen enclave flaw", "width": 1200, "height": 685 } ], "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/four-byte-write-bug-lets-researchers-run-code-in-w-30bd88" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/four-byte-write-bug-lets-researchers-run-code-in-w-30bd88" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "", "streetAddress": "", "addressCountry": "US" } ] } ```