我把这些行放在一起，因为把它们分开会让这个漏洞看起来比实际更复杂：
CreateFileW, GENERIC_WRITE error 5
DeleteFileW error 5
CfCreatePlaceholders, SUPERSEDE S_OK
per-entry Result S_OK
写入打开、删除尝试和 Cloud Files 调用使用相同的路径名和相同的线程令牌。在最后一次调用之前，该名称属于一个具有受保护 DACL 且没有重解析点的普通文件。之后，FSCTL_GET_REPARSE_POINT 返回 IO_REPARSE_TAG_CLOUD。
Microsoft 将该结果发布为 CVE-2026-83991，即 Windows Cloud Files 微筛选器驱动程序篡改漏洞。我在报告中将其描述为不正确的授权，并建议归类为 CWE-863。Microsoft 则将其分配为 CWE-306。
该程序在创建测试目录、文件、DACL 或同步根之前，先安装其受限模拟令牌。并不存在先提升权限、再仅为那个关键调用切换令牌的情况。如果账户具有 Administrators SID，CreateRestrictedToken 会将其设为仅拒绝；如果该 SID 从未存在，程序也会记录该情况。完整性级别设置为 Medium。
父目录和叶文件故意不具有匹配的 DACL。当前用户在目录上获得以下权限：
FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE
现有文件获得 FILE_GENERIC_READ，并且其 DACL 受到保护，不会继承。SYSTEM 和 Administrators 保留完全控制权。由于令牌中的 Administrators SID 不存在或仅为拒绝，Administrators 允许 ACE 无法为此线程授予访问权限。
父目录上的 DELETE 位看起来可疑，直到明确它所适用的对象。它允许删除目录本身。删除其子项需要 FILE_DELETE_CHILD，这是父 ACE 中不包含的另一个位。DeleteFileW 接受叶文件上的 DELETE 或父目录上的删除子项权限。该测试两者都不具备，这就是为什么错误 5 是预期的控制结果。
我在父目录上保留了 FILE_GENERIC_WRITE。当对象是目录时，其 FILE_WRITE_DATA 位即为 FILE_ADD_FILE。调用者可以创建子项，因此父目录满足 CfCreatePlaceholders 所记录的 WRITE_DATA 或 WRITE_DAC 要求。如果没有该权限，API 会在到达我所报告的案例之前就未通过其基目录检查。
除非此代码块为真，否则程序不会注册同步根：
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
我让它在此处停止，因为如果叶文件已经可写、可删除或是一个重解析点，那么运行后期出现 S_OK 将毫无意义。
在这些控制之后，程序将父目录注册为同步根，使用仅包含终止项的回调表将其连接，并以标志 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 被记录为覆盖现有占位符。此文件并非占位符。PoC 在应用叶 DACL 之前设置 FILE_ATTRIBUTE_NORMAL，并在调用 Cloud Files 之前确认重解析点位已清除。
在受影响的系统上，批量调用和条目均返回 S_OK，且 CreateUsn 非零。该文件获得了重解析点属性。向文件系统请求重解析数据返回标签 0x9000001A，即 IO_REPARSE_TAG_CLOUD。
EntriesProcessed == 1 并不能证明成功，因为 API 文档也将失败的条目计入其中。确认来自两个 HRESULT、创建 USN、重解析属性以及 Cloud 标签。
FILE_ID_INFO 在调用前后保持不变。现有文件对象获得了 Cloud Files 状态；并非只是另一个文件出现在同一路径名下。
MSRC 列出的最早受影响版本是 17763.0，即 Windows 10 版本 1809 和 Windows Server 2019 世代。这将公开线索置于 2018 年，比 2026 年 9 月的修复早了近八年。