كشف باحثون أمنيون عن تفاصيل ثغرة Click2Shell في نواة ووردبريس، وهي مشكلة تسمح لرابط مُعد بعناية بأن يدفع موقعًا يعمل بإصدار متأثر إلى تثبيت قالب من دليل WordPress.org تلقائيًا عندما يفتح الرابط مسؤول موقع مسجل الدخول. الخطورة الأكبر تظهر عند دمج الخلل مع ثغرة ثانية داخل القالب المثبت، ما قد يقود في سيناريو متسلسل إلى تنفيذ كود PHP على الخادم.
الإجابة السريعة
تم إصلاح ثغرة Click2Shell ضمن WordPress 7.1.1 الصادر في 17 سبتمبر 2026. الخلل في حد ذاته لا يثبت قالبًا عشوائيًا من خارج WordPress.org ولا ينفذ كودًا مباشرة، لكنه يسمح لمهاجم غير مسجل بإجبار متصفح مسؤول ووردبريس المسجل دخوله على تثبيت قالب حقيقي من الدليل الرسمي عند فتح رابط مُصمم خصيصًا. وقد أثبت باحثو pwn.ai إمكانية دمج ذلك مع ثغرة منفصلة في قالب ضعيف للوصول إلى تنفيذ كود على الخادم. لا توجد حتى الآن إشارة منشورة إلى استغلال الخلل في هجمات فعلية.
ما الذي حدث بالضبط؟
أدرج WordPress.org في ملاحظات الإصدار 7.1.1 إصلاحًا لمشكلة تسمح لروابط مصممة خصيصًا بتثبيت قالب غير نشط من WordPress.org ومعاينته تلقائيًا. وبعد صدور التحديث نشر فريق pwn.ai التفاصيل التقنية وسمى سلسلة الهجوم ثغرة Click2Shell.
الفكرة الأساسية تعتمد على اختلاف طريقة تفسير قيمة واحدة بين واجهة Themes API التابعة لـWordPress.org وبين JavaScript داخل لوحة إدارة ووردبريس. واجهة الدليل تتعامل مع القيمة باعتبارها اسم قالب عاديًا وتعيد سجل قالب حقيقي، بينما يحتفظ المتصفح ببعض الرموز الأصلية داخل القيمة عند استخدامها لاحقًا في محدد jQuery داخل صفحة الإدارة.
كيف يمكن أن يؤدي الرابط إلى تثبيت قالب؟
بحسب تحليل pwn.ai، يستطيع المهاجم تجهيز رابط خاص بصفحة تثبيت القوالب. إذا فتحه مسؤول موقع مسجل الدخول، تقوم صفحة الإدارة بجلب القالب الحقيقي من الدليل الرسمي، لكن القيمة نفسها تُستخدم لاحقًا بطريقة تسمح بتوجيه JavaScript إلى زر التثبيت الحقيقي داخل بطاقة القالب.
المهم هنا أن المهاجم لا يحتاج إلى حساب داخل الموقع ولا إلى امتلاك صلاحية تثبيت القوالب بنفسه؛ الجلسة المفتوحة لمسؤول الموقع هي التي توفر الصلاحية ووسيلة التحقق المطلوبة. لذلك يصف الباحثون ثغرة Click2Shell بأنها هجوم يعتمد على خداع مسؤول مسجل الدخول لفتح الرابط.
القالب يتم تثبيته لكنه يظل غير نشط
من التفاصيل المهمة أن القالب الذي يتم تنزيله لا يصبح القالب النشط للموقع تلقائيًا. يظل القالب الأصلي للموقع فعالًا، ولذلك قد لا يلاحظ المسؤول أي تغيير بصري بعد فتح الرابط.
وهذا يفسر جانبًا من خطورة السيناريو: التثبيت يمكن أن يحدث في الخلفية من دون أن يتغير مظهر الموقع. لكن ثغرة Click2Shell الأساسية وحدها لا تعني أن المهاجم حصل مباشرة على تنفيذ كود أو سيطرة كاملة على الموقع.
متى تتحول المشكلة إلى تنفيذ كود على الخادم؟
للوصول إلى Remote Code Execution احتاج الباحثون إلى ثغرة ثانية منفصلة داخل قالب تم تثبيته من الدليل الرسمي. استخدم فريق pwn.ai قالبًا كان يحتوي على معالج AJAX غير محمي بالشكل الكافي، يستطيع جلب حزمة من عنوان يختاره المهاجم وتشغيل كودها.
عندما تتم معاينة القالب غير النشط عبر Customizer، يستطيع ووردبريس تحميل PHP الخاص به رغم أن القالب لم يتم تفعيله. هنا تمكن الباحثون من ربط ثغرة Click2Shell بخلل القالب الثاني للوصول في النهاية إلى تنفيذ PHP على الخادم.
هذا التفصيل مهم حتى لا يتم تضخيم الخبر: الخلل الموجود في نواة ووردبريس لا ينفذ كودًا عشوائيًا وحده، بل يحتاج إلى وجود ثغرة إضافية قابلة للاستغلال داخل القالب الذي جرى تثبيته.
ما درجة الخطورة؟
صنّف باحثو pwn.ai مشكلة التثبيت القسري وحدها بدرجة 7.1 وفق CVSS، أي ضمن مستوى High، بينما أعطوا سلسلة الهجوم الكاملة التي تصل إلى تنفيذ كود درجة 9.6 ضمن Critical. هذه الدرجات صادرة عن الفريق البحثي وليست تقييمًا رسميًا منشورًا من WordPress، لكنها توضح لماذا حظيت ثغرة Click2Shell باهتمام أمني واسع بعد نشر التفاصيل.
أما WordPress.org فاكتفى في ملاحظات الإصدار بوصف المشكلة بأنها روابط خاصة يمكنها تثبيت قالب غير نشط من WordPress.org ومعاينته تلقائيًا، مع شكر الباحثين الذين أبلغوا عنها.
هل تم استغلال Click2Shell في هجمات حقيقية؟
حتى وقت نشر التفاصيل، لا توجد إشارة معلنة إلى استخدام ثغرة Click2Shell في هجمات فعلية. وهذا فرق مهم بينها وبين بعض ثغرات ووردبريس الأخرى التي ظهرت خلال الشهور الماضية وتم رصد استغلالها عمليًا.
لكن غياب دليل على الاستغلال لا يعني إمكانية تجاهل المشكلة، خصوصًا بعد نشر التفاصيل التقنية. WordPress نفسه أوصى بتثبيت WordPress 7.1.1 فورًا لأنه إصدار أمني يتضمن 11 إصلاحًا أمنيًا إلى جانب إصلاحات الصيانة.
ما الإصدارات المتأثرة؟
تشير التفاصيل المنشورة إلى أن المشكلة كانت موجودة في إصدارات ووردبريس من 6.0 وحتى الإصدارات السابقة مباشرة للإصلاح. وقد تم إصلاحها في WordPress 7.1.1، مع نقل الإصلاحات الأمنية إلى الفروع القديمة المؤهلة للحصول على تحديثات أمنية.
إذا كنت تستخدم الإصدار الحالي، فالحل المباشر هو التحديث إلى 7.1.1. أما المواقع الموجودة على فرع أقدم، فيجب تثبيت تحديث الأمان المطابق لذلك الفرع فور توفره، مع بقاء أحدث إصدار هو الخيار المدعوم بنشاط بصورة كاملة.
WordPress 7.1.1 هو الحل المباشر
سبق أن تناولنا على سوالف تفاصيل تحديث ووردبريس 7.1.1 و11 إصلاحًا أمنيًا، وكان هذا الخلل واحدًا من المشكلات التي عالجها الإصدار. الجديد الآن هو أن pwn.ai نشر تفاصيل سلسلة الهجوم وكيف يمكن تحويل التثبيت القسري إلى تنفيذ كود عند وجود ثغرة ثانية في قالب مناسب.
ولا توجد توصية رسمية بحل بديل منفصل إذا كان التحديث متاحًا. لذلك فإن الإجراء الأهم لأصحاب المواقع هو التأكد من تثبيت الإصدار الأمني بدل الاعتماد على محاولة حجب روابط أو تعطيل صفحة معينة.
هل يجب حذف القوالب غير النشطة؟
التحديث هو الخطوة الأساسية، لأن ثغرة Click2Shell تُغلق من خلال إصلاح النواة، لكن من الممارسات الجيدة عمومًا تقليل عدد القوالب والإضافات غير المستخدمة. ومع ذلك لا ينبغي الخلط بين هذه النصيحة وبين علاج المشكلة نفسها؛ المشكلة تبدأ من نواة ووردبريس المتأثرة، وبالتالي تحديث Core هو ما يغلق المسار الأساسي للهجوم الموصوف.
كما أن وجود قالب غير نشط على الموقع لا يعني تلقائيًا أنه قابل للاستغلال. سلسلة الباحثين احتاجت إلى خلل منفصل داخل قالب بعينه، وهو ما يؤكد أهمية تحديث القوالب والإضافات أيضًا وعدم الاحتفاظ بمكونات قديمة بلا حاجة.
ما الذي يجب على مدير الموقع فعله الآن؟
- التأكد من أن ووردبريس يعمل على الإصدار 7.1.1 أو تحديث الأمان المناسب للفرع المستخدم.
- مراجعة نجاح التحديث وعدم الاكتفاء بوجود تحديث تلقائي مفترض.
- تحديث القوالب والإضافات إلى أحدث الإصدارات المتاحة.
- إزالة القوالب والإضافات غير المستخدمة إذا لم تكن هناك حاجة عملية إليها.
- تجنب فتح روابط غير موثوقة أثناء تسجيل الدخول بحساب Administrator.
لماذا الخبر مهم رغم صدور الإصلاح بالفعل؟
عند صدور WordPress 7.1.1 كانت المعلومة الرسمية مختصرة للغاية: رابط مصمم خصيصًا يمكنه تثبيت قالب غير نشط ومعاينته. نشر التفاصيل البحثية أوضح أن الأمر ليس مجرد سلوك مزعج في صفحة القوالب، بل يمكن أن يصبح جزءًا من سلسلة أخطر عند دمجه مع كود ضعيف داخل قالب.
ولهذا فإن ثغرة Click2Shell تمثل مثالًا مهمًا على خطورة الجمع بين ثغرتين كل منهما محدودة بمفردها. الأولى تمنح المهاجم وسيلة لإدخال قالب رسمي إلى الموقع، والثانية تمنحه مسارًا لاستغلال كود ذلك القالب أثناء المعاينة.
خلاصة ثغرة Click2Shell
تم إغلاق ثغرة Click2Shell بالفعل في WordPress 7.1.1، وبالتالي لا يوجد سبب لتأجيل التحديث على المواقع التي ما زالت تعمل بإصدار متأثر. الخلل الأساسي يسمح بتثبيت قالب رسمي غير نشط عندما يفتح مسؤول مسجل الدخول رابطًا مصممًا خصيصًا، بينما يحتاج الوصول إلى تنفيذ كود على الخادم إلى ثغرة ثانية مستقلة في القالب الذي تم تثبيته.
يمكن مراجعة إعلان WordPress 7.1.1 الرسمي للتأكد من قائمة الإصلاحات، بينما نشر فريق pwn.ai التحليل الفني الكامل لسلسلة Click2Shell. وحتى الآن لا توجد مؤشرات منشورة على استغلال هذه المشكلة في هجمات فعلية، لكن تحديث ووردبريس يظل الإجراء المطلوب لإغلاقها.
لا يسمح بنقل هذا المحتوى من سوالف دون الاشارة برابط مباشر
