TotalRecall Reloaded: encrypted storage and authorized data delivery differ

Alexander Hagenah's April 2026 TotalRecall Reloaded report concerns access to data delivered for Windows Recall's interface after authorization. It is not presented by the author as a break of the encrypted vault's cryptography. Microsoft disputed that the demonstrated access crossed a security boundary.

The distinction corrects this article's earlier account, which substituted a broad story about capture caches, temporary files and sidecar artifacts for the mechanism actually documented. This is an explanation of the reported case and the current documented controls, not a new exploit reproduction by UnliveNews.

The researcher’s claim has prerequisites

The project's primary README identifies AIXHost.exe, the process rendering the Recall timeline, as the relevant delivery point. It describes code already running as the logged-in user and access to screenshots, recognized text and metadata after Windows Hello authorization.

That is a different claim from an unauthenticated remote party decrypting the full database from anywhere. The local execution context and authorization state are part of the report, not details that can be dropped from a headline.

The author separately describes limited pre-authorization operations. Those should not be merged with the broader post-authorization claim as if they demonstrate the same access under the same conditions. This article does not provide operating instructions for the proof of concept or claim to have run it.

A vendor classification and a privacy concern can coexist

The project's disclosure timeline says the report was submitted on March 6 and closed by MSRC on April 3 as not a vulnerability. Andrew Cunningham's Ars Technica coverage includes Microsoft's response disputing a security-boundary bypass and referring to authorization controls.

That classification is an attributed vendor position, not an independent guarantee that capturing a history of screen content is appropriate in every context. Conversely, disagreeing with the product's privacy trade-off does not prove a cryptographic failure.

The useful question is which claim is being evaluated. A defined boundary, an authorized access path and a user's willingness to collect sensitive content are related considerations, but evidence about one does not automatically answer the others.

Microsoft documents opt-in and separate filters

Microsoft's current support page says snapshot saving is not enabled by default. It describes Windows Hello authentication and encrypted snapshots and search information. It also identifies app and website filters and sensitive-information filtering, enabled by default.

The website-filtering capability depends on browser support. Microsoft distinguishes browsers that support specific-site filtering from other Chromium-based browsers that filter private sessions but not individual sites. A generic instruction to exclude every work browser profile would therefore overstate the documented control.

These are vendor-described controls, not an independent validation of every build. This revision makes no claim that the April proof of concept still works unchanged on the latest November software, or that a later patch has resolved every reported behaviour.

Stopping capture, deleting history and resetting are different actions

Microsoft describes a pause-until-tomorrow action that resumes at midnight. Its reset documentation says Reset Recall removes saved snapshots and resets settings, but does not remove copies previously exported or saved by third parties.

That distinction matters when evaluating a claim that data has been removed. Stopping future collection does not, by itself, establish what happened to previous copies. Resetting the original store likewise cannot demonstrate removal of an earlier export elsewhere.

The old article recommended clearing temporary directories and thumbnail caches as additional assurance. It provided no test showing that those steps addressed the reported delivery mechanism. That advice has been removed rather than presented as a verified mitigation.

A useful assessment needs the build and the evidence

The article also removes invented file-monitoring indicators, service-disablement fallbacks and blanket compliance prescriptions. A general recommendation cannot substitute for documented policy behaviour on a particular managed Windows configuration.

For interpretation, retain the version, execution context, authorization condition and data category attached to any test result. A successful demonstration under one set of conditions is not evidence that every possible access route works, and a failed attempt on another system is not proof of universal protection.

The supported lesson from this case is specific: protecting stored data and controlling its delivery during authorized use are different parts of a design. Accurate coverage can explain that relationship, preserve the researcher's and vendor's differing assessments, and avoid inventing either a universal bypass or an untested cleanup cure.

Sources

Researcher's primary report and disclosure timeline: https://github.com/xaitax/TotalRecall

Microsoft Recall documentation: https://support.microsoft.com/en-us/windows/ai/ai-features/retrace-your-steps-with-recall

Original reporting: https://arstechnica.com/gadgets/2026/04/totalrecall-reloaded-tool-finds-a-side-entrance-to-windows-11s-recall-database/