ثغرة Cisco SD-WAN تمنح صلاحيات مدير: الدرع المؤقت لا يكفي

في 2 أكتوبر 2026، حدّثت Cisco تنبيه ثغرة CVE-2026-76504 في Cisco Catalyst SD-WAN Manager بعد رصد استغلالها فعليًا في سبتمبر 2026؛ يمكن لمهاجم بعيد بلا حساب تجاوز مصادقة واجهة API والحصول على امتيازات المدير، وتبلغ شدة الثغرة 9.8 وفق CVSS. أضاف التحديث درع Live Protect لتغطية مؤقتة جزئية، أما إغلاق الثغرة فيتطلب إصدارًا برمجيًا مصححًا.

وأورد المركز الكندي للأمن السيبراني أن وكالة CISA أدرجت CVE-2026-76504 في كتالوج الثغرات المستغلة المعروفة يوم 30 سبتمبر 2026. بالنسبة إلى مشغل الشبكة، يجتمع قراران عاجلان: حماية مسار الوصول إلى Manager وترقيته، مع حفظ بيانات التشخيص قبل التغيير لمعرفة ما إذا سبق استغلاله. وجود نسخة معرضة يثبت الحاجة إلى الإصلاح، لكنه لا يثبت بمفرده وقوع اختراق في تلك البيئة.

لماذا يطال الخلل واجهة إدارة SD-WAN؟

توجد الثغرة في إدارة المصادقة القائمة على الجلسات لواجهة API الخاصة بـ Cisco Catalyst SD-WAN Manager، المعروف أيضًا باسم vManage. يؤدي التعامل غير الصحيح مع ترميز الأحرف في عنوان طلب HTTP إلى تجاوز قاعدة مصادقة تحمي نقطة محددة من الواجهة. يتيح الطلب المصاغ للاستغلال الوصول إلى API بامتيازات حساب المدير من دون بيانات تسجيل دخول، وهو ما يجعل التعرض لواجهة الإدارة مسألة تشغيلية مباشرة.

ينحصر نطاق هذا التنبيه في Manager؛ ولا تتطلب معالجة هذه الثغرة بعينها تحديث Controller أو Validator أو الموجهات الطرفية. لكن توافق إصدارات مكونات التحكم يظل شرطًا عند اختيار نسخة Manager الجديدة. ويزداد خطر التعرض حين تكون منافذ Manager متاحة من الإنترنت، لأن الطلب الضار يحتاج إلى الوصول إلى النظام حتى يحاول تجاوز المصادقة. لذلك يفيد جرد نسخة كل Manager ومسارات الوصول إليها، بما يشمل عقد المجموعات ومواقع التعافي، قبل تحديد نافذة الترقية.

مصفوفة الإصدارات: إلى أين يرقّى Manager؟

يعرض دليل Cisco للمعالجة أول إصدار يتضمن الإصلاح داخل كل سلسلة من Cisco Catalyst SD-WAN Manager. إذا كانت النسخة المثبتة أقدم من الحد المقابل لسلسلتها، فهي تحتاج إلى تحديث؛ أما النسخة التي بلغت هذا الحد أو تجاوزته فقد حصلت على إصلاح هذه الثغرة:

• ما قبل سلسلة 20.9: الانتقال إلى سلسلة مدعومة وإصدار مصحح.
• سلسلة 20.9: الإصدار 20.9.10.1 أو أحدث ضمن السلسلة.
• سلسلة 20.12: الإصدار 20.12.8.2 أو أحدث ضمن السلسلة.
• سلسلة 20.15: الإصدار 20.15.6.1 أو أحدث ضمن السلسلة.
• سلسلة 20.18: الإصدار 20.18.4.1 أو أحدث ضمن السلسلة.
• سلسلة 26.1: الإصدار 26.1.2.1 أو أحدث ضمن السلسلة.
• سلسلة 26.2: الإصدار 26.2.1 أو أحدث ضمن السلسلة.

الإصدارات السابقة للسلسلة 20.9 بلغت نهاية صيانة البرمجيات، ولهذا لا يكفي البحث لها عن رقعة داخل السلسلة نفسها. وفي السلاسل الأخرى، يكون المسار الموصى به إلى أول إصدار مصحح ضمن السلسلة الحالية؛ الانتقال إلى سلسلة رئيسية أعلى يحتاج إلى توجيه صريح من TAC. وتتيح مصفوفة توافق مكونات التحكم تحديد ما إذا كان Manager المحدّث سيعمل مع Controller وValidator الموجودين، خصوصًا إذا كانت بقية المكونات لا تزال على إصدارات قديمة.

تختلف حالة Cisco SD-WAN Cloud ‏(Cisco Managed) عن Manager الذي تديره المؤسسة بنفسها: عولجت الخدمة المُدارة في إصدار 20.15.605، ولا يُطلب من العميل تنفيذ تحديث لهذه الخدمة. أما البيئات المستضافة سحابيًا التي يدير فيها العميل الترقية، فتحتاج إلى مراجعة موعد التحديث المجدول وقواعد السماح بالوصول إلى الإدارة؛ ولا يعني وجود استضافة سحابية أن كل نسخة Manager قد رُقّيت تلقائيًا.

مؤشرات السجل التي تستحق المطابقة

تبدأ المراجعة بطلبات j_security_check التي يظهر فيها حرف واحد على الأقل مرمّزًا داخل المسار، وتأتي من عنوان IP مجهول أو غير مخوّل. المثال المنشور هو ‎/%6a_security_check، حيث يمثّل ‎%6a الحرف j. يمكن أن يستخدم الطلب حرفًا مرمّزًا آخر، لذلك لا يُحصر البحث في هذا التسلسل وحده. افحص السجلات الحالية والملفات المدورة لكل Manager، بما فيها كل عقدة في المجموعة ونظام التعافي من الكوارث.

في ملف serviceproxy-access.log، ابحث عن الطلب المرمّز ومصدره ووقته ورمز استجابة HTTP؛ ظهور استجابة ناجحة في المثال المنشور يجعل المطابقة الزمنية مهمة، لكنه لا يحسم وحده طبيعة النشاط. ثم راجع vmanage-server.log للفترة نفسها: يزداد وزن الإشارة إذا ظهر طلب j_security_check مرتبطًا باسم مستخدم يبدأ بـ viptela-reserved-، وهي بادئة لحسابات خدمة محجوزة.

قد تظهر هذه المؤشرات خلال نشاط مشروع، مثل فحص أمني مصرح به. قارن عنوان المصدر بالجهات المسموح لها فعليًا، واحتفظ بأسطر السجل والطوابع الزمنية والعناوين ورموز الاستجابة للمراجعة. بعض سجلات Manager مقيدة الوصول؛ لذلك تُعد حزمة admin-tech، بخياري Log وTech، وسيلة الجمع المفضلة. وإذا تعذر جمعها، توفر مراجعة السجلات يدويًا مؤشرات أولية تُرفع إلى مركز الدعم الفني TAC، الذي يقيّمها في سياق البيئة.

ما الذي يفعله Live Protect، وما ترتيب الاستجابة؟

يوفر Live Protect وقتًا للتخطيط وحفظ الأدلة، لكنه يغطي الثغرة جزئيًا فقط. وقد يؤدي تفعيله إلى منع مستخدم مشروع يعتمد ترميز الأحرف في عنوان الطلب من تسجيل الدخول إلى Manager. وفي النشر المحلي، يحد تقييد الوصول من الشبكات غير الموثوقة ووضع مكونات التحكم خلف جدار ناري يسمح للمضيفين المعروفين فقط بالاتصال من فرصة وصول الطلب الضار؛ تبقى هذه ضوابط تعرض مؤقتة إلى أن تتغير النسخة الضعيفة نفسها.

1. اجمع admin-tech من جميع نسخ Manager قبل التحديث، ومن كل عضو في المجموعة وكل موقع تعافٍ. اختر بيانات Log وTech حتى تبقى السجلات والتشخيصات متاحة لفحص ما حدث قبل الإصلاح.
2. قيّد مسار الإدارة إلى المضيفين الموثوقين حيث تسمح بنية الشبكة بذلك، ثم رقِّ كل Manager معرض إلى إصدار مصحح في سلسلته. لا تنتظر نتيجة فحص TAC قبل تنفيذ الترقية.
3. افتح حالة لدى TAC وأرسل حزم admin-tech السابقة للتحديث لفحص مؤشرات الاختراق. إذا ظهرت مؤشرات في بيئتك، تُحدَّد المعالجة الإضافية وفق نتائج الفحص؛ فترقية البرنامج تغلق مدخل الثغرة لكنها لا تعالج تلقائيًا آثار وصول سابق.

اقرأ أيضًا:

• ثغرة IPv6 تمنح صلاحيات root، والإصدار لا يكفي وحده للحكم
• ثغرة Cisco ISE تُستغل فعليًا: لا حل مؤقتًا والتحديث وحده لا يكفي
• Cisco تضيف خوادم Supermicro إلى مصنع NVIDIA للذكاء الاصطناعي