CVE-2026-68896: local privilege escalation in the Windows Search component

Why a user’s catalogue became our target

After the CBS work, we looked for the same kind of identity mismatch in a different Windows service: code that handles one user’s files safely in one place but forgets that user’s identity elsewhere. Windows Search maintains a separate catalogue for each user on multi-session hosts. That made its logon lifecycle more interesting than ordinary indexing: a cleanup running as SearchIndexer.exe could touch a path inside an unprivileged user’s profile.

We compared the two routes in mssrch.dll. The crawl/access-check route impersonated the user. The catalogue cleanup reached from the logon notification did not; it kept the service’s SYSTEM identity while recursively removing catalogue contents. This was a promising code difference, but our first question was whether the route was even active on a real host. The EnablePerUserCatalog registry value looked like a feature switch. Static analysis showed that, when the value is absent, the code falls back to a Windows suite check and enables per-user catalogues on genuine multi-session systems by default. We verified that gate on RDS Session Hosts, rather than assuming it from a registry screenshot.

That check itself caused a false negative. A PowerShell reproduction of VerifyVersionInfoW reported the wrong suite state because of the host’s version behaviour. A native probe, which matched how mssrch.dll checks the suite mask, showed the Terminal Server bit set and the single-user bit clear. The difference mattered: we could not publish “default-on for RDS” from the PowerShell output alone.

We proved the deletion before chasing SYSTEM code execution

The path came from the user’s profile, and the cleanup could be retriggered by that same user’s interactive logon. We prepared a redirected catalogue path and the relevant value in the user’s own hive. Before logging on, we put a canary file in a directory whose ACL allowed SYSTEM and administrators, but not the standard user. We tried deleting that file as the user and got Access denied. At the next genuine logon, Search’s SYSTEM cleanup deleted the file. The enclosing directory remained. That distinction told us exactly what primitive we had: deletion of contents under a redirected directory, not an arbitrary top-level directory deletion on that first test.

Even the logon needed a precise control. A disconnected RDP session kept the catalogue database open; the path was not free to replace. Fully logging the user off, then logging back on, released the handles and triggered the lifecycle again. A failed run with a merely disconnected session would have been a lab-state error, not evidence that the code was safe.

A SYSTEM file deletion can sometimes be turned into code execution through other Windows mechanisms. We developed and exercised such a conversion, but it was more conditional than the deletion bug. On a stripped-down Server test image, the required Windows Installer state was not available to the non-admin driver in the same way as on a populated client. In the 7 June fresh-install replay, the staging and logon trigger for the protected delete were non-admin, while the automation of the later conversion ran elevated for headless lab orchestration. The resulting proof recorded a SYSTEM token, but that run alone must not be described as an entirely non-admin-operated end-to-end execution chain. Earlier lab runs tested the conversion under other states; the primitive we can attribute without that qualification is the protected delete at low privilege.

Why we rebuilt the laboratory

We did not want an old Windows image, a leftover catalogue or a registry override to explain the result. On 7 June we reinstalled Server 2025 as an RDS Session Host, rebuilt the PoC from source, confirmed that Defender real-time protection was on, and checked that no EnablePerUserCatalog override was present. The low-privilege account again failed to delete the canary directly, then Search removed it on that account’s next logon. We recorded the native gate result and the before/after file state separately. That clean replay made the core finding stronger; it did not erase the conversion caveat.

We sent Microsoft the code path, low-privilege proof and the conditions for the code-execution follow-on. After Microsoft published CVE-2026-68896 on 8 September, we replayed the original route on fixed Windows 11 25H2 build 26200.9445: one entry returned 0x80070005, and a separate catalogue trigger reached its consumer without removing the protected target. We kept both observations because a denied call by itself says little about what a reached cleanup would do.

The published scope

Microsoft’s advisory calls the flaw an absolute path traversal (CWE-36), scores it 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and credits our researcher for the work. At publication Microsoft assessed exploitation as less likely and did not report observed exploitation. The catalogue and lab details above come from our research, not from the short vendor notice. A single-user workstation did not enable this catalogue mode by default in our tests; the multi-session gate is central to understanding the discovery.

Affected builds and action

Product	First fixed build	Update
Windows 11 23H2	22631.7582	KB5122880
Windows 11 24H2 / 25H2	26100.9445 / 26200.9445	KB5124008
Windows 11 26H1	28000.2954	KB5124012
Windows Server 2022	20348.5622	KB5122882
Windows Server 2025	26100.33438	KB5122871

Install the applicable September 2026 update or a later cumulative update, especially on RDS and other hosts where mutually untrusted users share a machine. This is a local low-privilege starting point, not a remotely exploitable Search endpoint. We have not published the full exploit path, so a generic alert on Search file operations is not a reliable signature; preserve process and filesystem evidence around a suspected elevation.

Timeline

Date	What we established
Late May 2026	Compared impersonated catalogue access with SYSTEM logon cleanup and established the multi-session gate
7 June 2026	Rebuilt the lab; low-privilege logon deleted a protected file while the containing directory survived
June 2026	Documented the more conditional delete-to-execution conversion and sent the case to MSRC
8 September 2026	Microsoft published CVE-2026-68896 and the fix
9 September 2026	Original route and a reached-catalogue negative control tested on 26200.9445