CVE-2026-83991: استبدال ملف لا يستطيع المستدعي حذفه

أبقيت هذه الأسطر متجاورة لأن فصلها يجعل الخطأ يبدو أكثر تعقيدًا مما هو عليه:

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 Mini Filter. كنت قد وصفتها في التقرير بأنها تفويض غير صحيح واقترحت CWE-863. لكن Microsoft خصصت CWE-306 بدلاً من ذلك.

يثبّت البرنامج رمز انتحال الهوية المقيّد الخاص به قبل إنشاء دليل الاختبار أو الملف أو DACLs أو جذر المزامنة. لا توجد تهيئة مرفوعة الصلاحيات يتبعها تبديل للرمز من أجل الاستدعاء المهم فقط. إذا كان الحساب يمتلك SID الخاص بالمسؤولين، فإن CreateRestrictedToken يجعله للرفض فقط؛ وإذا لم يكن هذا SID موجودًا أبدًا، يسجّل البرنامج تلك الحالة أيضًا. تُضبط السلامة على Medium.

لا يمتلك الدليل الأب والورقة DACLs متطابقة عن قصد. يحصل المستخدم الحالي على ما يلي بالنسبة للدليل:

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

ويحصل الملف الموجود على FILE_GENERIC_READ، وDACL الخاص به محمي من الوراثة. يحتفظ SYSTEM وAdministrators بالتحكم الكامل. ولأن SID الخاص بالمسؤولين في الرمز غائب أو للرفض فقط، فإن ACE السماح الخاص بالمسؤولين لا يمكنه منح الوصول لهذا الخيط.

تبدو بتة DELETE على الدليل الأب مثيرة للشك حتى يتم توضيح الكائن الذي تنطبق عليه. فهي تسمح بحذف الدليل نفسه. أما حذف أحد أبنائه فهو FILE_DELETE_CHILD، وهي بتة مختلفة لا يحتوي عليها ACE الخاص بالدليل الأب. DeleteFileW يقبل إما DELETE على الورقة أو صلاحية حذف الابن على الدليل الأب. لا يمتلك الاختبار أيًّا منهما، ولهذا فإن الخطأ 5 هو نتيجة التحكم المتوقعة.

أبقيت FILE_GENERIC_WRITE على الدليل الأب. فبتة FILE_WRITE_DATA الخاصة به هي FILE_ADD_FILE عندما يكون الكائن دليلًا. يمكن للمستدعي إنشاء ابن، وبالتالي يستوفي الدليل الأب متطلب WRITE_DATA أو WRITE_DAC الموثّق لـ CfCreatePlaceholders. بدون هذا الحق، تفشل الواجهة البرمجية في فحص الدليل الأساسي قبل الوصول إلى الحالة التي أبلغت عنها.

لن يسجّل البرنامج جذر المزامنة إلا إذا كانت هذه الكتلة صحيحة:

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 القيمة FILE_ATTRIBUTE_NORMAL قبل تطبيق DACL الخاص بالورقة ويؤكد أن بتة نقطة إعادة التحليل غير مضبوطة قبل استدعاء Cloud Files.

على النظام المتأثر، أعاد كل من استدعاء الدفعة والإدخال القيمة S_OK، وكان CreateUsn غير صفري. واكتسب الملف سمة نقطة إعادة التحليل. وعند طلب بيانات إعادة التحليل من نظام الملفات، أُرجع الوسم 0x9000001A، وهو IO_REPARSE_TAG_CLOUD.

لا يثبت EntriesProcessed == 1 النجاح لأن توثيق الواجهة البرمجية يحسب الإدخالات الفاشلة أيضًا. يأتي التأكيد من كلا HRESULTs، وUSN الخاص بالإنشاء، وسمة إعادة التحليل، ووسم Cloud.

بقي FILE_ID_INFO دون تغيير خلال الاستدعاء. اكتسب كائن الملف الموجود حالة Cloud Files؛ ولم يظهر ملف آخر ببساطة تحت نفس اسم المسار.

أقدم إصدار متأثر مُدرج لدى MSRC هو 17763.0، وهو جيل Windows 10 الإصدار 1809 وWindows Server 2019. وهذا يضع الأثر العام في 2018، أي قبل قرابة ثماني سنوات من إصلاح سبتمبر 2026.