كشفت شركة الأمن السيبراني TantoSec عن سلسلة استغلال جديدة تستهدف مكون RadAsyncUpload في إطار عمل Telerik UI for ASP.NET AJAX، حيث يمكن للمهاجمين غير المصرح لهم تنفيذ أوامر عن بُعد (RCE) عبر ثغرة Padding Oracle في تشفير AES-CBC. ورغم أن شركة Progress Software أصدرت تحديثاً لمعالجة الثغرة في يوليو 2026، فإن نشر أداة استغلال عامة مع حمولة جاهزة يجعل المسار الهجومي متاحاً للجميع لأول مرة. الثغرة الأساسية، المسجلة تحت الرمز CVE-2026-13181، تحمل تقييم خطورة 8.1 وفق معيار CVSS.
شروط الاستغلال والبيئة المستهدفة
لا يكفي تشغيل إصدار متأثر ليصبح التطبيق معرضاً للهجوم؛ بل يتطلب الاستغلال توافر شروط محددة:
- وجود صفحة تستخدم مكون RadAsyncUpload مع معالج خادم يقرأ نتيجة الرفع.
- تكوين التطبيق باستخدام مفتاح تشفير مخصص غير افتراضي، وهو إعداد توصي به Telerik عادةً كإجراء تعزيز أمني.
في حال تحقق هذه الشروط، يمكن للمهاجم استغلال الفارق في استجابات الخادم عند معالجة بيانات مشوهة، لفك تشفير الإعدادات ثم تزويرها، وصولاً إلى تحميل مكتبة DLL خبيثة وتشغيلها بامتيازات IIS Application Pool.
تفاصيل تقنية حول سلسلة الهجوم
- الثغرة الأولى (CVE-2026-13182) تسمح بفك تشفير البيانات عبر استغلال اختلاف استجابات الخادم عند وجود حشو صحيح أو خاطئ.
- الثغرة الثانية (CVE-2026-13181) تتيح للمهاجم تسمية نوع .NET عشوائي يتم تحميله دون قائمة سماح، ما يؤدي إلى تحميل مكتبة DLL خبيثة.
- ثغرة إضافية (CVE-2026-13183) تعتمد على توقيت الاستجابة عند إخفاء رسائل الخطأ التفصيلية.
- ثغرة أخرى (CVE-2026-13184) تتعلق بمفتاح افتراضي متوقع، لكنها لم تُستخدم في الاستغلال المنشور.
عملية الاستغلال الكاملة قد تتطلب أكثر من 127 ألف طلب Oracle، أي نحو ساعة ضد بيئة اختبارية، وقد تطول أكثر في حال وجود قيود على معدل الطلبات.
سجل تاريخي للهجمات على Telerik
رغم عدم وجود تقارير مؤكدة عن استغلال هذه الثغرات الجديدة في بيئات الإنتاج حتى الآن، فإن مكون RadAsyncUpload له سجل طويل من الهجمات الواقعية. أبرزها ثغرة CVE-2019-18935 التي استُغلت مع ضعف تشفير سابق في هجمات نفذتها مجموعات فدية وجهات مدعومة من دول، بما في ذلك اختراق وكالة فدرالية أميركية عام 2022، وظلت تُستغل حتى عام 2025.
توصيات الحماية والإجراءات المؤقتة
أوصت شركة Progress Software بالترقية الفورية إلى الإصدار 2026.2.708 أو أحدث، حيث تم استبدال نظام التشفير بـ Authenticated Encryption يغلق سلسلة الاستغلال بالكامل. أما المواقع التي لا تستطيع الترقية فوراً، فيمكنها اتباع إجراءات مؤقتة:
- تفعيل إعداد customErrors لتقييد رسائل الخطأ.
- تعطيل معالج الرفع إذا لم يكن ضرورياً.
- إزالة أي مفتاح تشفير مخصص والاعتماد على مفتاح ASP.NET الافتراضي مع AES + HMAC.
كما حذرت الشركة من أن الاستغلال لا يترك آثاراً واضحة في سجلات الأخطاء، ما يستدعي مراقبة سلوكيات غير طبيعية مثل تشغيل cmd.exe من عملية w3wp.exe أو ظهور ملفات DLL مشبوهة في مجلدات التطبيق.
