أصدرت وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية CISA تحذيراً أمنياً بشأن ثغرة حرجة جديدة في نظام MikroTik RouterOS يمكن استغلالها قبل تسجيل الدخول إلى جهاز الراوتر، وقد تسمح للمهاجم بتنفيذ تعليمات برمجية عن بُعد Remote Code Execution بصلاحيات root أو التسبب في توقف الجهاز عن العمل.
الثغرة مسجلة بالرمز CVE-2026-84411 وحصلت على درجة CVSS 9.8/10. والمشكلة الأهم لمسؤولي الشبكات أن الخلل يقع في خدمة الإدارة عبر الويب ويصل إليه المهاجم قبل مرحلة المصادقة، ما يعني أن كلمة مرور الإدارة القوية وحدها لا تمنع استغلال الثغرة إذا كانت الخدمة الضعيفة قابلة للوصول.
إذا كنت تدير أجهزة MikroTik، افحص إصدار RouterOS وخدمات www وwww-ssl فوراً. CISA تسجل إصدارات RouterOS الأقدم من 7.24 كإصدارات متأثرة. وبسبب وجود تعارض في نشرة CISA نفسها حول الحد الأدنى للإصدار الآمن، فإن الإجراء الأكثر تحفظاً حالياً هو التحديث إلى أحدث إصدار Stable متاح، وهو 7.24.4 وقت إعداد هذا المقال، أو أي إصدار أحدث، مع منع WebFig من الوصول المباشر عبر الإنترنت.
ما هي ثغرة CVE-2026-84411؟
نشرت CISA التحذير ICSA-26-272-06 بتاريخ 29 سبتمبر 2026، ووصفت CVE-2026-84411 بأنها ثغرة Integer Underflow من تصنيف CWE-191 داخل آلية معالجة جسم طلبات HTTP في خدمة الإدارة عبر الويب في RouterOS.
بحسب التحذير، يستطيع مهاجم موجود على الشبكة وقادر على الوصول إلى خدمة الإدارة إرسال طلب HTTP مصمم خصيصاً يؤدي إلى تشغيل تعليمات برمجية بصلاحيات root أو إلى حالة Denial of Service. ولا يحتاج الاستغلال إلى حساب مستخدم أو كلمة مرور أو تفاعل من المسؤول.
| العنصر | التفاصيل |
|---|---|
| CVE | CVE-2026-84411 |
| المنتج | MikroTik RouterOS |
| المكوّن المتأثر | خدمة الإدارة عبر الويب Web Management |
| نوع الثغرة | Integer Underflow — CWE-191 |
| الحاجة إلى تسجيل الدخول | لا — Pre-Authentication |
| متجه الهجوم | Network |
| الأثر المحتمل | Remote Code Execution بصلاحيات root أو Denial of Service |
| CVSS v3.1 | 9.8 — Critical |
| الإصدارات التي تسجلها CISA كمتأثرة | RouterOS أقدم من 7.24 |
| الاستغلال المعروف وقت النشر | CISA لم تكن على علم باستغلال علني مؤكد لهذه الثغرة تحديداً وقت إصدار التحذير |
يمكن مراجعة تفاصيل التحذير في نشرة CISA الرسمية ICSA-26-272-06.
يوجد حالياً تعارض داخل بيانات التحذير: CISA تسجل RouterOS < 7.24 كإصدارات متأثرة، بينما يحتوي قسم المعالجة على توصية منسوبة إلى MikroTik بالانتقال إلى الإصدار 7.23 أو أحدث. لذلك لا ينبغي اعتبار جميع إصدارات 7.23 آمنة تلقائياً اعتماداً على هذه العبارة وحدها.
حتى 1 أكتوبر 2026، تعرض MikroTik الإصدار 7.24.4 كأحدث إصدار Stable، بينما الإصدار 7.23.7 هو أحدث Long-term. في بيئة إنتاجية حساسة، الخيار الأكثر تحفظاً أمام هذا التعارض هو استخدام أحدث Stable مؤهل لبيئتك أو انتظار توضيح رسمي من MikroTik قبل اعتبار فرع 7.23 محمياً من CVE-2026-84411.
لماذا تعتبر الثغرة خطيرة رغم وجود كلمة مرور للراوتر؟
النقطة الأساسية هي أن المسار المتأثر يمكن الوصول إليه قبل المصادقة. عادةً تحمي صفحة الإدارة نفسها بطلب اسم المستخدم وكلمة المرور، لكن في هذه الحالة تحدث المشكلة أثناء معالجة طلب HTTP قبل أن يصل RouterOS إلى مرحلة التحقق من هوية المستخدم.
لذلك فإن تغيير كلمة المرور، واستخدام كلمة مرور طويلة، وحتى تعطيل حساب admin الافتراضي تبقى إجراءات أمنية مهمة، لكنها لا تعالج هذه الثغرة بحد ذاتها.
إذا كان منفذ WebFig أو خدمة الويب الخاصة بالراوتر مكشوفاً مباشرة للإنترنت، يستطيع أي جهاز خارجي الوصول إلى سطح الهجوم. أما إذا كانت الإدارة محصورة ضمن Management VLAN أو شبكة موثوقة، فإن احتمالية الوصول من الإنترنت تنخفض بصورة كبيرة، لكن يبقى الجهاز بحاجة إلى التحديث لأن مهاجماً حصل مسبقاً على موطئ قدم داخل الشبكة قد يستطيع الوصول إلى الخدمة.
ولهذا السبب تعتبر حماية Management Plane أمراً أساسياً في أجهزة الراوتر والفايروول. المشكلة نفسها تظهر في كثير من حوادث أجهزة الحافة؛ ويمكن مراجعة مثال مشابه في مقال هجمات Fortinet FortiGate وسبب خطورة تعريض واجهات Firewall وVPN للإنترنت.
كيف تعرف إن كان جهاز MikroTik لديك معرضاً للخطر؟
ابدأ بتحديد إصدار RouterOS، ثم افحص خدمات الإدارة المفعلة ومصادر الشبكات المسموح لها بالوصول إليها.
/system resource printابحث عن قيمة version. إذا كان الإصدار أقدم من 7.24، فيجب اعتباره ضمن نطاق CISA المتأثر إلى أن يتوفر توضيح رسمي أكثر تحديداً.
/ip service printراجع خصوصاً خدمتي:
- www — خدمة WebFig عبر HTTP.
- www-ssl — خدمة WebFig عبر HTTPS.
إذا ظهرت الخدمة مفعلة، تحقق مما إذا كانت مقيدة بعناوين Management محددة أم قابلة للوصول من نطاقات غير موثوقة.
لا تعطل خدمة الإدارة التي تعتمد عليها للوصول إلى راوتر بعيد قبل التأكد من وجود وسيلة إدارة بديلة مثل WinBox من شبكة موثوقة أو VPN أو وصول Out-of-Band. قطع آخر وسيلة إدارة عن راوتر في فرع بعيد قد يتطلب زيارة الموقع لاستعادة الوصول.
يمكن تعطيل خدمتي الويب بالكامل بعد التأكد من عدم اعتماد أي تكامل أو REST API عليهما:
/ip service disable www,www-sslقيد الخدمة على شبكة إدارة محددة بدلاً من السماح بالوصول العام. المثال التالي افتراضي لشبكة إدارة 192.168.88.0/24 ويجب تغييره ليتناسب مع شبكتك:
/ip service set www address=192.168.88.0/24
/ip service set www-ssl address=192.168.88.0/24وتوضح وثائق MikroTik أن تقييد الوصول باستخدام Firewall يعد أكثر قوة، لأنه يمنع الاتصال من الوصول إلى Socket الخاص بالخدمة أصلاً. الأفضل في الشركات أن تكون إدارة الراوتر متاحة فقط من Management VLAN أو من خلال VPN محدث بدلاً من نشر منافذ الإدارة على الإنترنت.
ماذا يجب على مسؤول الشبكة فعله الآن؟
المعالجة العملية لا تعتمد على التحديث وحده. الأفضل التعامل مع الجهاز على مرحلتين: أولاً خفض سطح التعرض، ثم تثبيت الإصدار المصحح والتحقق من الإعدادات بعد إعادة التشغيل.
افحص Firewall وNAT وأي Port Forwarding أو قواعد Input Chain تسمح بالوصول إلى HTTP أو HTTPS الخاص بالراوتر من WAN. حتى لو كنت تخطط للتحديث خلال دقائق، فإن تقليل Surface Exposure خطوة مفيدة ومستقلة عن التصحيح.
تحقق أولاً من الإصدار المتاح في القناة المستخدمة:
/system package update check-for-updatesخذ Export أو Backup مناسباً للإعدادات، وتأكد من وجود مسار Rollback ووصول بديل للجهاز. تثبيت تحديث RouterOS يؤدي عادةً إلى إعادة تشغيل الراوتر، لذلك نفذ التغيير ضمن نافذة صيانة مناسبة، خصوصاً على Core Router أو أجهزة الفروع.
بعد التأكد من الإصدار وسياسة التغيير يمكن تنفيذ عملية التحديث من WinBox أو WebFig أو CLI وفق إجراءات المؤسسة. يمكن مراجعة أحدث الإصدارات مباشرة من صفحة تنزيل MikroTik الرسمية.
وبسبب التعارض الحالي بين نطاق الإصدارات المتأثرة في CISA ونص توصية التحديث، لا ننصح بالانتقال من إصدار قديم إلى 7.23 فقط والافتراض أن المشكلة انتهت. حتى ظهور توضيح رسمي، استخدم أحدث إصدار Stable مدعوم ومختبر في بيئتك كلما كان ذلك ممكناً.
- تأكد من الإصدار الفعلي بعد إعادة التشغيل.
- راجع أن www وwww-ssl مغلقتان أو مقيدتان بالشبكات المطلوبة فقط.
- تحقق من Firewall Input Rules وNAT بحثاً عن أي نشر غير مقصود لخدمات الإدارة.
- راجع المستخدمين والحسابات ذات الصلاحيات المرتفعة.
- افحص Scripts وScheduler وأي إعدادات جديدة أو غير معروفة.
- راجع Logs بحثاً عن تغييرات أو عمليات دخول وإدارة غير متوقعة.
- وثق الإصدار السابق والجديد ووقت التغيير والاختبارات التي تمت بعده.
هل CVE-2026-84411 هي نفسها ثغرات MikroTrick؟
لا. من المهم عدم الخلط بين الحادثتين.
الثغرة CVE-2026-84411 التي تناولتها CISA في 29 سبتمبر مرتبطة بخدمة الإدارة عبر الويب ومعالجة طلبات HTTP قبل المصادقة.
أما سلسلة الثغرات التي أطلق عليها CERT Polska اسم MikroTrick وظهرت في وقت سابق من سبتمبر 2026، فقد تضمنت ثغرات مختلفة مرتبطة خصوصاً بخدمة SSH ومكونات أخرى في RouterOS. وأكد CERT Polska رصد هجمات فعلية على أجهزة RouterOS كانت خدمة SSH فيها قابلة للوصول من الإنترنت.
عدم تشغيل SSH على الإنترنت لا يعني أن الجهاز محمي من CVE-2026-84411 إذا كانت خدمة الإدارة عبر الويب معرضة. وبالمقابل، إغلاق WebFig لا يلغي الحاجة إلى معالجة ثغرات SSH السابقة. المطلوب هو تحديث RouterOS وتقليل جميع خدمات الإدارة المكشوفة، وليس معالجة منفذ واحد فقط.
خطة معالجة سريعة لبيئة شركة
إذا كان لديك عشرات أجهزة MikroTik، لا تبدأ بتحديثها عشوائياً. أنشئ Inventory سريعاً وحدد الأولوية حسب مستوى التعرض.
| الأولوية | نوع الجهاز | الإجراء | التحقق |
|---|---|---|---|
| حرجة | RouterOS أقدم من 7.24 مع Web Management قابل للوصول من الإنترنت | إزالة التعرض فوراً ثم تحديث الجهاز | اختبار WAN والتأكد من عدم إمكانية الوصول إلى واجهة الإدارة |
| مرتفعة | RouterOS قديم لكن الإدارة متاحة عبر VPN أو Management Network | تحديث ضمن أقرب Change Window مع مراجعة قواعد الوصول | فحص الإصدار والخدمات وقواعد Firewall |
| متوسطة | جهاز داخلي غير مكشوف ويستخدم إصداراً متأثراً | إدخاله ضمن خطة Patch وعدم تركه دون تحديث | Validation بعد التحديث ومراجعة Logs |
| متابعة | جهاز على إصدار حديث | التأكد من عدم وجود Management Exposure غير ضروري | Periodic Configuration Review |
في البيئات التي تجمع Syslog مركزياً، يمكن كذلك إرسال سجلات أجهزة الشبكة إلى SIEM ومراقبة التغييرات ومحاولات الإدارة غير المعتادة. شرحنا نموذجاً عملياً لهذه الفكرة في دليل Wazuh لمنصة SIEM وXDR.
لكن المراقبة لا تستبدل التحديث: اكتشاف محاولة استغلال بعد وصولها إلى الراوتر أقل فعالية من إزالة الخدمة من الإنترنت وإغلاق الثغرة من الأساس.
أسئلة شائعة حول ثغرة MikroTik الجديدة
هل RouterOS 7.23 آمن من CVE-2026-84411؟
لا توجد حالياً إجابة يمكن اعتبارها محسومة اعتماداً على نشرة CISA وحدها. سجل المنتجات المتأثرة يذكر كل إصدار أقدم من 7.24، بينما قسم المعالجة يذكر 7.23 أو أحدث. لهذا السبب يفضل عدم اعتبار 7.23.x آمناً تلقائياً إلى أن توضح MikroTik أو CISA هذا التعارض.
هل تغيير كلمة مرور MikroTik يحمي من الثغرة؟
لا. كلمة المرور القوية مهمة ضد سرقة الحسابات ومحاولات تسجيل الدخول، لكن CVE-2026-84411 قابلة للوصول قبل مرحلة المصادقة، لذلك المعالجة الأساسية هي التحديث وتقليل الوصول إلى خدمة الإدارة.
هل يكفي تعطيل WebFig؟
تعطيل خدمات الويب يقلل سطح الهجوم المتعلق بهذه الخدمة بشكل كبير، لكنه ليس بديلاً دائماً عن تثبيت التحديث الأمني. قد تحتاج الخدمة لاحقاً، كما أن الجهاز يمكن أن يحتوي على ثغرات أخرى في مكونات مختلفة.
هل يتم استغلال CVE-2026-84411 حالياً؟
بحسب CISA عند نشر التحذير في 29 سبتمبر 2026، لم تكن الوكالة على علم باستغلال علني مؤكد لهذه الثغرة تحديداً. هذا يختلف عن بعض ثغرات MikroTik الأخرى التي ظهرت خلال سبتمبر وثبت استخدامها في هجمات فعلية.
الخاتمة
CVE-2026-84411 ليست مجرد مشكلة في صفحة تسجيل الدخول إلى MikroTik. كون الخلل موجوداً في خدمة الإدارة ويمكن الوصول إليه قبل المصادقة، مع إمكانية تنفيذ تعليمات برمجية بصلاحيات root، يفسر حصوله على درجة CVSS حرجة تبلغ 9.8.
الخطوة العملية لمسؤول الشبكة هي جرد أجهزة MikroTik، تحديد إصدارات RouterOS، البحث عن www وwww-ssl المكشوفتين، إزالة الوصول الإداري المباشر من الإنترنت، ثم نشر تحديث حديث ضمن Change Window مع Validation بعد إعادة التشغيل. وبسبب التعارض الحالي حول 7.23، فإن استخدام أحدث Stable متاح ومؤهل للبيئة هو القرار الأكثر تحفظاً إلى أن تصدر MikroTik توضيحاً مباشراً حول CVE-2026-84411.