Microsoft Recall Flaw Risks Decrypted User Data Exposure, Researchers Warn

Microsoft’s reintroduction of its redesigned Recall feature aimed to enhance security through a robust architecture. This framework incorporates hardened components such as Virtualization-Based Security (VBS) enclaves, AES-256-GCM encryption, Windows Hello authentication, and a Protected Process Light (PPL) host. However, recent findings from security research indicate that while the system’s vault may be secure, the handling of decrypted data presents significant vulnerabilities.

A Strong Core with a Fragile Edge

The encryption model employed by Recall is fundamentally sound. Data is stored within a secure enclave, ensuring that cryptographic keys remain confined within its boundaries. The implementation of AES-256-GCM encryption guarantees both confidentiality and integrity. Yet, the vulnerability does not stem from data storage; rather, it arises from the management of decrypted data once it exits the secure enclave.

The process responsible for rendering Recall’s timeline, AIXHost.exe, lacks the protective measures found in other components. Unlike aihost.exe, which operates under PPL, AIXHost.exe functions without PPL enforcement, AppContainer isolation, or stringent code integrity checks. This creates a critical vulnerability, allowing other processes running under the same user account to interact with it.

Once a user authenticates through Windows Hello, decrypted Recall data begins to flow through AIXHost.exe. At this point, the system implicitly trusts everything within that process, regardless of whether it is legitimate or malicious.

How TotalRecall Exploits the Gap

The research tool TotalRecall Reloaded capitalizes on this trust boundary issue. It employs a classic DLL injection technique to embed itself into AIXHost.exe. The tool comprises two components: an injector (totalrecall.exe) and a payload DLL (totalrecall_payload.dll).

Using standard Windows APIs such as CreateToolhelp32Snapshot, VirtualAllocEx, WriteProcessMemory, and LoadLibraryW, it injects code into the target process. Notably, this attack does not require administrative privileges or kernel exploits; it relies entirely on user-level permissions and legitimate system functionality. This is particularly concerning, as Windows allows processes under the same user to interact freely by default.

Authentication: Timing Instead of Bypassing

TotalRecall Reloaded does not bypass Windows Hello; instead, it waits for authentication to occur naturally or triggers it indirectly. In “launch” mode, it simulates the Win+J shortcut, prompting the user to authenticate. Once authenticated, decrypted data becomes accessible. In “stealth” mode, the tool modifies the DiscardDataAccess function to ensure access is never revoked after Recall closes. It then waits for normal user activity to begin extraction silently, without triggering another authentication prompt.

A third mode, “wait,” simply monitors for Recall activity and acts once authentication occurs.

What Data Gets Extracted

Once embedded, the payload utilizes Recall’s internal COM interfaces to extract various types of data, including:

• Full-resolution screenshots (PNG format)
• OCR text, including lines and individual words with pixel-level bounding boxes
• Metadata such as application names, URLs, timestamps, and window dimensions
• Named entities like people, locations, and email addresses
• AI-generated activity descriptions

Recall captures data at regular intervals, constructing a detailed behavioral profile stored in an encrypted SQLite database (ukg.db) protected by AES-256-GCM encryption. The default retention period is 90 days, with a storage limit of 75 GB. This dataset encompasses everything from browser activity and document edits to terminal commands and messaging conversations, all fully indexed and searchable.

Pre-Authentication Concerns

Certain functions exposed by Recall do not require Windows Hello authentication. For instance, GetRecentCaptureThumbnail can return a full-resolution screenshot simply by requesting a larger size. Similarly, IDataStoreManager::DeleteEvents allows complete deletion of the recall history without authorization checks.

Additional metadata, such as storage paths, database size, and capture counts, can also be accessed without authentication. Microsoft’s design assumes that data remains secure within the enclave and PPL-protected processes. However, once decrypted data reaches AIXHost.exe, that assumption is compromised.

There is no verification of which code is making requests inside AIXHost.exe. Whether it is legitimate UI logic or injected malware, the system treats all requests equally. This effectively ends the trust boundary prematurely, leaving decrypted data exposed.

Inconsistent Access Controls

Further complications arise from inconsistent protections within COM interfaces. Some methods enforce access restrictions correctly, returning errors when accessed without authorization. Others, such as alternate interface versions, permit access to the same data without checks. This inconsistency enables attackers to bypass intended safeguards by invoking different interfaces.

Once Windows Hello authentication is completed, the authenticated state is cached in the PPL-protected aihost.exe for the entire Windows session. Restarting AIXHost.exe does not reset this state. By patching the DiscardDataAccess function, TotalRecall Reloaded ensures that access persists indefinitely. Even after Recall is closed, the tool can reinject itself and continue extracting data without further prompts or user awareness.

The Bigger Picture

The underlying technologies of Recall—VBS enclaves, AES-256-GCM encryption, TPM-backed keys, and Windows Hello—are implemented correctly. The issue does not lie in cryptographic weakness or flawed authentication but rather in the decision to pass decrypted data into a process that lacks equivalent protections.

In essence, while the vault remains secure, its contents are left unguarded once exposed. This research was submitted to the Microsoft Security Response Center (MSRC) on March 6, 2026. After review, the case (109586) was closed on April 3, 2026, as “Not a Vulnerability.” Microsoft stated that the observed behavior aligns with the system’s documented security design.

Tested Environment

• OS: Windows 11 25H2 (Build 26300.8155)
• Architecture: ARM64
• AIXHost.exe version: 2126.7602.0.0
• Privilege level: Standard user (medium integrity, no elevation)

Source: thecyberexpress.com

Keep reading for the latest cybersecurity developments, threat intelligence and breaking updates from across the Middle East.