ثلاث ثغرات حرجة، ترقيع طارئ واحد
في 29 يوليو 2026، كشفت Broadcom عن ثلاث ثغرات حرجة تؤثر على منتجات افتراضية أساسية من VMware ورقّعتها. تحمل CVE-2026-59309، وهي تجاوز للمصادقة في vCenter، وCVE-2026-59310، وهي ثغرة اجتياز دليل تتيح تنفيذ كود عشوائي، درجة CVSS القصوى البالغة 9.8. أما الثغرة الثالثة، CVE-2026-47876، وهي كتابة خارج الحدود في محول الشبكة الافتراضي VMXNET3 بدرجة CVSS تبلغ 9.3، فتتيح لمهاجم يملك امتيازات إدارية محلية داخل جهاز افتراضي تنفيذ كود مباشرة على خادم ESXi المضيف — سيناريو إفلات من الجهاز الافتراضي يقوّض وعد العزل الأساسي الذي تقوم عليه الافتراضية نفسها.
وتؤثر الثغرات الثلاث جميعها على إصدارات حالية ومدعومة فعليًا: vCenter 8.0 وCloud Foundation/vSphere Foundation 9.0.x و9.1.x بالنسبة لثغرتي vCenter، وESXi 8.0 و9.0.x و9.1.x بالنسبة لثغرة VMXNET3، وفقًا للتقرير التقني من Rapid7. وصدرت الإصدارات المُصححة بالتزامن مع الإعلان: vCenter 9.1.0.0300، وvCenter 9.0.2.0100، وvCenter 8.0 U3k أو 8.0 U2f، وإصدارات ESXi المقابلة.
لا حل بديل يعني لا عذر للانتظار
التفصيل الذي كان ينبغي أن يُنذر كل مسؤول VMware في 29 يوليو ليس درجة CVSS وحدها — فثغرات CVE بخطورة حرجة أصبحت للأسف أمرًا روتينيًا — بل غياب أي إجراء تخفيفي عدا الترقيع. وتنص نشرة Rapid7 بوضوح على أنه «لا توجد حلول بديلة لـCVE-2026-59309 أو CVE-2026-59310، ما يجعل التحديثات المقدمة من المورّد هي المعالجة الأساسية». لم تكن هناك قاعدة جدار حماية، ولا تغيير في الإعداد، ولا ضابط تعويضي متاح للمنظمات غير القادرة على الترقيع فورًا — فقط التحديث نفسه.
كما أشارت Rapid7 إلى السبب التاريخي المحدد الذي جعل vCenter يستحق اهتمامًا عاجلًا حتى قبل بدء الاستغلال: فقد ظهر المنتج سابقًا عشر مرات في قائمة الثغرات المُستغَلة فعليًا (KEV) الخاصة بوكالة CISA بسبب ثغرات أخرى — ما يعني أن للمهاجمين نمطًا راسخًا في إعطاء الأولوية لـvCenter بمجرد أن تصبح ثغرة حرجة جديدة معلنة. وحثّت نشرة Rapid7 العملاء على «الترقيع بشكل عاجل قبل حدوث الاستغلال في الواقع» — وهي توصية، بالنظر بأثر رجعي، قلّلت من ضآلة الوقت الذي كانت المنظمات تملكه فعليًا.
من الترقيع إلى الحملة الفعلية خلال خمسة أيام
كانت الفجوة بين الإعلان والاستغلال قصيرة. ووفقًا لتقرير SecurityWeek، بدأ الاستغلال الفعلي لـCVE-2026-59310 في 3 أغسطس 2026 — أي بعد خمسة أيام فقط من إصدار ترقيع Broadcom في 29 يوليو. ومن هناك، تصاعد عدد الاختراقات بسرعة: أظهر تتبع BleepingComputer أن أولى الأنظمة المخترَقة اتصلت ببنية المهاجمين التحتية في 3 أغسطس، تلاها رصد 151 عنوان IP ضحية جديد بحلول 4 أغسطس، ثم 343 عنوان IP بحلول 5 أغسطس، ليصل الإجمالي إلى 361 عنوان IP عبر 47 دولة بحلول 7 أغسطس.
واستحوذت ألمانيا والولايات المتحدة وتركيا وإيران وفرنسا على أكثر من نصف جميع الضحايا المحددين، وفقًا لتقرير BleepingComputer. وقدّمت مجموعة الباحثين الأمنيين Quirso، التي استشهدت بها SecurityWeek، قراءة محددة للتوقيت: «رغم أن المهاجم ربما كان يملك معرفة مسبقة بالثغرة، فإن الارتباط القوي بين الإعلان والاستغلال يوحي بأن الإعلان كان نقطة الانطلاق الأولى للحملة» — بعبارة أخرى، من المرجح أن ملاحظات الترقيع وتفاصيل CVE نفسها شكّلت خارطة طريق للمهاجم.
إعلان
الحمولة: قذيفة عكسية مصممة للتحايل على جدران الحماية
وبمجرد الدخول إلى خادم Syslog ضعيف تابع لـvCenter، نشر المهاجمون reverse_ssh، وهو إطار عمل قذيفة SSH عكسية مفتوح المصدر، لتحقيق الاستمرارية. وتكمن القيمة المحددة لهذه الأداة بالنسبة للمهاجمين في بنيتها: فلأنها تبدأ اتصالًا صادرًا من الخادم المخترَق نحو بنية تحتية يتحكم بها المهاجم، بدلًا من أن يحتاج المهاجم إلى الاتصال الوارد، فإنها تعمل كقناة قيادة وتحكم يمكنها تجاوز قواعد جدار الحماية الواردة القياسية وضوابط أمن الشبكة الأخرى التي تفترض أن المهاجمين بحاجة للدخول، لا أن الأجهزة المخترَقة ستخرج للاتصال.
ونشرت Quirso قاعدة كشف عامة بصيغة YARA لملفات reverse_ssh التنفيذية عبر مستودعها العام على GitHub، ما يمنح المدافعين وسيلة لتعقب هذه الحمولة المحددة حتى دون معرفة ما إذا كانت نسخة vCenter الخاصة بهم قد اختُرقت بالفعل. وأخبر الباحثون SecurityWeek أنهم يشتبهون في تورط جهة تهديد متقدمة ومستمرة (APT) في هذه الحملة، لكنهم أبقوا مؤشرات الإسناد المحددة طي الكتمان ريثما يتم التنسيق مع جهات إنفاذ القانون — وهو نمط شائع عندما يعتقد المحققون أن الكشف المبكر قد يعرّض تحقيقًا نشطًا للخطر أو ينبّه جهة التهديد.
ماذا يعني هذا للمؤسسات التي تشغّل بنية تحتية من VMware
1. تعامل مع تنبيهات «لا يوجد حل بديل متاح» كطوارئ تلقائية من المستوى الأول
عندما تنص نشرة أمنية من المورّد صراحة على عدم وجود إجراء تخفيفي عدا الترقيع، ينبغي تجاوز الجداول الزمنية القياسية لإدارة التغيير. وينبغي أن تملك المنظمات عملية ترقيع طارئ مُعتمَدة مسبقًا مخصصة لهذه الفئة من التنبيهات — لا حل بديل، وCVSS حرجة، وبنية تحتية إدارية مواجهة للإنترنت — قادرة على التنفيذ خلال نافذة الخمسة أيام التي أثبتت هذه الحملة أنها واقعية لتسليح المهاجمين.
2. دقّق فيما إذا كان خادم Syslog التابع لـvCenter لديك مواجهًا للإنترنت أصلًا
تؤثر CVE-2026-59310 تحديدًا على مكوّن خادم Syslog في vCenter، واستهدف نمط الاستغلال النسخ التي يمكن الوصول إليها عبر الشبكة. وينبغي على المؤسسات التحقق من أن بنيتها التحتية الإدارية لـvCenter — بما فيها وظيفة خادم Syslog — غير مكشوفة على الإنترنت العام، إذ إن الافتراض التصميمي الأساسي لـvCenter هو أنه يقع على شبكة إدارية موثوقة، لا شبكة مواجهة للعامة.
3. انشر قاعدة YARA الخاصة بـreverse_ssh بغض النظر عن حالة الترقيع لديك
حتى المنظمات التي رقّعت الثغرة بسرعة ينبغي أن تشغّل قاعدة الكشف المنشورة من Quirso على بيئتها، لأن نافذة الاستغلال البالغة خمسة أيام تعني أن أي نسخة بقيت غير مرقّعة بين 29 يوليو وأوائل أغسطس ربما تكون قد اخترقت قبل المعالجة. فالترقيع يغلق الثغرة مستقبلًا؛ لكنه لا يزيل حمولة نُشرت بالفعل خلال نافذة التعرض.
4. راقب الاتصالات الصادرة من البنية التحتية الإدارية، لا الواردة فقط
تعتمد تقنية التحايل الأساسية لأداة reverse_ssh — الاتصالات التي تبدأ صادرة — على إفشال أوضاع الأمن المبنية أساسًا حول التصفية الواردة. وينبغي على فرق الأمن مراجعة مراقبة وتنبيهات حركة الخروج تحديدًا لـvCenter وخوادم إدارة الافتراضية الأخرى، إذ نادرًا ما تحتاج هذه الأنظمة لبدء اتصالات SSH صادرة نحو مضيفين خارجيين في التشغيل العادي، ما يجعل مثل هذه الاتصالات إشارة كشف عالية القيمة.
نمط يعترف به المورّدون والمدافعون على حد سواء
تتوافق هذه الحادثة مع شكل بات مألوفًا في أمن المؤسسات: ثغرة بخطورة قصوى في برمجيات بنية تحتية منتشرة على نطاق واسع، بلا حل بديل، وجدول زمني للاختراق يُقاس بأيام أحادية الرقم لا بأسابيع. وما يميز هذه الحالة هو دقة الأدلة — فجوة موثقة مدتها خمسة أيام بين الترقيع وأول استغلال، وعدد دقيق لعناوين IP والدول متتبَّع يومًا بيوم، وحمولة معروفة الاسم ومُحددة البصمة مع قاعدة كشف عامة متاحة بالفعل. وبالنسبة لكبار مسؤولي أمن المعلومات الذين يديرون بنية تحتية افتراضية، الدرس العملي ليس «رقّع VMware» بشكل مجرد، بل معيار ملموس: إذا كان بإمكان نشرة vCenter بدرجة CVSS تبلغ 9.8 ودون حل بديل أن تنتقل من الإعلان إلى 361 خادمًا مخترَقًا خلال تسعة أيام، فإن دورة الترقيع لدى أي منظمة يجب أن تُقاس وفق تلك الساعة، لا وفق راحة إدارة التغيير الداخلية.
الأسئلة الشائعة
ما هي CVE-2026-59310 ولماذا هي بهذه الخطورة؟
CVE-2026-59310 هي ثغرة اجتياز دليل في خادم Syslog التابع لـVMware vCenter بدرجة CVSS تبلغ 9.8، تتيح لجهة خبيثة تملك وصولًا شبكيًا تنفيذ كود عشوائي، وفقًا لـSecurityWeek. وقد رقّعتها Broadcom في 29 يوليو 2026، إلى جانب ثغرة مرتبطة لتجاوز المصادقة (CVE-2026-59309) وثغرة إفلات من الجهاز الافتراضي (CVE-2026-47876)، دون وجود حل بديل لأي من الثلاث.
ما مدى سرعة استغلال هذه الثغرة بعد الإعلان عنها؟
بدأ الاستغلال الفعلي في 3 أغسطس 2026 — بعد خمسة أيام من إصدار ترقيع 29 يوليو — وارتفع إلى 361 عنوان IP مخترقًا عبر 47 دولة بحلول 7 أغسطس 2026، وفقًا لتتبع BleepingComputer للحملة.
ماذا ينبغي أن تفعل المنظمات إذا لم ترقّع الثغرة بعد؟
ينبغي على المنظمات تطبيق تصحيحات Broadcom فورًا (vCenter 9.1.0.0300، أو 9.0.2.0100، أو 8.0 U3k/U2f) نظرًا لعدم وجود حل بديل، كما ينبغي عليها تشغيل قاعدة الكشف YARA المتاحة للعموم الخاصة بأداة reverse_ssh المستخدمة في حملة الهجوم للتحقق مما إذا كانت أنظمتها قد اخترقت بالفعل خلال نافذة التعرض، بغض النظر عن حالة الترقيع الحالية.
المصادر والقراءات الإضافية
- Critical VMware vCenter Vulnerabilities Allow Authentication Bypass and Remote Code Execution — Rapid7
- Critical VMware vCenter RCE flaw exploited for reverse SSH access — BleepingComputer
- Critical VMware vCenter Vulnerability in Attackers’ Crosshairs — SecurityWeek
- Three Critical VMware Flaws Allow Auth Bypass, Code Execution, and VM Escape — The Hacker News












