karollooool/cve-2026-83991-writeup-and-pocPreuve de concept démontrant un contournement de la vérification d'accès aux fichiers cloud Windows (CVE-2026-83991) qui convertit un fichier en lecture seule en espace réservé cloud via la sémantique de supersession, avec une analyse technique détaillée et des étapes de reproduction.
CVE-2026-83991 est une vulnérabilité de falsification de Windows Cloud Files dont la plage affectée publiée commence avec Windows 10 version 1809, près de huit ans avant le correctif de septembre 2026.
J'ai demandé à Windows d'ouvrir un fichier en écriture. Il a répondu ERROR_ACCESS_DENIED.
J'ai demandé à Windows de supprimer le même fichier. Encore une fois, ERROR_ACCESS_DENIED.
Puis j'ai demandé à la pile Cloud Files de remplacer ce nom de fichier. Elle a renvoyé S_OK et a transformé le fichier existant en espace réservé Cloud Files.
Le fichier avait dit non deux fois. Le chemin de remplacement a entendu quelque chose qui ressemblait plus à « veuillez continuer ».
Cette scission d'autorisation est CVE-2026-83991. Microsoft l'appelle la vulnérabilité de falsification du pilote mini-filtre Windows Cloud Files, la classe Importante et lui a attribué un score de base CVSS 3.1 de 5,5 Moyen. Le vecteur officiel est 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.
La preuve de concept crée un nouveau répertoire et un fichier ordinaire. Elle accorde à l'appelant un accès en écriture au répertoire, puis applique une DACL protégée au fichier qui accorde à l'appelant un accès en lecture sans accès ordinaire en écriture ou en suppression.
À l'aide d'un seul jeton de thread restreint à intégrité moyenne, elle prouve la séquence suivante :
L'appel a traité une entrée, a renvoyé un USN de création non nul et a attribué au fichier la balise IO_REPARSE_TAG_CLOUD, valeur 0x9000001A. Dans l'exécution reproduite, l'identifiant du fichier était identique avant et après l'appel. Le même fichier NTFS a persisté tandis que son état changeait en espace réservé cloud.
Windows 10 version 1709 a introduit l'API Cloud Files. Elle offre aux moteurs de synchronisation de bureau un moyen pris en charge d'enregistrer une arborescence de répertoires, de créer des entrées d'espaces réservés et d'hydrater leur contenu si nécessaire.
Trois éléments comptent ici :
CldApi.dll expose l'API Cloud Filter en mode utilisateur.cldflt.sys est le mini-filtre du système de fichiers au centre du chemin de stockage.Les espaces réservés cloud utilisent des points de réanalyse. Un point de réanalyse est un mécanisme du système de fichiers avec une balise et des données associées. C'est un concept plus large qu'un lien symbolique, et les deux ne doivent pas être traités comme des synonymes.
L'API pertinente est CfCreatePlaceholders. Elle crée un ou plusieurs fichiers ou répertoires d'espaces réservés sous une racine de synchronisation enregistrée. La documentation de Microsoft indique que l'appelant doit avoir un accès WRITE_DATA ou WRITE_DAC au répertoire de base.
L'indicateur par entrée CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE, valeur 0x4, fournit la sémantique d'écrasement pour un espace réservé existant. Le détail intéressant de ce CVE est que le chemin vulnérable acceptait également un fichier ordinaire existant et le convertissait en espace réservé.
L'expérience sépare les droits sur le répertoire des droits sur le fichier existant.
Le répertoire parent accorde à l'utilisateur actuel :
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
DELETE
Pour un répertoire, FILE_GENERIC_WRITE inclut FILE_WRITE_DATA, également appelé FILE_ADD_FILE. Cela suffit pour l'exigence documentée de répertoire de base utilisée par CfRegisterSyncRoot et CfCreatePlaceholders.
L'ACE du parent n'accorde pas FILE_DELETE_CHILD. Son bit DELETE s'applique à l'objet parent lui-même. Cette distinction compte car DeleteFileW exige soit DELETE sur le fichier cible, soit FILE_DELETE_CHILD sur son parent.
La feuille existante accorde à l'utilisateur actuel uniquement FILE_GENERIC_READ. Sa DACL est marquée protégée avec PROTECTED_DACL_SECURITY_INFORMATION, elle n'hérite donc pas des ACE du parent.
Cela crée la question centrale :
L'autorisation de créer un nouvel enfant dans un répertoire autorise-t-elle également une opération de remplacement modifiant l'état contre un enfant plus restrictif qui existe déjà ?
L'accès aux fichiers ordinaires répond non. Le chemin vulnérable de Cloud Files a répondu oui.
La documentation sur la sécurité des fichiers de Microsoft explique pourquoi la distinction est attendue. L'accès à un fichier est normalement contrôlé par le descripteur de sécurité de ce fichier. Le descripteur du parent ne remplace généralement pas le contrôle d'accès de l'enfant, à l'exception de règles spécifiques telles que l'héritage et FILE_DELETE_CHILD.
Les démonstrations de contrôle d'accès deviennent peu convaincantes lorsque la configuration s'exécute sous une identité et que l'opération intéressante s'exécute sous une autre. Cette preuve de concept évite ce problème.
Elle dérive un jeton restreint du jeton de processus actuel, rend le SID des administrateurs absent ou refus-seulement, définit une intégrité moyenne, duplique un jeton d'emprunt à SecurityImpersonation et l'installe sur le thread actuel avec SetThreadToken.
La formulation exacte des privilèges mérite une attention particulière. CreateRestrictedToken avec DISABLE_MAX_PRIVILEGE désactive tous les privilèges sauf SeChangeNotifyPrivilege. Ce privilège restant contourne certains contrôles de traversée de répertoire. Il n'accorde pas de droits d'écriture de données ou de suppression de fichiers.
La preuve de concept effectue ensuite la configuration, les contrôles, l'enregistrement de la racine de synchronisation, la connexion et l'appel de remplacement tandis que ce même jeton d'emprunt de thread reste actif. Il n'y a pas de changement d'identité pratique entre « accès refusé » et S_OK.
Le code source complet se trouve dans main_poc.c, avec build.bat pour GCC ou le compilateur C de Microsoft.
Le programme crée un nouveau répertoire de test nommé par GUID sous le répertoire de données d'application locales de l'utilisateur actuel. Un chemin facultatif peut être fourni, mais le programme refuse d'en utiliser un qui existe déjà.
Cette restriction est délibérée. La preuve de concept démontre le bug contre des données qu'elle crée elle-même. Elle n'a pas besoin d'un fournisseur de synchronisation tiers installé et ne vise pas une racine de synchronisation existante.
Le programme crée protected_existing.bin, écrit des données de test connues et lui donne des attributs de fichier ordinaires. Il enregistre les métadonnées de base du fichier, sa taille logique, ses attributs et son identifiant de fichier.
Avant l'appel Cloud Files, le fichier n'est pas un point de réanalyse.
Le programme remplace la DACL de la feuille par trois ACE d'autorisation non hérités :
| Principal | Droits de la feuille |
|---|---|
SYSTEM | Contrôle total |
Administrators | Contrôle total |
| Utilisateur actuel | FILE_GENERIC_READ |
Parce que le SID des administrateurs dans le jeton effectif est absent ou refus-seulement, l'ACE d'autorisation des administrateurs ne peut pas accorder un accès administrateur au thread.
La preuve de concept effectue ensuite trois contrôles. GENERIC_WRITE échoue avec l'erreur 5, DeleteFileW échoue avec l'erreur 5 et GENERIC_READ réussit. Elle confirme également que la DACL est protégée.
Ces contrôles prouvent les autorisations utilisées par les deux opérations ordinaires. La preuve de concept ne teste pas WRITE_DAC ni toutes les façons possibles dont le propriétaire de son fichier de test synthétique pourrait affecter ce fichier. La divergence démontrée concerne spécifiquement les opérations d'écriture et de suppression refusées et l'opération de remplacement Cloud Files réussie.
La preuve de concept enregistre son nouveau répertoire avec une politique d'hydratation progressive et une politique de population complète. Elle fournit un nouveau GUID comme identité du fournisseur et de la racine.
Elle appelle ensuite CfConnectSyncRoot avec une table de rappels contenant uniquement l'entrée terminale CF_CALLBACK_NONE. Aucun rappel d'hydratation n'est nécessaire pour la transition de métadonnées testée.
L'entrée d'espace réservé préserve les horodatages et la taille logique du fichier d'origine, fournit une identité de fichier GUID et définit la constante locale qui correspond à l'indicateur de remplacement officiel :
#define CF_CREATE_SUPERSEDE 0x00000004UL
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);
La source charge CldApi.dll dynamiquement et résout les fonctions publiques à l'exécution. Ses structures déclarées manuellement couvrent uniquement l'ABI nécessaire à ce test.
Une API par lots peut traiter une entrée qui a échoué. La documentation de Microsoft indique explicitement que EntriesProcessed inclut les entrées ayant échoué, donc une valeur de un n'établit pas le succès à elle seule.
La preuve de concept exige donc toutes ces conditions avant d'afficher CONFIRMED et de se terminer avec le code zéro :
CfCreatePlaceholders renvoie exactement S_OK.S_OK.FILE_ATTRIBUTE_REPARSE_POINT.FSCTL_GET_REPARSE_POINT renvoie IO_REPARSE_TAG_CLOUD.Les contrôles directs d'écriture, de suppression, de lecture, de DACL et de fichier préexistant doivent également réussir plus tôt dans le programme, sinon l'exécution s'arrête avant l'opération Cloud Files.
La transition d'état reproduite était :
0x00000020 est FILE_ATTRIBUTE_ARCHIVE. Le masque résultant 0x00401600 contient FILE_ATTRIBUTE_SPARSE_FILE, FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_OFFLINE et FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS.
L'identifiant de fichier inchangé est particulièrement utile. Il montre que, dans cette exécution, le résultat n'était pas simplement un fichier différent apparaissant au même chemin. L'objet fichier existant a survécu tout en acquérant l'état Cloud Files.
Le programme préserve la taille logique du fichier, mais il ne valide pas les octets d'origine après la conversion. Aucune affirmation sur le contrôle arbitraire du contenu ne découle de cette preuve de concept.
La défaillance observable peut être énoncée sans inventer une pile d'appels interne :
CfCreatePlaceholders accepte une demande de remplacement pour cette feuille.Ce comportement est cohérent avec un contrôle manquant ou incomplet contre la feuille existante sur le chemin de remplacement. Il n'identifie pas la fonction interne, la branche, l'IRP ou le rappel du noyau précis responsable. La preuve de concept ne contient aucun débogage du noyau ni analyse de différence binaire, donc l'explication s'arrête à la limite vérifiée de manière externe.
Microsoft a attribué CWE-306, Authentification manquante pour une fonction critique. Au niveau de l'objet Windows, l'expérience expose une application d'autorisation incohérente. J'utilise le CWE officiel de Microsoft dans les métadonnées et je décris le comportement de contrôle d'accès observé dans l'analyse technique.
La preuve de concept démontre un changement d'intégrité et d'état de fichier que les opérations directes testées ne pouvaient pas effectuer. Un appelant local à faibles privilèges disposant de l'accès requis au répertoire de base peut faire devenir une feuille existante en lecture seule un espace réservé Cloud Files via le chemin affecté.
L'avis de Microsoft donne l'impact produit plus large : un attaquant pourrait apporter des modifications non autorisées aux données système protégées et modifier l'état ou la configuration du système au-delà des privilèges normaux. C'est l'évaluation de Microsoft de la vulnérabilité. La preuve de concept isolée ne sélectionne pas une cible système protégée ni ne démontre une chaîne complète de post-exploitation.
Le vecteur CVSS reflète la même forme générale :
La réponse prudente est près de huit ans dans la plage affectée publiée par Microsoft.
L'enregistrement CVE officiel commence la branche affectée la plus ancienne à 10.0.17763.0 pour Windows 10 version 1809 et Windows Server 2019. L'historique des versions de Windows 10 de Microsoft liste la première version 1809, 17763.1, le 2 octobre 2018. Microsoft a publié le correctif le 8 septembre 2026.
Cela place le point confirmé le plus ancien dans la plage publique à un peu moins de huit ans avant le correctif.
L'API Cloud Files elle-même est arrivée avec Windows 10 version 1709 en 2017, et la documentation de l'API liste 1709 comme client minimal pris en charge. Cela ne prouve pas que cette vulnérabilité existait en 1709. L'enregistrement CVE de Microsoft ne liste pas 1709, et cette recherche ne l'a pas testée. L'anniversaire d'une API n'est pas automatiquement l'anniversaire d'un bug, aussi tentant que puisse être le titre.
Utilisez un système de test affecté sur NTFS. Exécutez la preuve de concept depuis une invite de commandes normale, non élevée.
build.bat
main_poc.exe
Le script de compilation utilise MinGW-w64 GCC lorsqu'il est disponible et revient au compilateur C de Microsoft. Le programme crée et enregistre sa propre racine de test vierge. Il désenregistre et déconnecte lors du nettoyage, puis laisse le répertoire de test en place pour inspection.
La forme facultative avec chemin est :
main_poc.exe C:\chemin\vers\un-nouveau-répertoire-de-test
Le chemin fourni ne doit pas déjà exister. Gardez le test isolé et supprimez son répertoire après avoir collecté les résultats.
Sur un système corrigé, la condition complète ne devrait pas atteindre CONFIRMED. N'inférez pas l'état du correctif à partir d'une seule ligne de console. Vérifiez ensemble le résultat global, le code de sortie, le résultat par entrée, l'USN, les attributs et la balise de réanalyse.
Les vulnérabilités Windows les plus intéressantes sont souvent des disputes sur l'objet auquel un contrôle d'accès se rapportait réellement.
Ici, l'autorisation de créer sous un répertoire a atteint un chemin qui pouvait transformer un enfant plus restrictif déjà présent à l'intérieur. Les API de fichiers ordinaires respectaient la DACL actuelle de cet enfant. Le remplacement Cloud Files n'a pas préservé la même frontière.
Aucune corruption de mémoire spectaculaire n'était requise. Un objet a dit non, un autre objet a fourni suffisamment d'autorité pour continuer, et un nom de fichier familier est devenu silencieusement autre chose.
C'est tout le truc. C'est aussi pourquoi le truc compte.
| Opération | Résultat |
|---|
Ouvrir le fichier existant avec GENERIC_WRITE | ERROR_ACCESS_DENIED |
Le supprimer avec DeleteFileW | ERROR_ACCESS_DENIED |
L'ouvrir avec GENERIC_READ | Succès |
| Enregistrer et connecter le répertoire parent comme racine de synchronisation | S_OK |
Appeler CfCreatePlaceholders avec la sémantique de remplacement | S_OK |
| Inspecter l'entrée résultante | Point de réanalyse cloud |
| Propriété | Avant | Après |
|---|
| Attributs | 0x00000020 | 0x00401600 |
| Point de réanalyse | Non | Oui |
| Balise de réanalyse | Aucune | 0x9000001A |
| Résultat de l'entrée | Sans objet | S_OK |
| USN de création | Sans objet | Non nul |
| Identifiant du fichier | Enregistré | Inchangé |