مقدمة

مرحباً بالجميع، في شهر مايو وجدت ثغرات أمنية جيدة في جهاز الراوتر الخاص بي، واليوم يمكنني أخيراً أن أعرضها على الجميع!

كلتا الثغرتين في هذا المستودع هما ثغرتان لحرمان الخدمة (Denial of Service) تتطلبان المصادقة!

لا أعرف التفاصيل التقنية الدقيقة لكيفية أو سبب عمل هاتين الثغرتين، لم نتلقَ أي رد من Calix (البائع في هذه الحالة) لذا نعم! مرحاً!

هذه أيضاً أول ثغرة CVE وثاني ثغرة CVE لي على الإطلاق، صفقة 2 مقابل 1 لا مشكلة.

CVE-2026-19745

CVE-2026-19745 هي ثغرة حرمان خدمة (DoS) بسبب إغلاق أو تحرير غير صحيح للموارد تؤثر على جهاز الراوتر الخاص بي :)

https://nvd.nist.gov/vuln/detail/CVE-2026-19745

"تم العثور على خلل في Calix GigaSpire 26.1.0. تتأثر وظيفة غير معروفة في الملف utilities_configurationsave.cgi من مكوّن واجهة الإدارة عبر الويب. تنفيذ معالجة للوسيط sessionKey يمكن أن يؤدي إلى حرمان الخدمة. يمكن شن الهجوم عن بُعد. تم نشر الاستغلال وقد يُستخدم. تم التواصل مع البائع مبكراً بشأن هذا الإفصاح لكنه لم يستجب بأي شكل."

الشرح

قررت VulDB أن التصنيف المناسب هو CWE-404 والذي فاجأني نوعاً ما لأنني كنت أفكر في CWE-835 للأسف ليس لدي تفاصيل تقنية حول سبب حدوث ذلك، لكن يمكنني أن أخبركم أنني وجدت هاتين الثغرتين CVE بالصدفة المحضة تماماً.

الخط الزمني

30 مايو: تم العثور على الثغرة، في البداية ظننت أنها مجرد تحديد معدل (ratelimiting) حتى حاولت استخدام الموقع على جهاز كمبيوتر آخر، واتضح أنها ليست كذلك.

31 مايو: بعد استعداد ذهني قررت أن هذا يستحق الإبلاغ حتى لو كنت مخطئاً في البداية.

15 يونيو: بلغت 16 عاماً، مهم جداً للخط الزمني بوضوح.

24 يونيو: أبلغت VulnDB

26 يونيو: ردت Calix (أخيراً) عليّ وهو أمر غير متوقع، ادعوا عدم وجود أي ثغرة لكنهم كانوا سيقومون "بإصلاحها" في الإصدار التالي ؟؟ عمل رائع، كما ردت في نفس اليوم مع دليل فيديو على أن تقريري هو ثغرة فعلية، ولم أتلقَ أي رد بعد ذلك.

13 أغسطس: تم تخصيص CVE من قبل VulDB.

الرد

قالت Calix أن هذا سلوك متوقع من مهلة زمنية (timeout) بينما ينتظر التطبيق إدخال المستخدم، قد يكون هذا هو الحال بالفعل لكن لا ينبغي أن يكون له أي تأثير على أي مستخدم آخر.

alt text

الفيديو

https://github.com/user-attachments/assets/6aa509d4-ee69-4ed6-a9bb-1324f77a7036

Calix إله التواصل

كما أشار الخط الزمني، لم تكن Calix مفيدة حقاً بأي شكل سوى الحصول على تخصيص CVE بسبب نقص التواصل، على حد علمي تواصلت vuldb مع Calix ولم يتلقوا رداً هم أنفسهم.

أود أن أعرض لكم الرد الذي قدموه لي، لكن للأسف غير مسموح لي بذلك :( بشكل أساسي قالوا فقط أنهم غير قادرين على إعادة إنتاج الثغرة وأنهم لن يقوموا بإصلاحها باستثناء ثغرة traceroot (انظر أدناه)

CVE-2026-19746

https://github.com/user-attachments/assets/62c1ae62-8d52-4e97-975c-3c14ee6d8c95

الشرح

كنت أبحث في جميع نقاط النهاية (endpoints) التي تعرضها واجهة المتصفح ولاحظت traceroot.cmd الذي يقبل عملية إلغاء. فكرت في نفسي ماذا سيحدث إذا قمت ببساطة بإلغاء traceroot غير موجود.

جربت وظهر أن الواجهة بأكملها تتعطل، ويتم تسجيل خروج الجميع ويتم إبطال ملفات تعريف الارتباط (cookies) السابقة وأشياء أخرى.

هذه هي الثغرة التي ستقوم Calix بإصلاحها، مدعين أنه لا يوجد حرمان خدمة لكنها تطلق مسار كود "غير متوقع".

الخاتمة

أود أن أقدم تحية كبيرة لفريق الإشراف والأمن في VulDB، لقد قاموا بعمل رائع في مراجعة تقاريري وأخذها على محمل الجد (على عكس شخص معين هنا) سأتطلع إلى تقديم المزيد من التقارير في المستقبل! :)

ملاحظة: كنت متوتراً جداً عند محاولة تقديم هذا التقرير لأنها المرة الأولى التي أفعل فيها شيئاً كهذا وكنت غير متأكد تماماً مما إذا كان ما وجدته ثغرة أم لا، لكنني عرفت ذلك عندما أجريت اختبارات على كل هذه الثغرات على جهاز كمبيوتر منفصل! مما يعني أن جهاز الكمبيوتر الأول كان بمثابة مهاجم بينما كان جهاز كمبيوتر ثانٍ مسجلاً الدخول، وشوهدت التأثيرات على كلا الجهازين!

أعتقد أن تحليل VulDB ذهب بعيداً جداً هنا (ربما ذكاء اصطناعي) لكن لا يهم، مثل وصفها بأنها "ثغرة أمنية حرجة" بينما هي في الحقيقة ليست كذلك.

أشياء أخرى

خلال الخط الزمني أرسلت أيضاً حوالي رسالتين متابعة عبر البريد الإلكتروني ولم أحصل على شيء سوى أخطاء من خدمة البريد الإلكتروني التي يستخدمونها وتم تجاهلي في الرسالة السابقة.

alt text