ثغرة CVE-2025-34028 في Commvault Command Center كانت من الحالات التي تجمع بين ثلاثة عوامل ترفع أولوية المعالجة بسرعة: إمكانية الوصول إلى الوظيفة المتأثرة دون مصادقة، ومعالجة حزم ZIP بصورة تسمح بـPath Traversal، وإمكانية تحويل ذلك في النهاية إلى Remote Code Execution (RCE) على خادم Command Center.
لم تعد القضية مجرد ثغرة ذات تقييم مرتفع أو Proof of Concept منشور. فقد أضافتها CISA إلى Known Exploited Vulnerabilities Catalog في 2 مايو 2025، ما يؤكد وجود دليل على الاستغلال الفعلي. وحتى في 2026، تبقى هذه المعلومة مهمة عند التحقيق في أي خادم كان معرضًا للإنترنت قبل تطبيق التصحيحات، لأن تثبيت التحديث الآن لا يثبت أن النظام لم يتعرض للاختراق سابقًا.
ما هي CVE-2025-34028؟
CVE-2025-34028 هي ثغرة حرجة في Commvault Command Center Innovation Release 11.38 على Windows وLinux. وفق التنبيه الأمني الرسمي من Commvault، يستطيع مهاجم بعيد غير مصادق استغلال المشكلة للوصول إلى تنفيذ كود على خادم Command Center المتأثر.
المشكلة ليست ثغرة عامة في جميع منتجات وإصدارات Commvault. التنبيه الرسمي يحصر CVE-2025-34028 في Command Center ضمن Innovation Release 11.38، لذلك يجب تحديد المنتج والإصدار ومستوى التحديث الفعلي بدل افتراض أن كل بيئة Commvault معرضة للمشكلة نفسها.
إذا كانت مصطلحات مثل CVE وRCE وPoC وCVSS غير مألوفة، يشرح دليل مصطلحات الأمن السيبراني الأساسية الفرق بينها ولماذا لا يعني وجود PoC وحده أن الاستغلال حدث فعليًا.
كيف تحولت معالجة ZIP إلى تنفيذ كود عن بُعد؟
شرح الباحثين في watchTowr Labs يوضح أن المسار لم يكن مجرد خطأ بسيط في فك ضغط ملف. كانت المشكلة في سلسلة من السلوكيات التي يمكن جمعها للوصول إلى نتيجة أخطر.
على مستوى مبسط، كان السيناريو كالتالي:
- توجد وظيفة في Command Center يمكن الوصول إليها قبل تسجيل الدخول.
- يمكن أن تجعل هذه الوظيفة الخادم يتعامل مع حزمة تثبيت ZIP.
- المسار المستخدم أثناء معالجة الحزمة لم يكن مقيدًا بما يكفي.
- يمكن لمحتويات الحزمة الوصول إلى موقع خارج المجلد المقصود عبر Path Traversal.
- إذا وصل ملف قابل للتنفيذ من جانب الخادم إلى مكان يخدمه التطبيق، يمكن تحويل الكتابة غير المقصودة إلى RCE.
لهذا السبب لا يكفي وصف CVE-2025-34028 بأنها «ثغرة Path Traversal» فقط. Path Traversal كان جزءًا من السلسلة، بينما جاء الأثر الحرج من قدرة المهاجم على التأثير في مكان كتابة الملفات ثم الوصول إلى كود ينفذه خادم الويب.
ويصنف سجل NVD الحالي المشكلة ضمن CWE-22 المرتبطة بعدم تقييد مسارات الملفات بصورة صحيحة، كما يدرج CWE-306 المرتبطة بغياب المصادقة عن وظيفة حساسة.
لماذا عدم الحاجة إلى تسجيل الدخول مهم؟
وجود RCE بعد المصادقة يختلف أمنيًا عن إمكانية بدء الهجوم من جهة لا تمتلك حسابًا أصلًا. في CVE-2025-34028 لا تتطلب السلسلة المنشورة بيانات اعتماد مستخدم داخل Commvault، ولا تعتمد على قيام موظف بفتح ملف أو الضغط على رابط.
إذا كانت واجهة Command Center الضعيفة متاحة مباشرة من شبكة يستطيع المهاجم الوصول إليها، يصبح سطح الهجوم أكبر بكثير مقارنة بثغرة تحتاج أولًا إلى اختراق حساب شرعي.
ولهذا تصبح مسألة Reachability مهمة عند تقييم الخطر الفعلي. خادم قديم ومعرض للإنترنت يختلف عن نظام معزول لا يمكن الوصول إلى واجهته الإدارية إلا من شبكة إدارة محددة، مع أن العزل لا يحول النسخة الضعيفة إلى نسخة آمنة ولا يغني عن التصحيح.
ما الإصدارات المتأثرة وما الإصلاح الصحيح؟
بحسب Commvault، الإصدارات الأساسية المتأثرة هي 11.38.0 إلى 11.38.19 من Innovation Release على Windows وLinux، مع اعتبار 11.38.20 إصدارًا يتضمن مسار الإصلاح.
لكن توجد نقطة مهمة عند التحقق من بيئة حقيقية: لا ينبغي الاعتماد على رقم الإصدار الأساسي وحده. التنبيه الأمني المحدث من Commvault يحدد أيضًا Additional Updates يجب التحقق من وجودها.
| الإصدار | التحديثات التي تحددها Commvault للإصلاح |
|---|---|
| 11.38.20 | SP38-CU20-433 وSP38-CU20-436 |
| 11.38.25 | SP38-CU25-434 وSP38-CU25-438 |
ولهذا قد تكون عبارة «لدينا 11.38.20» وحدها غير كافية لتوثيق أن كل Command Center instance محمي. توصي Commvault بفتح قائمة Servers داخل Command Center، وفحص كل تثبيت، والتأكد من ظهور التحديثات الإضافية المطلوبة.
وتشير الشركة إلى أن عملاء Commvault SaaS حصلوا على التصحيحات اللازمة تلقائيًا من جانب Commvault، بينما تحتاج البيئات التي يديرها العميل إلى التحقق من حالة تحديثها بنفسها.
هل درجة CVSS هي 10 أم 9.3؟
قد يجد القارئ أرقامًا مختلفة عند مقارنة المصادر. تنبيه Commvault يعرض الثغرة بدرجة 10، بينما يعرض سجل NVD الحالي تقييم CVSS 4.0 من الجهة المسؤولة عن سجل CVE بدرجة 9.3 Critical.
هذا الاختلاف لا يغير القرار العملي الأساسي. CVSS يصف خصائص تقنية للثغرة وفق إصدار وطريقة حساب محددة، لكنه ليس المقياس الوحيد للأولوية. في هذه الحالة توجد أيضًا إمكانية RCE دون مصادقة، وPoC عام، وإدراج رسمي في CISA KEV بسبب دليل الاستغلال.
هل يوجد Proof of Concept؟ وهل استُغلت الثغرة فعليًا؟
نعم في الحالتين، لكن يجب الفصل بينهما.
نشر watchTowr تحليلًا تقنيًا وProof of Concept في أبريل 2025 يوضح إمكانية الوصول إلى Pre-Authentication RCE. وجود PoC يعني أن مسار الاستغلال أصبح موثقًا وقابلًا لإعادة الاختبار، لكنه وحده لا يثبت أن مهاجمين استخدموه ضد أهداف حقيقية.
التغيير الأهم حدث في 2 مايو 2025 عندما أدرجت CISA CVE-2025-34028 في Known Exploited Vulnerabilities Catalog. ويعرض NVD حاليًا حالة الاستغلال لدى CISA على أنها active.
كما أصدرت المديرية العامة لأمن نظم المعلومات DGSSI في المغرب تنبيهًا في أبريل 2025 دعت فيه إلى تحديث الإصدارات المتأثرة، وصنفت مستوى الخطر والتأثير على أنه حرج.
لا تخلط CVE-2025-34028 مع CVE-2025-3928
هناك سبب إضافي يستدعي الدقة عند قراءة أخبار Commvault في 2025. فقد تعاملت الشركة في الفترة نفسها مع ثغرة أخرى هي CVE-2025-3928، مرتبطة بخوادم الويب في إصدارات أخرى من Commvault وتتطلب بيانات اعتماد مستخدم شرعي للاستغلال وفق التنبيه CV_2025_03_1.
كما ربطت Commvault CVE-2025-3928 بتحقيق منفصل بدأ بعد إخطار Microsoft للشركة في فبراير 2025 بشأن نشاط من جهة تهديد مرتبطة بدولة داخل بيئة Azure الخاصة بها. وذكرت الشركة لاحقًا أن بعض بيانات اعتماد تطبيقات M365 لدى مجموعة من العملاء ربما كانت قد تعرضت للوصول.
هذا لا يعني تلقائيًا أن CVE-2025-34028 هي نفسها الثغرة المستخدمة في ذلك الحادث. CVE-2025-34028 وCVE-2025-3928 ثغرتان مختلفتان بمتطلبات ونطاقات إصدارات مختلفة، ومن المهم عدم دمج قصتيهما في حادث واحد دون دليل.
كيف تتحقق من تعرض بيئتك؟
إذا كنت مسؤولًا عن Commvault، ابدأ بحالة النظام الفعلية بدل البحث عن اسم CVE فقط.
- احصر جميع Command Center instances: بما في ذلك الخوادم القديمة أو بيئات الاختبار التي قد لا تكون ضمن قائمة الأصول الرئيسية.
- سجل الإصدار الكامل: لا تكتفِ بعبارة 11.38، بل حدد Build وUpdate level لكل خادم.
- تحقق من Additional Updates: قارنها بالقائمة الحالية في Advisory الرسمية.
- حدد مدى الوصول الشبكي: هل كانت واجهة Command Center متاحة من الإنترنت أو من شبكات واسعة داخل المؤسسة؟
- حدد الفترة الزمنية: متى أصبح الخادم معرضًا، ومتى طبقت التصحيحات؟
- راجع السجلات التاريخية: خصوصًا إذا ظل الخادم الضعيف قابلًا للوصول بعد نشر التفاصيل التقنية أو أثناء وجود استغلال معروف.
هذه العملية جزء من إدارة الثغرات وليست مجرد تثبيت تحديث. فالمؤسسة تحتاج إلى معرفة الأصل المتأثر، ومدى تعرضه، ووجود استغلال معروف، ثم تحديد ما إذا كانت المعالجة وحدها كافية أم أن التحقيق في حادث محتمل أصبح ضروريًا.
ما الذي يستحق البحث عنه في السجلات؟
الهدف من Threat Hunting هنا ليس الاعتماد على عنوان IP واحد أو Indicator ثابت قد يتغير، بل البحث عن سلوك لا يتوافق مع التشغيل المعتاد لـCommand Center.
- طلبات غير معتادة إلى وظائف تثبيت أو نشر الحزم في Command Center.
- كتابة ملفات في مجلدات يخدمها Web Server دون وجود عملية إدارية تفسر ذلك.
- ظهور ملفات JSP أو ملفات تنفيذية غير معروفة في مسارات التطبيق.
- عمليات جديدة ينشئها Web Server أو Java ولم تكن تظهر عادة في Baseline الخادم.
- اتصالات Outbound غير متوقعة من Command Center إلى عناوين خارجية.
- حسابات جديدة أو تغييرات صلاحيات أو وسائل Persistence ظهرت خلال الفترة المشبوهة.
- محاولات تعطيل Logging أو إزالة ملفات وسجلات بعد نشاط غير طبيعي.
إذا كانت المؤسسة تعمل عبر مركز عمليات أمنية SOC، فمن الأفضل ربط سجلات الويب والعمليات والشبكة والهوية في Timeline واحد بدل التحقيق في كل مصدر بصورة منفصلة.
هل يكفي تثبيت Patch؟
إذا اكتشفت الثغرة قبل حدوث أي تعرض وكان لديك دليل جيد على عدم إمكانية الوصول إلى المسار الضعيف، فقد يكون التصحيح وإعادة التحقق من الإعدادات هو الإجراء الرئيسي.
أما إذا كان Command Center متأثرًا ومتاحًا لجهات غير موثوقة خلال فترة كان فيها الاستغلال معروفًا، فهناك سؤالان مختلفان يجب الإجابة عنهما:
- هل الثغرة ما زالت موجودة؟ يحل ذلك التحديث الصحيح.
- هل استُغلت قبل التحديث؟ لا يجيب Patch عن هذا السؤال، بل يحتاج إلى Logs وForensics وThreat Hunting.
إذا ظهرت مؤشرات اختراق، يصبح التعامل مع الحالة Incident Response وليس مجرد Vulnerability Management. وقد يتطلب ذلك عزل الخادم، والحفاظ على الأدلة، وفحص الحسابات والأسرار وبيانات الاعتماد التي كان يستطيع النظام الوصول إليها، ثم تحديد مدى الحركة إلى أنظمة أخرى.
ماذا تفعل إذا تعذر التحديث فورًا؟
توصية Commvault الرسمية هي عزل Command Center عن الوصول من الشبكات الخارجية إذا تعذر تثبيت التحديث في الوقت المناسب.
التخفيف هنا يجب فهمه كحل مؤقت. تقليل Reachability يمكن أن يمنع جهات كثيرة من الوصول إلى الوظيفة المتأثرة، لكنه لا يصلح الخطأ الموجود في البرنامج نفسه.
عمليًا، يجب أن تكون واجهات الإدارة والنسخ الاحتياطي قابلة للوصول فقط من الأنظمة والمستخدمين الذين يحتاجون إليها، مع تطبيق قواعد Firewall وNetwork Segmentation ومراقبة مناسبة بدل نشر واجهة الإدارة مباشرة على الإنترنت دون ضرورة.
لماذا تعد أنظمة النسخ الاحتياطي هدفًا حساسًا؟
اختراق منصة إدارة Backup ليس مماثلًا لاختراق تطبيق هامشي. أنظمة النسخ الاحتياطي والاستعادة توجد غالبًا في موقع عالي الثقة داخل البنية التحتية، وقد تمتلك اتصالًا بعدد كبير من الخوادم والبيانات وبيئات السحابة.
ولهذا لا ينبغي قياس خطورة CVE-2025-34028 بدرجة CVSS فقط. السؤال الأهم لكل مؤسسة هو: ماذا يستطيع Command Center المحدد الوصول إليه داخل بيئتها؟
كلما ارتفعت صلاحيات النظام واتسع نطاق الأصول التي يديرها، زاد أثر أي اختراق محتمل. وهذا يجعل عزل أنظمة الإدارة، وتطبيق أقل قدر من الصلاحيات، وتقييد الاتصالات، ومراقبة السلوك جزءًا من تصميم الحماية وليس إجراءات إضافية بعد ظهور CVE.
ما الوضع الحالي للثغرة في 2026؟
CVE-2025-34028 ليست Zero-Day جديدة في 2026. لقد كُشفت وعولجت من Commvault في 2025، وأصبحت تفاصيلها التقنية وPoC الخاص بها معروفة منذ ذلك الوقت.
لكنها ما زالت ذات أهمية دفاعية لسببين. الأول أنها مدرجة في CISA KEV بسبب الاستغلال المعروف. والثاني أن البيئات القديمة أو غير المدارة جيدًا قد تستمر في تشغيل إصدارات أو مستويات تحديث ضعيفة بعد فترة طويلة من صدور الإصلاح.
الوضع الصحيح اليوم هو التعامل معها كثغرة معروفة ومصححة ولها تاريخ استغلال، وليس كتهديد جديد لم يصدر له علاج.
الخلاصة
CVE-2025-34028 كانت ثغرة Pre-Authentication خطيرة في Commvault Command Center Innovation Release 11.38. سمحت سلسلة مرتبطة بمعالجة حزم ZIP وPath Traversal بوضع ملفات في مواقع غير مقصودة وتحويل ذلك إلى Remote Code Execution على الخادم المتأثر.
أصدرت Commvault التصحيحات وحددت Additional Updates المطلوبة، ثم أصبح PoC متاحًا للعامة، وأدرجت CISA الثغرة في KEV في مايو 2025 بعد ظهور دليل على الاستغلال.
لذلك، إذا كانت لديك بيئة Commvault قديمة، لا يكفي التأكد من رقم الإصدار فقط. تحقق من مستوى التصحيح الفعلي، ومن وجود التحديثات الإضافية المحددة في Advisory، ومن تاريخ تعرض Command Center للشبكات غير الموثوقة. وإذا كان النظام ظل معرضًا أثناء فترة الاستغلال المعروف، اجمع بين التصحيح وتقليل سطح الهجوم والتحقيق التاريخي في السجلات بدل افتراض أن تثبيت Patch ينهي كل المخاطر السابقة.