إذا كان نشاطك التجاري يستخدم جدارًا ناريًا من SonicWall، أو إذا كنت تستعين بمزوّد خدمات مُدارة (MSP) لتعهيد خدمات تقنية المعلومات إليه، بحيث يسجّل الدخول عن بُعد للحفاظ على تحديث أنظمتك ونسخها الاحتياطية، فلديك سببان منفصلان لإجراء مكالمة هاتفية هذا الأسبوع. كلاهما يتعلق بثغرات يستغلها المهاجمون الآن، وليس بمخاطر نظرية في نشرة مورّد لا يقرأها أحد. ولا يتطلب أيٌّ منهما أن تصبح خبيرًا في الأمن. المطلوب هو أن تطرح أسئلة محددة وتتوقع إجابات محددة — تواريخ، وأرقام إصدارات، وتأكيدات — لا عبارات تطمين.
إليك ما يحدث في كل حالة، وقائمة تحقق يمكنك نسخها ولصقها وإرسالها إلى من يدير شبكتك.
المشكلة 1: جدار SonicWall الناري لديك (CVE-2026-15409 وCVE-2026-15410)
كشفت SonicWall عن ثغرتين وأصدرت تصحيحات لهما في 14 يوليو 2026 — لكن وفقًا للخط الزمني الخاص بالشركة، كان المهاجمون قد بدأوا استغلالهما قبل الكشف العلني بنحو ثلاثة أسابيع. وهذا يعني أن «تم التصحيح الآن» و«أصبح آمنًا الآن» ليسا بالضرورة الشيء نفسه بالنسبة إلى جهاز كان مكشوفًا على الإنترنت خلال تلك الفترة.
الجهة المهدِّدة التي يُشار إليها باستمرار أكبر من غيرها في ما يتعلق بسلسلة الثغرات هذه هي INC، وهي عملية برمجيات فدية كخدمة يصفها باحثو Rapid7 بأنها واحدة من أنشط المجموعات من هذا النوع على مستوى العالم حاليًا (مع أن كل هجوم يستخدم هذه الثغرات لم يُربط على نحو قاطع بـ INC تحديدًا — ومن شبه المؤكد أيضًا تورط مهاجمين انتهازيين آخرين). وبشكل منفصل، أبلغت شركة الأمن Huntress عن حملة سريعة الوتيرة اختُرقت خلالها أنظمة 30 عميلًا من عملاء SonicWall في أقل من يومين. هذا ليس خطرًا يتطور ببطء.
وهناك أيضًا سوابق ذات صلة هنا: فقد كشفت SonicWall سابقًا عن حادثة سرقت فيها مجموعة مدعومة من دولة ملفات إعدادات الجدار الناري من كل عميل من عملاء SonicWall الذين كانوا يستخدمون ميزة النسخ الاحتياطي السحابي. ويمكن أن يحتوي ملف الإعدادات المسروق على بيانات اعتماد الحسابات المحلية وإعدادات VPN. إذا سبق نسخ إعدادات جدارك الناري احتياطيًا إلى الخدمة السحابية لـ SonicWall قبل احتواء تلك الحادثة، فإن تصحيح العيوب الحالية لا يلغي ما كُشف بالفعل — وقد تظل بيانات الاعتماد الموجودة في ذلك الإعداد بحاجة إلى التغيير.
قائمة تحقق لإرسالها إلى مزوّد خدمات تقنية المعلومات أو MSP:
- «ما طراز SonicWall وإصدار البرنامج الثابت اللذان نشغّلهما حاليًا، وهل يعالج ذلك الإصدار الثغرتين CVE-2026-15409 وCVE-2026-15410؟» (اطلب منهم التأكيد بالرجوع إلى النشرة الاستشارية الخاصة بـ SonicWall — ولا تقبل عبارة «نحن على أحدث إصدار» من دون رقم الإصدار.)
- «ما التاريخ الذي طبّقنا فيه التصحيح؟» إذا كان ذلك بعد 14 يوليو 2026، فاطلب منهم فحص السجلات التي تغطي الأسابيع القليلة السابقة بحثًا عن مؤشرات وصول غير مصرّح به — مثل عمليات تسجيل دخول غير متوقعة للمسؤولين، أو حسابات محلية جديدة، أو جلسات SSLVPN من عناوين IP غير مألوفة.
- «هل كانت بوابة SSLVPN أو بوابة الوصول عن بُعد لدينا مكشوفة على الإنترنت خلال تلك الفترة؟» إذا كانت الإجابة نعم، فاطلب إعادة تعيين إلزامية لكلمات المرور لكل حساب يُصادق عبرها، وليس تطبيق تصحيح فحسب.
- «هل سبق نسخ إعدادات جدارنا الناري احتياطيًا إلى الخدمة السحابية لـ SonicWall، وإذا كان الأمر كذلك، فهل جرى تغيير بيانات الاعتماد الموجودة في ملف الإعدادات منذ ذلك الحين؟»
- «هل فعّلتم المصادقة متعددة العوامل على جميع حسابات الوصول عن بُعد عبر الجدار الناري؟» إذا لم تكن مفعّلة، فاطلب منهم تفعيلها هذا الأسبوع.
المشكلة 2: أداة الإدارة عن بُعد الخاصة بمزوّد خدمات تقنية المعلومات (CVE-2026-18577 في N-able N-central)
هذه الحالة مختلفة لأن الأمر لا يتعلق بمعداتك — بل بأداة قد يستخدمها مزوّد خدمات تقنية المعلومات لإدارة عشرات أو مئات الشركات العميلة، وربما شركتك من بينها، من وحدة تحكم مركزية واحدة. وتُعد N-able N-central إحدى هذه المنصات، وقد أضافت CISA (وكالة الأمن السيبراني وأمن البنية التحتية في الولايات المتحدة) ثغرة فيها — CVE-2026-18577، بتصنيف 8.2 من 10 من حيث الخطورة — إلى كتالوج الثغرات المستغلة المعروفة لديها بعد تأكيد استغلالها فعليًا منذ 31 يوليو 2026. ويُقال إن العيب يتيح للمهاجم الحصول على وصول إداري كامل إلى وحدة تحكم N-central نفسها.
وهذا مهم بسبب ما يستطيع المهاجم فعله من هناك. فقد أفادت Huntress بأن الهجمات الناجحة انتقلت من وحدة التحكم المخترقة إلى نقاط النهاية التي تُدار عبرها — ما يعني أن اختراق أداة مزوّد خدمات تقنية المعلومات يمكن أن يتحول إلى اختراق لأنظمتك من دون أن يستهدفك المهاجم مباشرةً على الإطلاق. كما وجدت Huntress أن المهاجمين كانوا ينشئون أنفاق Cloudflare على الأنظمة المخترقة، وهي تقنية تمنحهم وسيلة دائمة ومشفّرة للعودة، ويمكن أن تبدو كأنها حركة مرور ويب عادية بالنسبة إلى الجدار الناري.
لا تحتاج إلى معرفة ما إذا كان مزوّدك المحدد يستخدم N-central. ما تحتاج إليه هو أن تسأل، وأن تطرح السؤال على نحو أوسع من مجرد اسم ذلك المنتج الواحد.
قائمة تحقق لإرسالها إلى مزوّد خدمات تقنية المعلومات أو MSP:
- «هل تستخدمون N-able N-central، أو أي منتج آخر من N-able، لإدارة أنظمتنا؟» إذا كانت الإجابة نعم: «هل جرى تصحيحه ضد CVE-2026-18577، وفي أي تاريخ؟»
- «هل راجعتم نشاط حسابات المسؤولين وسجلات الوصول في وحدة تحكم الإدارة لديكم منذ 31 يوليو 2026 بحثًا عن أي شيء لا تستطيعون تفسيره؟»
- «هل فحصتم أنظمتنا تحديدًا بحثًا عن اتصالات صادرة غير متوقعة — ولا سيما عمليات أنفاق Cloudflare (التي تظهر أحيانًا باسم 'cloudflared') أو نطاقات الأنفاق التي لم نُنشئها؟»
- «هل دُفعت إلى أنظمتنا أي حسابات مسؤول محلية جديدة، أو مهام مجدولة، أو سياسات إدارة عن بُعد جديدة لا تستطيعون نسبتها إلى فريقكم؟»
- «إذا كنتم لا تستخدمون N-central، فما أداة الإدارة عن بُعد التي تستخدمونها بدلًا منه، وهل أُضيفت إليها مؤخرًا أي ثغرات إلى كتالوج CISA للثغرات المستغلة المعروفة؟»
ما الذي ينبغي فعله بالإجابات
سيجيب مزوّد خدمات تقنية المعلومات الجيد عن هذه الأسئلة بتواريخ وتفاصيل، وغالبًا خلال يوم واحد، لأنه ينبغي أن يكون على علم بهذه المعلومات أصلًا أو قادرًا على استخراجها من السجلات بسرعة. أما الإجابة المبهمة — «نحن مسيطرون على الوضع»، «أنظمتنا آمنة»، من دون تقديم تواريخ — فهي بحد ذاتها معلومة مفيدة: فهي تخبرك بأن هذه المحادثة تحتاج إلى أن تتكرر، خطيًا، مع تحديد موعد نهائي.
إذا كنت تدير SonicWall بنفسك من دون MSP، تظل قائمة التحقق أعلاه منطبقة عليك مباشرةً — سجّل الدخول بنفسك إلى وحدة تحكم الإدارة، وتحقق من إصدار البرنامج الثابت، وتحقق من صفحة النشرات الاستشارية لدى SonicWall لمعرفة الإصدار الذي يعالج كلتا الثغرتين CVE.
لا تتطلب أيٌّ من هذين العيبين أن تستغني عن مورّد أو تفصل مزوّد خدمة. بل تتطلبان التأكد من أن الثغرة المحددة قد أُغلقت، وأن شيئًا لم يتسلل عبرها أثناء بقائها مفتوحة. اطرح الأسئلة، واحصل على التواريخ، وضع تذكيرًا في تقويمك لتطرحها مجددًا في المرة القادمة التي يفصح فيها مورّد عن أمر «يُستغل بنشاط». سيحدث ذلك مجددًا.
