نشرت شركة TantoSec سلسلة استغلال عاملة تستهدف ثغرات في Telerik UI for ASP.NET AJAX تسمح لمهاجم غير مصادَق بتنفيذ شفرة عن بُعد على الخادم الذي يستضيف التطبيق المتأثر، بحسب The Hacker News. أصلحت Progress Software الثغرات في يوليو، والاستغلال يتطلب إعدادًا غير افتراضي — لكن ما تغيّر في 7 سبتمبر أن الشرح التفصيلي اقترن بأداة جاهزة للتشغيل (telerik-rau-exploit) وحمولتين: واحدة تكتب web shell على القرص، وأخرى تعمل في الذاكرة بالكامل. مسار هجوم مكتمل في أيدي العامة لأول مرة.
كيف تعمل السلسلة؟
نقطة الدخول Padding Oracle (CVE-2026-13182): يشفّر عنصر الرفع حالته بـ AES-CBC دون تحقق من السلامة، ويرد الخادم على البيانات المعدَّلة بشكل مختلف بحسب صحة الحشو. هذا الفارق يسمح بفك التشفير — وبتقنية بنتها TantoSec حول بذرة التشفير الثابتة للعنصر، بتزوير إعدادات الرفع المشفّرة دون معرفة المفتاح أبدًا.
التزوير نفسه يسمح بتسمية نوع .NET عشوائي يحلّه العنصر دون قائمة سماح (CVE-2026-13181) ويلغي تسلسله إلى gadget يحمّل DLL من موقع يتحكم به المهاجم. الـ DLL المرفوع تجميعة مختلطة الأنماط تنفّذ شفرة أصلية فور تحميلها — بصلاحيات مجمّع تطبيقات IIS.
ليس فوريًا: استغرق التشغيل الكامل عند TantoSec نحو 127 ألف طلب إلى الـ Oracle — قرابة ساعة ضد هدف مخبري، وأطول ضد خادم بتحديد معدل. وإن أخفى التطبيق رسائل الخطأ التفصيلية، يبقى الـ Oracle قابلًا للقراءة عبر توقيت الاستجابة (CVE-2026-13183).
من المعرَّض فعلًا؟
تشغيل إصدار متأثر لا يكفي. تقول TantoSec إن للسلسلة «شروطًا مسبقة لا يحققها التثبيت الافتراضي»:
- صفحة تعرض عنصر RadAsyncUpload يقرأ معالجها نتيجة الرفع.
- تطبيق مهيّأ بـ مفتاح تشفير صريح غير افتراضي للعنصر — وهو، في مفارقة لافتة، إعداد توصي به Telerik كتحصين.
المواقع على إصدار متأثر دون الشرطين معًا غير قابلة للاستغلال عبر هذه السلسلة. النطاق المتأثر: 2010.1.309 حتى 2026.2.519؛ الإصلاح في 2026.2.708 (2026 Q2 SP1) وما بعده.
هل تُستغل فعليًا؟
لا تقارير مؤكدة عن استغلال ثغرات 2026 في الواقع، ولا تظهر في فهرس KEV حتى 7 سبتمبر. مورّد واحد (IONIX) يقول إنه «يتتبع محاولات استغلال جارية» دون تواريخ أو أرقام، ودون التمييز بين الاستغلال والمسح العادي للمعالج.
لكن للمكوّن نفسه تاريخ ثقيل — عبر ثغرات أقدم: خلل إلغاء التسلسل CVE-2019-18935 في المعالج ذاته سُلسل مع ضعف تشفير من 2017 واستغلته عصابات فدية وفاعلون حكوميون، بما في ذلك اختراق وكالة فيدرالية أمريكية في 2022، وظل يُستغل حتى 2025. لهذا يلفت أي مسار تنفيذ شفرة دون مصادقة في هذا المعالج الانتباه.
سلسلتان لا واحدة
نشرة Progress ليوليو تغطي في الواقع سلسلتي هجوم منفصلتين: سلسلة RadAsyncUpload التي فصّلتها TantoSec، وسلسلة تنفيذ شفرة مستقلة في مكوّني RadPersistenceManager وRadDockLayout (CVE-2026-13185 و-13186 و-13190) اكتشفها ماركوس فولفتانغه من CODE WHITE مع Progress، ولم تُنشر لها أداة استغلال علنية. وثمة خلل رابع بمفتاح افتراضي قابل للتنبؤ (CVE-2026-13184) ينطبق فقط على نمط هجوم بديل لم تستخدمه الأداة المنشورة.
ماذا تفعل؟
الترقية إلى 2026.2.708 أو أحدث هي التوصية الرسمية الوحيدة من Progress: تستبدل مخطط AES-CBC المعيب بتشفير موثَّق وتغلق السلسلة بأكملها. وتحذّر الشركة من أن مفتاحًا مخصصًا أقوى لا يساعد، لأن الـ Oracle لا يحتاج المفتاح أصلًا.
للمواقع التي لا تستطيع الترقية فورًا، خطوات مؤقتة من Progress:
- اضبط
customErrorsعلىRemoteOnlyأوOn— يُجبر المهاجم على متغير التوقيت الأبطأ. - عطّل معالج الرفع كليًا (
Telerik.Web.DisableAsyncUploadHandler = true) إن لم تكن بحاجة إلى RadAsyncUpload. - أزل أي مفتاح تشفير مخصص ليعود العنصر إلى مفتاح ASP.NET الآلي مع AES وHMAC، أو ولّد مفاتيح آلة قوية يدويًا لا وقت التشغيل.
الصيد: سلوكيًا لا بالبصمات
تحذّر Progress من أن الاستغلال الناجح «لا يترك أثرًا واضحًا في سجلات أخطاء ASP.NET القياسية». ابحث عن السلوك:
- عملية IIS (
w3wp.exe) تُطلقcmd.exeأوpowershell.exe. - ملف
.aspxجديد أو غير متوقع في جذر الويب. - مكتبة DLL مختلطة الأنماط مكتوبة تحت المجلد المؤقت لعنصر الرفع أو
App_Data. - دفعة كبيرة من الطلبات (عشرات الآلاف) إلى
Telerik.Web.UI.WebResource.axd?type=rauمن عنوان واحد — بصمة الـ Oracle نفسها.
أبلغت TantoSec الشركة في 22 مايو؛ شُحن الإصلاح في 8 يوليو، وتبعته معرّفات CVE في 22 يوليو. يُنسب الفضل في متغير التوقيت إلى جاستن ستيفن.
