ووردبريس 7.1 هو الإصدار المستقرّ الحالي، وخدمة التحقّق من الإصدارات التي يتصل بها كل موقع ووردبريس بصمت ما زالت ترسل تحديثات أمنية تلقائية لفروع تعود إلى 4.7. وهاتان الحقيقتان معاً تفسّران كثيراً من الالتباس الذي نسمعه من العملاء: «لوحتي تقول إن كل شيء محدَّث» و«موقعي يعمل على ووردبريس 5.9» يمكن أن تكونا صحيحتين في اللحظة نفسها، ولا واحدة منهما تعني أن الموقع آمن. في هذا الدليل: ما الذي يتطلّبه ووردبريس 7.1 فعلاً، وماذا يمنحك «الدعم المستمرّ» حقيقةً، وما العمل الأمني الذي لن يقوم به عنك أي رقم إصدار.
الخلاصة السريعة
ووردبريس 7.1 هو الإصدار الحالي، ويتطلّب PHP 7.4 أو أحدث وMySQL 5.5.5 أو أحدث. وما زال ووردبريس يوصل إصلاحات أمنية تلقائية إلى أكثر من عشرين فرعاً أقدم — 7.0.4 و6.9.7 و6.8.8 و6.7.7 و6.6.7 و6.5.10 ورجوعاً حتى 4.7 — فالتثبيت القديم يستمرّ في تلقّي ترقيعات النواة. لكن النواة ليست المكان الذي تُخترق منه المواقع. في عمليات التنظيف التي نجريها، تكون نقطة الدخول في الغالب الأعمّ إضافة أو قالباً، أو حساب مدير لا يراجعه أحد، أو نسخة PHP توقّفت إصلاحاتها الأمنية قبل سنوات. حدِّث النواة، ثم عالج هذه الثلاثة.
ما الذي يتطلّبه ووردبريس 7.1
المتطلّبات المعلنة للإصدار 7.1 هي PHP 7.4 أو أحدث وMySQL 5.5.5 أو أحدث (أو MariaDB 10.1 فأحدث). وهذا هو الحدّ الأدنى لتشغيل البرنامج — لا توصية به.
أما التوصية فأعلى بكثير، وهنا تكمن الفجوة المهمّة: PHP 7.4 نفسه انتهى دعمه الأمني في نوفمبر 2022. فقد يستوفي موقعٌ الحدّ الأدنى لووردبريس 7.1 وهو يعمل في الوقت نفسه على نسخة PHP لم تتلقَّ إصلاحاً أمنياً منذ سنوات. وكل إضافة على ذلك الموقع تعمل على المفسّر غير المرقّع ذاته.
إن أخذت شيئاً واحداً من هذا المقال فليكن هذا: افحص نسخة PHP قبل أن تفحص نسخة ووردبريس. تجدها في cPanel تحت «Select PHP Version»، وفي لوحة ووردبريس تحت أدوات ← صحة الموقع ← معلومات ← الخادم. وأي نسخة دون PHP 8.1 ينبغي جدولة ترقيتها الآن، وأي نسخة دون 8.0 تُعامَل على أنها عاجلة.
«ما زال مدعوماً» لا تعني «ما زال آمناً»
يحافظ ووردبريس على ذيل دعم أمني طويل بصورة غير معتادة: موقع مثبَّت على 6.1 ما زال يتلقّى إصلاحات مُرحَّلة باسم 6.1.12، وموقع على 5.9 يتلقّاها باسم 5.9.16. وهذه خدمة عامة حقيقية، وهي سبب بقاء مواقع ووردبريس القديمة جداً واقفةً على أقدامها.
وهي أيضاً تُقرأ خطأً على نطاق واسع. فما يمنحه هذا الترحيل هو إصلاحات أمنية للنواة لثغرات معروفة في ذلك الفرع. وما لا يمنحه:
التحصينات الأمنية الجديدة. التحسينات في طريقة تعامل ووردبريس مع كلمات مرور التطبيقات، ومصادقة REST، والتحقّق من الملفات المرفوعة، وأدوار المستخدمين — كلها تصل في الإصدارات الجديدة ولا تُرحَّل إلى القديمة. فالفرع القديم يحتفظ بمستوى الأمان الخاص بالسنة التي صدر فيها.
توافق الإضافات. يختبر مطوّرو الإضافات برامجهم على ووردبريس الحالي. وكلّما تخلّفت نواتك، بلغتَ نقطة لا تستطيع فيها تحديث إضافة مصابة بثغرة قبل تحديث النواة — وتكون النواة عندها قفزة كبيرة محفوفة بالمخاطر بدل أن تكون تحديثاً روتينياً.
أي شيء خارج النواة. وهو — كما يوضّح القسم التالي — موضع المشكلة الفعلية.
في تثبيتات ووردبريس التي نديرها للعملاء، نجد بانتظام مواقع على 5.9 و6.1 و6.3 يعتقد أصحابها أنهم محميّون لأن «ووردبريس يحدّث نفسه». والنواة فعلاً رُقِّعت. أما إضافة النماذج التي يعود آخر تحديث لها إلى 2019 والجالسة بجوارها فلا.
من أين تُخترق المواقع فعلاً
١. الإضافات والقوالب، لا النواة
نواة ووردبريس من أكثر الشِّفرات تدقيقاً على الويب، ولها فريق أمني مخصّص وعملية إفصاح منسَّق. أما منظومة الإضافات والقوالب فعشرات الآلاف من المشاريع المستقلّة المتفاوتة الجودة تفاوتاً هائلاً، ومنها تبدأ الغالبية الساحقة من اختراقات ووردبريس الواقعية.
والأنماط التي يجدر معرفتها تحديداً:
الإضافات المهجورة. إضافة آخر تحديث لها قبل ثلاث سنوات ليست «مستقرّة»، بل غير مصانة. وحين تُكتشف فيها ثغرة، لن يأتي إصلاح.
الإضافات المعطَّلة ما زالت على القرص. هذه النقطة تكلّف الناس مواقعهم. تعطيل الإضافة يمنع ووردبريس من تحميلها — ولا يحذف ملفاتها، والملف المصاب بثغرة الذي يمكن بلوغه مباشرةً برابط يبقى قابلاً للاستغلال سواء كانت الإضافة مفعَّلة أم لا. فإن كنت لا تستعملها، احذفها ولا تعطّلها.
القوالب المقرصنة والمكسورة الحماية. القوالب التجارية المتاحة مجاناً عبر قنوات غير رسمية هي أضمن طريقة لتثبيت باب خلفي عن قصد. «التوفير» بضع مئات من الدراهم، وتكلفة التنظيف أضعافها.
الإضافات المدفوعة المضمَّنة داخل القالب. كثير من القوالب التجارية يشحن نسخة مرخّصة من عارض شرائح أو منشئ صفحات. وهذه النسخ المضمَّنة لا تُحدَّث إلا بتحديث القالب، ما يعني أنها كثيراً ما تتخلّف شهوراً عن النسخة المستقلّة — بما في ذلك عن إصداراتها الأمنية.
٢. حسابات المديرين التي لا يراجعها أحد
كل موقع ووردبريس يراكم حسابات مديرين: المطوّر الذي بناه، والوكالة التي أعادت تصميمه، ومتعاقد التسويق، وحساب خدمة أنشأته إحدى الإضافات. ونادراً ما تُزال هذه الحسابات عند انتهاء العلاقة.
افتح المستخدمون ← كل المستخدمين وفلتِر حسب «مدير». واسأل عن كل حساب: هل أعرف من هذا؟ وهل ما زال يعمل معنا؟ وهل يحتاج صلاحية مدير بدل محرِّر؟ وما يسقط في الأسئلة الثلاثة يُحذف. أما حساب لا تستطيع التعرّف عليه فيُعامَل بوصفه اكتشافاً أمنياً لا فضولاً.
٣. التثبيت الذي لا يتذكّره أحد
مواقع الاختبار، والنسخ التجريبية، ونسخة قديمة متروكة على نطاق فرعي، وووردبريس تحت /blog/ استُبدل قبل سنوات. هذه غير مراقَبة وغير مرقَّعة، وتجلس على حساب الاستضافة نفسه الذي يحمل الموقع المهمّ. والمهاجم الذي يبلغ الملفات عبر المنسيّ منها يكون قد صار داخل الحساب الذي يحوي الموقع الحقيقي.
اجرد ما يعمل فعلاً تحت نطاقك، واحذف ما لا تحتاجه.
٤. PHP التي عاشت بعد انتهاء دعمها
ذُكرت أعلاه وتستحقّ التكرار، لأنها البند الوحيد في هذه القائمة الذي لا يُرى من داخل ووردبريس ما لم تبحث عنه قصداً.
روتين تحديث يُلتزَم به فعلاً
أفضل روتين أمني هو الذي ينجو من شهر مزدحم. وهذا واحد منها.
أتمِت ما يجب أن يكون تلقائياً
يطبّق ووردبريس الإصدارات الثانوية والأمنية تلقائياً افتراضياً — أبقِ ذلك مفعَّلاً. ثم فعِّل التحديث التلقائي للإضافات واحدةً واحدة (الإضافات ← رابط «تفعيل التحديثات التلقائية» في كل صفّ)، بدءاً بما هو واسع الانتشار ومنخفض المخاطر عند التحديث: إضافات الأمن، وإضافات السيو، والأدوات البسيطة.
واختبر ما يجب اختباره
لا تفعّل التحديث التلقائي للإضافتين أو الثلاث التي قد يكسر تحديثُها الموقع بصورة ظاهرة — عادةً منشئ الصفحات، وإضافة المتجر، والقالب. حدِّث هذه عن قصد على نسخة تجريبية، ثم انظر إلى الموقع بعدها.
إن كانت استضافتك توفّر نسخة تجريبية بنقرة واحدة، فهذا يستغرق عشر دقائق. وإن كانت لا توفّرها، فذلك سبب لتغيير الاستضافة لا سبب لتخطّي الخطوة.
واحتفظ بنسخة احتياطية جرّبت استعادتها فعلاً
النسخة الاحتياطية غير المختبَرة اعتقاد لا خطّة. استعِد نسخةً مرة واحدة على الأقل إلى موقع تجريبي وتأكّد أنك تستعيد موقعاً يعمل. وكل من يفعل ذلك أول مرة تقريباً يكتشف نقصاً ما — قاعدة البيانات دون مجلد الرفع، أو نسخاً توقّفت بصمت قبل أربعة أشهر.
وضع له موعداً
الشهري يكفي لأغلب مواقع الأعمال: افحص التحديثات، وطبّقها، وانظر في قائمة المديرين، وتأكّد من وجود آخر نسخة احتياطية. عشرون دقيقة، اثنتي عشرة مرة في السنة.
تحصينات تبقى بعد أي رقم إصدار
التحديث يغلق الثغرات المعروفة. وهذه الإجراءات تقلّص ما يستطيع المهاجم فعله بثغرة لا يعرفها أحد بعد.
التحقّق بخطوتين على كل حساب مدير. أعلى بنود هذه القائمة قيمةً على الإطلاق، إذ يجعل كلمة المرور المسروقة أو المخمَّنة غير كافية وحدها. وتضيفه عدة إضافات موثوقة في دقائق، ويحفظ الرموزَ أيُّ مدير كلمات مرور محترم.
أزل القدرة على تثبيت شيفرة من اللوحة. على موقع مكتمل لا يحتاج أحد إلى تثبيت إضافات أو تعديل ملفات القالب عبر المتصفح. وإضافة define('DISALLOW_FILE_EDIT', true); إلى wp-config.php تُلغي محرّر الملفات المدمج — وهو أسرع طريق من كلمة مرور مدير مسروقة إلى باب خلفي دائم. والمواقع التي لم تعد تتغيّر يمكنها الذهاب أبعد ومنع تثبيت الإضافات كلياً.
أقلّ صلاحية ممكنة. من يكتب المقالات يحتاج صلاحية كاتب أو محرِّر، لا مدير. لا يكلّف هذا شيئاً ويحدّ من أثر أي حساب يُخترق.
راقب التغيير لا البرمجيات الخبيثة وحدها. الماسحات القائمة على البصمات تجد الملفات الخبيثة المعروفة، ولا تلاحظ ظهور حساب مدير جديد في الثالثة فجراً، ولا ملف PHP جديداً في مجلد الرفع. أما الأداة التي تخبرك بما تغيّر منذ أمس فتلتقط ما لا يلتقطه الماسح أبداً — بما في ذلك الحالة الأكثر تكراراً عندنا، حيث لا يوجد على القرص شيء «خبيث» أصلاً، والمهاجم يسجّل الدخول ببساطة بحساب شرعي أنشأه لنفسه.
ولا تعتمد على بصمات الملفات وحدها. يستطيع ووردبريس التحقّق من أن ملفات النواة تطابق الإصدار الرسمي، وهذا مفيد فعلاً. لكنه يقارن الملفات التي يُفترَض وجودها. ومدير ملفات زرعه مهاجم في مجلد لا تعرفه النواة يعطي نتيجة بصمات نظيفة تماماً وموقعاً مخترقاً تماماً. فالملفات الزائدة لا تقلّ أهمية عن المعدَّلة.
افحص موقعك في عشر دقائق
اعمل بهذه القائمة الآن بدل جدولتها:
١. لوحة التحكم ← التحديثات. سجّل نسخة ووردبريس وعدد تحديثات الإضافات المعلّقة.
٢. أدوات ← صحة الموقع ← معلومات ← الخادم. سجّل نسخة PHP. ودون 8.1 خطّط للترقية.
٣. الإضافات ← الكل. صنّفها ذهنياً إلى ثلاث: مستعمَلة، وغير مستعمَلة، و«ما هذه؟». احذف الثانية، وحقّق في الثالثة.
٤. الإضافات ← افحص تاريخ «آخر تحديث» لكل ما تعتمد عليه. وما تجاوز سنتين موضوع استبدال.
٥. المستخدمون ← كل المستخدمين ← مدير. تأكّد أنك تستطيع تسمية كل واحد منهم.
٦. تأكّد متى عملت آخر نسخة احتياطية وأين تُخزَّن. وإن كانت مخزَّنة على الخادم نفسه فقط فليست نسخة احتياطية.
٧. افحص هل يوجد تثبيت ووردبريس آخر على حساب الاستضافة نفسه.
وكل ما لا تستطيع الإجابة عنه يستحقّ نظرة جادّة.
أين يأتي دورنا
تدير «بيغ بانغ لحلول تقنية المعلومات» استضافة ووردبريس لشركات في أنحاء الإمارات، وجانب الصيانة في هذا العمل هو الجزء الذي يلاحظه العملاء أقلّ ما يكون وينتفعون به أكثر ما يكون: PHP حديثة، وتحديثات تُطبَّق ويُتحقَّق منها، ونسخ احتياطية يومية خارج الخادم نختبرها فعلاً، ومراقبة مبنيّة على كشف التغيير لا على انتظار ماسحٍ يتعرّف على شيء.
إن لم تكن متأكداً من نسخة ووردبريس التي يعمل عليها موقعك، ولا من موعد آخر تحديث له، ولا ممّن يملك صلاحية مدير عليه — فهذه بالضبط الأسئلة التي يستحقّ الإجابة عنها قبل أن يفرضها حادث. تواصل معنا وننظر في الموقع معك.
