CVE-2026-83991: superseding a file that the caller cannot delete

I kept these lines next to each other because separating them makes the bug look more complicated than it is:

CreateFileW, GENERIC_WRITE             error 5
DeleteFileW                            error 5
CfCreatePlaceholders, SUPERSEDE        S_OK
per-entry Result                       S_OK

The write open, delete attempt, and Cloud Files call use the same pathname and the same thread token. Before the last call, the name belongs to an ordinary file with a protected DACL and no reparse point. After it, FSCTL_GET_REPARSE_POINT returns IO_REPARSE_TAG_CLOUD.

Microsoft published that result as CVE-2026-83991, the Windows Cloud Files Mini Filter Driver Tampering Vulnerability. I had described it in the report as incorrect authorization and suggested CWE-863. Microsoft assigned CWE-306 instead.

The program installs its restricted impersonation token before it creates the test directory, file, DACLs, or sync root. There is no elevated setup followed by a token switch just for the interesting call. If the account has an Administrators SID, CreateRestrictedToken makes it deny-only; if the SID was never present, the program records that case too. Integrity is set to Medium.

The parent and leaf deliberately do not have matching DACLs. The current user receives this on the directory:

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

The existing file receives FILE_GENERIC_READ, and its DACL is protected from inheritance. SYSTEM and Administrators retain full control. Because the token's Administrators SID is absent or deny-only, the Administrators allow ACE cannot grant access to this thread.

The DELETE bit on the parent looks suspicious until the object it applies to is made explicit. It permits deletion of the directory itself. Deleting one of its children is FILE_DELETE_CHILD, a different bit that the parent ACE does not contain. DeleteFileW accepts either DELETE on the leaf or delete-child permission on the parent. The test has neither, which is why error 5 is the expected control result.

I left FILE_GENERIC_WRITE on the parent. Its FILE_WRITE_DATA bit is FILE_ADD_FILE when the object is a directory. The caller may create a child, and the parent therefore meets the documented WRITE_DATA or WRITE_DAC requirement for CfCreatePlaceholders. Without that right, the API fails its base-directory check before reaching the case I reported.

The program will not register the sync root unless this block is true:

write open denied with ERROR_ACCESS_DENIED
DeleteFileW denied with ERROR_ACCESS_DENIED
read open succeeded
leaf DACL protected
starting object not a reparse point

I made it stop there because an S_OK later in the run would be useless if the leaf had already been writable, deletable, or a reparse point.

After those controls, the program registers the parent as a sync root, connects it with a callback table containing only the terminating entry, and submits the existing filename with flag 0x4:

placeholder.RelativeFileName = leaf_name;
placeholder.FsMetadata.BasicInfo = basic_info;
placeholder.FsMetadata.FileSize = standard_info.EndOfFile;
placeholder.FileIdentity = &run_id;
placeholder.FileIdentityLength = sizeof(run_id);
placeholder.Flags = CF_CREATE_SUPERSEDE;

create_hr = cf.Create(root, &placeholder, 1, 0, &processed);

CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE is documented as overwriting an existing placeholder. This file is not one. The PoC sets FILE_ATTRIBUTE_NORMAL before applying the leaf DACL and confirms that the reparse-point bit is clear before calling Cloud Files.

On the affected system, the batch call and the entry both returned S_OK, and CreateUsn was nonzero. The file acquired the reparse-point attribute. Asking the file system for the reparse data returned tag 0x9000001A, which is IO_REPARSE_TAG_CLOUD.

EntriesProcessed == 1 does not prove success because the API documentation counts failed entries too. Confirmation comes from both HRESULTs, the creation USN, the reparse attribute, and the Cloud tag.

FILE_ID_INFO was unchanged across the call. The existing file object acquired Cloud Files state; another file did not merely appear under the same pathname.

MSRC's oldest listed affected build is 17763.0, the Windows 10 version 1809 and Windows Server 2019 generation. That puts the public trail in 2018, almost eight years before the September 2026 fix.