CVE-2026-83991 : remplacer un fichier que l'appelant ne peut pas supprimer

J'ai gardé ces lignes côte à côte parce que les séparer fait paraître le bug plus compliqué qu'il ne l'est :

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

L'ouverture en écriture, la tentative de suppression et l'appel Cloud Files utilisent le même nom de chemin et le même jeton de thread. Avant le dernier appel, le nom appartient à un fichier ordinaire avec une DACL protégée et sans point d'analyse. Après, FSCTL_GET_REPARSE_POINT renvoie IO_REPARSE_TAG_CLOUD.

Microsoft a publié ce résultat sous CVE-2026-83991, la vulnérabilité d'altération du pilote de minifiltre Windows Cloud Files. Je l'avais décrite dans le rapport comme une autorisation incorrecte et suggéré CWE-863. Microsoft a attribué CWE-306 à la place.

Le programme installe son jeton d'emprunt d'identité restreint avant de créer le répertoire de test, le fichier, les DACL ou la racine de synchronisation. Il n'y a pas de configuration élevée suivie d'un changement de jeton uniquement pour l'appel intéressant. Si le compte possède un SID Administrators, CreateRestrictedToken le rend deny-only ; si le SID n'était jamais présent, le programme enregistre aussi ce cas. L'intégrité est définie à Medium.

Le parent et la feuille n'ont délibérément pas de DACL correspondantes. L'utilisateur actuel reçoit ceci sur le répertoire :

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

Le fichier existant reçoit FILE_GENERIC_READ, et sa DACL est protégée contre l'héritage. SYSTEM et Administrators conservent le contrôle total. Comme le SID Administrators du jeton est absent ou deny-only, l'ACE d'autorisation Administrators ne peut pas accorder l'accès à ce thread.

Le bit DELETE sur le parent semble suspect jusqu'à ce que l'objet auquel il s'applique soit rendu explicite. Il permet la suppression du répertoire lui-même. Supprimer l'un de ses enfants est FILE_DELETE_CHILD, un bit différent que l'ACE parent ne contient pas. DeleteFileW accepte soit DELETE sur la feuille, soit la permission delete-child sur le parent. Le test n'a ni l'un ni l'autre, c'est pourquoi l'erreur 5 est le résultat de contrôle attendu.

J'ai laissé FILE_GENERIC_WRITE sur le parent. Son bit FILE_WRITE_DATA est FILE_ADD_FILE lorsque l'objet est un répertoire. L'appelant peut créer un enfant, et le parent satisfait donc à l'exigence documentée WRITE_DATA ou WRITE_DAC pour CfCreatePlaceholders. Sans ce droit, l'API échoue à sa vérification du répertoire de base avant d'atteindre le cas que j'ai signalé.

Le programme n'enregistrera pas la racine de synchronisation à moins que ce bloc soit vrai :

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

Je l'ai fait s'arrêter là parce qu'un S_OK plus tard dans l'exécution serait inutile si la feuille avait déjà été accessible en écriture, supprimable ou un point d'analyse.

Après ces contrôles, le programme enregistre le parent comme racine de synchronisation, le connecte avec une table de rappel contenant uniquement l'entrée de terminaison, et soumet le nom de fichier existant avec le 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 est documenté comme écrasant un placeholder existant. Ce fichier n'en est pas un. Le PoC définit FILE_ATTRIBUTE_NORMAL avant d'appliquer la DACL de la feuille et confirme que le bit de point d'analyse est effacé avant d'appeler Cloud Files.

Sur le système affecté, l'appel par lots et l'entrée ont tous deux renvoyé S_OK, et CreateUsn était non nul. Le fichier a acquis l'attribut de point d'analyse. Demander les données de point d'analyse au système de fichiers a renvoyé le tag 0x9000001A, qui est IO_REPARSE_TAG_CLOUD.

EntriesProcessed == 1 ne prouve pas le succès car la documentation de l'API compte aussi les entrées échouées. La confirmation vient des deux HRESULT, de l'USN de création, de l'attribut de point d'analyse et du tag Cloud.

FILE_ID_INFO était inchangé pendant l'appel. L'objet fichier existant a acquis l'état Cloud Files ; un autre fichier n'est pas simplement apparu sous le même nom de chemin.

La plus ancienne build affectée listée par MSRC est 17763.0, la génération Windows 10 version 1809 et Windows Server 2019. Cela place la trace publique en 2018, presque huit ans avant le correctif de septembre 2026.