karollooool/cve-2026-83991-writeup-and-pocProof-of-concept demonstrating a Windows Cloud Files access-check bypass (CVE-2026-83991) that converts a read-only file into a cloud placeholder via supersede semantics, with detailed technical analysis and reproduction steps.
CVE-2026-83991 is a Windows Cloud Files tampering vulnerability whose published affected range begins with Windows 10 version 1809, almost eight years before the September 2026 fix.
I asked Windows to open a file for writing. It answered ERROR_ACCESS_DENIED.
I asked Windows to delete the same file. Again, ERROR_ACCESS_DENIED.
Then I asked the Cloud Files stack to supersede that filename. It returned S_OK and changed the existing file into a Cloud Files placeholder.
The file had said no twice. The supersede path heard something closer to “please continue.”
That authorization split is CVE-2026-83991. Microsoft calls it the Windows Cloud Files Mini Filter Driver Tampering Vulnerability, rates it Important, and assigned a CVSS 3.1 base score of 5.5 Medium. The official vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N/E:U/RL:O/RC:C.
The proof of concept creates a fresh directory and an ordinary file. It gives the caller write access to the directory, then applies a protected DACL to the file that grants the caller read access without ordinary write or delete access.
Using one restricted medium-integrity thread token, it proves the following sequence:
| Operation | Result |
|---|---|
Open the existing file with GENERIC_WRITE | ERROR_ACCESS_DENIED |
Delete it with DeleteFileW | ERROR_ACCESS_DENIED |
Open it with GENERIC_READ | Success |
| Register and connect the parent as a sync root | S_OK |
Call CfCreatePlaceholders with supersede semantics | S_OK |
| Inspect the resulting entry | Cloud reparse point |
The call processed one entry, returned a nonzero creation USN, and gave the file the IO_REPARSE_TAG_CLOUD tag, value 0x9000001A. In the reproduced run, the file ID was identical before and after the call. The same NTFS file persisted while its state changed into a cloud placeholder.
Windows 10 version 1709 introduced the Cloud Files API. It gives desktop sync engines a supported way to register a directory tree, create placeholder entries, and hydrate their content when needed.
Three pieces matter here:
CldApi.dll exposes the user-mode Cloud Filter API.cldflt.sys is the file-system minifilter at the center of the storage path.Cloud placeholders use reparse points. A reparse point is a file-system mechanism with a tag and associated data. It is a broader concept than a symbolic link, and the two should not be treated as synonyms.
The relevant API is CfCreatePlaceholders. It creates one or more placeholder files or directories beneath a registered sync root. Microsoft’s documentation says the caller must have WRITE_DATA or WRITE_DAC access to the base directory.
The per-entry flag CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE, value 0x4, supplies overwrite semantics for an existing placeholder. The interesting detail in this CVE is that the vulnerable path also accepted an ordinary existing file and converted it into a placeholder.
The experiment separates rights on the directory from rights on the existing file.
The parent directory grants the current user:
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
DELETE
For a directory, FILE_GENERIC_WRITE includes FILE_WRITE_DATA, also called FILE_ADD_FILE. That is enough for the documented base-directory requirement used by CfRegisterSyncRoot and CfCreatePlaceholders.
The parent ACE does not grant FILE_DELETE_CHILD. Its DELETE bit applies to the parent object itself. This distinction matters because DeleteFileW requires either DELETE on the target file or FILE_DELETE_CHILD on its parent.
The existing leaf grants the current user only FILE_GENERIC_READ. Its DACL is marked protected with PROTECTED_DACL_SECURITY_INFORMATION, so it does not inherit the parent’s ACEs.
This creates the central question:
Does permission to create a new child in a directory also authorize a state-changing supersede operation against a more restrictive child that already exists?
Ordinary file access answers no. The vulnerable Cloud Files path answered yes.
Microsoft’s file security documentation explains why the distinction is expected. Access to a file is normally controlled by that file’s security descriptor. The parent’s descriptor does not generally replace the child’s access check, apart from specific rules such as inheritance and FILE_DELETE_CHILD.
Access-control demonstrations become unconvincing when the setup runs as one identity and the interesting operation runs as another. This PoC avoids that problem.
It derives a restricted token from the current process token, makes the Administrators SID absent or deny-only, sets medium integrity, duplicates an impersonation token at SecurityImpersonation, and installs it on the current thread with SetThreadToken.
The exact privilege wording deserves care. CreateRestrictedToken with DISABLE_MAX_PRIVILEGE disables every privilege except SeChangeNotifyPrivilege. That remaining privilege bypasses some directory traversal checks. It does not grant file data writes or deletion rights.
The PoC then performs the setup, control checks, sync-root registration, connection, and supersede call while that same thread impersonation token remains active. There is no convenient identity swap between “access denied” and S_OK.
The full source is in main_poc.c, with build.bat for GCC or Microsoft’s C compiler.
The program creates a new GUID-named test directory beneath the current user’s local application-data directory. An optional path can be supplied, but the program refuses to use one that already exists.
That restriction is deliberate. The PoC demonstrates the bug against data it creates for itself. It does not need an installed third-party sync provider and does not aim at an existing sync root.
The program creates protected_existing.bin, writes known test data, and gives it ordinary file attributes. It records the file’s basic metadata, logical size, attributes, and file ID.
Before the Cloud Files call, the file is not a reparse point.
The program replaces the leaf DACL with three non-inheriting allow ACEs:
| Principal | Leaf rights |
|---|---|
SYSTEM | Full control |
Administrators | Full control |
| Current user | FILE_GENERIC_READ |
Because the Administrators SID in the effective token is absent or deny-only, the Administrators allow ACE cannot grant administrator access to the thread.
The PoC then performs three controls. GENERIC_WRITE fails with error 5, DeleteFileW fails with error 5, and GENERIC_READ succeeds. It also confirms that the DACL is protected.