ثغرة مستغلة في مدير SD-WAN من سيسكو: من يحدثه في شركتك، أنت أم مزود الخدمة؟

ثغرة مستغلة في مدير SD-WAN من سيسكو: من يحدثه في شركتك، أنت أم مزود الخدمة؟

يوم 30 سبتمبر 2026، عند الرابعة عصرا بتوقيت الرياض، نشرت سيسكو نشرة أمنية للثغرة CVE-2026-76504 في Cisco Catalyst SD-WAN Manager، النظام الذي تدير منه الشركات متعددة الفروع شبكة فروعها كلها من شاشة واحدة. درجة الخطورة 9.8 من 10، والاستغلال لا يحتاج حسابا ولا كلمة مرور، وتقول سيسكو إنها علمت خلال سبتمبر باستغلال فعلي للثغرة، ولا يوجد حل مؤقت. وفي اليوم نفسه أصدرت الهيئة الوطنية للأمن السيبراني التنبيه رقم 2026-7889 بمستوى خطورة عال جدا، ودعت إلى مراجعة النشرة وتطبيق التحديث.

كتبنا قبل أسبوعين عن ثغرة مستغلة في جهاز سيسكو آخر يدير الهوية والدخول، وشرحنا هناك أساسيات إدارة الثغرات. هذه المرة السؤال الأهم ليس تقنيا. شبكة الفروع قد لا تديرها أنت أصلا، بل مزود اتصالات أو شركة تقنية بعقد خدمة مدارة. فإن كانت كذلك: من يحدث النظام الليلة، ومن يفحص هل دخل أحد قبل التحديث، وماذا يقول عقدك إن لم يحدث أي من ذلك؟

ماذا نشرت سيسكو بالتحديد

الخبر عمره ساعات، لذلك هذه الوقائع من نشرة سيسكو نفسها ومن تنبيه الهيئة، لا من قراءات صحفية:

• المنتج: Cisco Catalyst SD-WAN Manager، المعروف سابقا باسم vManage. تنص النشرة على أنه متأثر أيا كانت طريقة ضبطه.
• السبب: خلل في معالجة ترميز الروابط داخل طلبات HTTP، يسمح لطلب معد خصيصا بتجاوز قاعدة مصادقة وضعت لحماية واجهة برمجية محددة، فيصل المهاجم إلى الواجهة البرمجية بصلاحيات حساب المدير.
• شرط الاستغلال: لا شيء. مهاجم عن بعد وغير مصادق عليه، والدرجة 9.8 من 10 على مقياس CVSS.
• الحالة: مستغلة فعليا. يقول فريق سيسكو الأمني إنه علم بالاستغلال في سبتمبر 2026، وإن الثغرة اكتشفت أثناء حل حالة دعم فني لدى مركز المساعدة التقنية في سيسكو.
• الحل المؤقت: لا يوجد. العلاج هو الترقية إلى إصدار مصحح.
• التنبيه المحلي: تنبيه الهيئة الوطنية للأمن السيبراني رقم 2026-7889 بتاريخ 30 سبتمبر 2026، ويذكر أربعة عشر قطاعا مستهدفا، أي عمليا كل القطاعات، منها التجارة والاستثمار، والمالية والاقتصاد، والصحة، والتعليم، والنقل، والصناعة.

والإصدارات المصححة بحسب النشرة:

انتبه للسطر الأول: من يعمل على إصدار أقدم من 20.9 لا ينتظره تحديث صغير، بل انتقال إلى فرع إصدار آخر، وهذا عمل يحتاج تخطيطا لكنه لا يحتمل التأجيل.

لماذا هذا النظام بالذات

شبكة SD-WAN تربط الفروع والمستودعات والمكتب الرئيسي ببعضها عبر خطوط الاتصال المتاحة، وتدار كلها من نظام مركزي واحد. من هذا النظام تكتب السياسات: أي حركة تمر عبر أي خط، وأي فرع يصل إلى أي نظام، وما الإعدادات التي ترسل إلى أجهزة التوجيه في كل موقع. تغيير واحد في المركز يصل إلى كل الفروع، وهذه هي الفكرة كلها.

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

في سحابة سيسكو أم في مركز بياناتك؟ هنا يتحدد من يتحرك

تفرق النشرة بين نوعين من التشغيل، والفرق عملي جدا:

• في سحابة سيسكو: تقول النشرة إن الثغرة تصيب النظام أيا كانت طريقة ضبطه، وتذكر حالتين سحابيتين. في بيئات Cisco Catalyst SD-WAN Cloud Hosted طبقت سيسكو مسبقا إجراء تقييد الوصول، لكن التخفيف ليس إصلاحا، فتبقى الترقية إلى إصدار مصحح من الجدول أعلاه مطلوبة، واسأل من ينفذها. أما في Cisco SD-WAN Cloud الذي تديره سيسكو (Cisco Managed) فالإصدار 20.15.605 يعالج الثغرة، وتقول سيسكو إنه لا يلزم العميل أي إجراء، ويمكن التحقق من الإصدار عبر قائمة المساعدة في واجهة الخدمة. في هذه الحالة وحدها تكون الترقية من جهة المورد، ويبقى عليك أن تتأكد منها كتابة، وأن تطلب فحص السجلات عن الفترة السابقة.
• التشغيل في موقعك أو في مركز بيانات مزودك: هنا لن يحدث أحد النظام نيابة عنك إلا إن كان ذلك مكتوبا في العقد. والتخفيف الذي تذكره سيسكو حتى تتم الترقية هو منع الوصول إلى النظام من الشبكات غير الآمنة مثل الإنترنت، ووضع مكونات التحكم في SD-WAN خلف جهاز تصفية مثل جدار الحماية.

السؤال الأول إذن ليس هل نستخدم سيسكو، بل أين يعمل نظام إدارة شبكتنا ومن يملك تحديثه. وإن كان الجواب عند المزود وحده، فهذه أول ثغرة تستحق المعالجة، وهي ليست تقنية.

التحديث لا يخبرك هل دخل أحد قبله

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

ولهذا نشرت سيسكو مؤشرات يبحث عنها فريقك التقني أو مزودك في سجلين محددين على النظام، هما serviceproxy-access.log و vmanage-server.log:

• طلبات إلى j_security_check من عناوين IP غير معروفة أو غير مصرح لها.
• أي حرف مرمز داخل مسار الطلب، مثل %6a_security_check حيث %6a هو الحرف j مرمزا، وهي الطريقة التي يتجاوز بها الاستغلال قاعدة المصادقة. وتنبه سيسكو إلى أن هذا مثال فقط، فترميز أي حرف واحد في الطلب يكفي للاستغلال، لذلك يبحث الفريق عن كل صيغة مرمزة لـ j_security_check لا عن %6a وحدها.
• في السجل vmanage-server.log تحديدا: طلبات j_security_check من عناوين غير معروفة لأسماء مستخدمين تبدأ بـ viptela-reserved-. هذه حسابات خدمة مدمجة في النظام، فظهور اسمها في السجل وحده ليس دليلا على اختراق، والعبرة بالمصدر غير المعروف.

وتنبه سيسكو إلى أن هذه المؤشرات قد تظهر أحيانا في التشغيل العادي، فتقارن بالنشاط المعتاد للشبكة قبل الحكم.

والدرس نفسه ظهر هذا الأسبوع مع ثغرتين حرجتين في Citrix NetScaler أضافتهما وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية CISA إلى قائمة الثغرات المستغلة المعروفة في 27 سبتمبر. قالت الوكالة إن جهات تهديد تستغلهما فعليا حول العالم، وشجعت على البحث عن مؤشرات الاختراق قبل التحديث متى أمكن، وقالت إن على الجهة التي تشتبه في اختراقها أن تحفظ الأدلة الجنائية الرقمية قبل تطبيق التحديثات، لأن التحديث قد يمحو ما يدل على ما حدث. والقاعدة تنطبق هنا: افحص، واحفظ نسخة من السجلات، ثم حدث، دون أن يصبح الفحص سببا لتأجيل التحديث أياما.

إن كانت شبكتك خدمة مدارة: ماذا يقول عقدك؟

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

• في عقود الأطراف الخارجية التي قد تتأثر بإصابتها بياناتك أو خدماتك، ومنها اتفاقيات مستوى الخدمة: بنود عدم الإفصاح والحذف الآمن لبياناتك عند انتهاء الخدمة، وإجراءات التواصل عند وقوع حادثة سيبرانية، وإلزام الطرف الخارجي بتطبيق متطلبات الأمن السيبراني وسياساته لديك (الضابط 4-1-2).
• في عقود مزودي خدمات الإسناد والخدمات المدارة تحديدا: تقييم مخاطر الأمن السيبراني والتأكد من وجود ضوابط لمعالجتها قبل توقيع العقد، وأن تكون مراكز عمليات خدمات الأمن السيبراني المدارة للتشغيل والمراقبة التي تستخدم الوصول عن بعد موجودة بالكامل داخل المملكة (الضابط 4-1-3).
• في إدارة الثغرات: تصنيف الثغرات حسب خطورتها ومعالجتها بحسب التصنيف، والاشتراك في مصادر موثوقة لأخبار الثغرات الجديدة، والتحقق من التحديثات في بيئة غير إنتاجية قبل تطبيقها (الضابط 2-10-3).

ولاحظ ما لا تقوله ضوابط إدارة الثغرات: لا تحدد مدة زمنية لتطبيق تحديث حرج. هذا الرقم يجب أن يكتب في عقدك أنت، وإلا فالمزود يحدث حين يستطيع، لا حين تحتاج.

رسالة ترسلها لمزودك اليوم

لا تحتاج أن تكون تقنيا لتطرح هذه الأسئلة، ولا أن تنتظر اجتماعا. اطلب الإجابة مكتوبة:

• هل تعمل شبكتنا على Cisco Catalyst SD-WAN Manager؟ وأين يعمل: في سحابة سيسكو، أم في موقعنا، أم في مركز بياناتكم؟
• ما إصداره الحالي، ومتى تتم الترقية إلى الإصدار المصحح، باليوم والساعة؟
• هل واجهة النظام متاحة من الإنترنت الآن؟ وإن كانت كذلك، هل قيدتم الوصول إليها حتى تتم الترقية؟
• هل فحصتم السجلين اللذين ذكرتهما سيسكو بحثا عن المؤشرات المنشورة، وهل حفظتم نسخة منهما قبل التحديث؟ وما النتيجة؟
• من أبلغنا بهذا التنبيه أولا: أنتم أم خبر قرأناه؟ وما الإجراء المتفق عليه لإبلاغنا في المرة القادمة؟

السؤال الأخير أهمها. إن عرفت بالتنبيه من مقال لا من مزودك، فالمشكلة أكبر من هذه الثغرة.

نظرة أوريجامي

نحن نبني أنظمة أعمال، ولا نبيع أجهزة شبكات ولا نديرها. لكن كل نظام نبنيه لعميل متعدد الفروع يعمل فوق شبكة لم نصممها: نقطة البيع في الفرع ترسل إلى الخادم، والمستودع يحدث المخزون، والفاتورة الإلكترونية تخرج إلى المنصة. والإجابة المعتادة عن سؤال من يحدث الشبكة هي: المزود يتكفل بكل شيء. إجابة مطمئنة، لكنها ليست إجابة.

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

الخلاصة

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

مصادر

• سيسكو: النشرة الأمنية cisco-sa-sdwan-webauth-xr8beuuU للثغرة CVE-2026-76504 (30 سبتمبر 2026)
• الهيئة الوطنية للأمن السيبراني: تنبيه Cisco رقم 2026-7889 (30 سبتمبر 2026)
• الهيئة الوطنية للأمن السيبراني: الضوابط الأساسية للأمن السيبراني، الإصدار 2024
• CISA: ثغرات يوم الصفر المستغلة في Citrix NetScaler ADC و Gateway (سبتمبر 2026)