أصدرت WordPress الإصدار 7.1.4 في 28 أكتوبر 2026، متضمنًا إصلاحات لـ 22 مشكلة أمنية. إحداها غير معتادة: فهي لا توجد في إضافة أو قالب، بل في أداة التحديث الخاصة بـ WordPress نفسها، ويمكن استغلالها دون امتلاك حساب على موقعك.
تحرّك المهاجمون بسرعة. فقد نشرت Wordfence قاعدة جدار حماية مساء يوم صدور الإصدار، ورصدت أول محاولة هجوم بعد تسع دقائق فقط. وعلى مدار الأيام التالية، كانت تصدّ عشرات الآلاف من المحاولات كل 24 ساعة. يشرح هذا الدليل ماهية الثغرة، والإصدارات التي تعالجها، وكيفية التحديث دون ترك الباب مفتوحًا أثناء ذلك.
أهم النقاط
- يعالج WordPress 7.1.4 (الصادر في 28 أكتوبر 2026) عدد 22 مشكلة أمنية. يجب أن يعمل كل موقع عليه، أو على الإصدار المُصلح من فرعه.
- تتيح الثغرة الأبرز، CVE-2026-119977، لمهاجم لا يملك حسابًا تشغيل تعليمات برمجية أثناء تحديث النواة. وتصنّفها Wordfence بدرجة 8.1 (عالية الخطورة).
- بدأ المهاجمون عمليات الفحص خلال تسع دقائق من نشر أول قاعدة جدار حماية، مع عشرات الآلاف من المحاولات يوميًا منذ ذلك الحين.
- امنع الوصول عبر الويب إلى wp-content/upgrade/ قبل التحديث، ثم حدِّث وتحقق من وجود أي علامات على الاختراق.
- لا يحصل WordPress 4.6 والإصدارات الأقدم على أي إصلاح على الإطلاق، وتحتاج هذه المواقع إلى ترقية كاملة.
باختصار أضف القاعدة المكونة من سطر واحد أدناه لحظر الوصول عبر الويب إلى wp-content/upgrade/، ثم حدِّث إلى 7.1.4 (أو الإصدار المُصلح من فرعك)، ثم تحقق من عدم وجود مستخدمين مسؤولين غير معروفين. إذا كان موقعك يعمل على WordPress 4.6 أو إصدار أقدم، فلا يوجد إصلاح: إذ يحتاج إلى ترقية كاملة.
ما هي ثغرة أداة التحديث
تحمل الثغرة المعرّف CVE-2026-119977. وتصنّفها Wordfence بدرجة 8.1 من 10 (عالية الخطورة). أما WordPress نفسها فتمنحها تصنيفًا أقل لصعوبة تنفيذها، لكن "الصعوبة" لا تعني "الأمان" حين تستطيع الروبوتات المحاولة آلاف المرات يوميًا.
عندما يثبّت WordPress تحديثًا كاملًا للنواة، فإنه يفك الملفات الجديدة أولًا في مجلد داخل wp-content/upgrade/. وفي الإصدارات المتأثرة، كان لهذا المجلد اسم يمكن توقعه، وكان من الممكن الوصول إليه عبر الويب على كثير من الخوادم. ولبضع ثوانٍ، كان بإمكان أي شخص فتح نسخة مثبّت WordPress الموجودة بداخله وتوجيهها إلى قاعدة بيانات يتحكم فيها المهاجم، ما يتيح له تشغيل تعليمات برمجية على خادمك.
يجب أن تجتمع أربعة شروط: أن يكون تحديث بالحزمة الكاملة قيد التشغيل، وأن يكون المجلد قابلًا للوصول عبر الويب، وأن يعثر المهاجم على مساره، وأن يسبق WordPress قبل أن ينتهي من التنظيف. وتتولى الروبوتات الشروط الثلاثة الأخيرة عبر استطلاع المواقع مرارًا وتكرارًا، ولهذا تبدو أعداد المحاولات مرتفعة إلى هذا الحد.
يسدّ الإصدار 7.1.4 هذه الثغرة بإضافة 16 حرفًا عشوائيًا إلى اسم مجلد التجهيز، والإبقاء على ملف حماية index.php في مجلد الترقية، ورفض نسخ الإعدادات من نسخة التجهيز. أما الإصلاحات الـ 21 الأخرى فتشمل ثغرات البرمجة النصية عبر المواقع (XSS)، ومشكلات في Interactivity API، وكشف معلومات لزوار غير مسجلين الدخول، والتحقق من الصلاحيات، إضافة إلى تحديث شهادات الجذر المضمّنة.
الإصدارات التي تتضمن الإصلاح
نُقل الإصلاح إلى كل فرع لا يزال يتلقى إصدارات أمنية. حدِّث على الأقل إلى:
- 7.1.4 على الفرع 7.1، أو 7.0.8 على الفرع 7.0؛
- 6.9.11 أو 6.8.12 أو 6.7.11 أو 6.6.11 أو 6.5.14 أو 6.4.14 على فروع 6.x؛
- الإصدار المُصلح المقابل على فروع 6.x و5.x الأقدم وفروع 4.7–4.9، نزولًا حتى 4.7.39.
لا يحصل WordPress 4.6 والإصدارات الأقدم على أي إصلاح. كما أن الإصلاحات المنقولة إلى الفروع القديمة تقتصر على المشكلات الأمنية فقط، لذا فإن الخيار الأفضل لأي موقع هو أحدث إصدار، أي 7.1.4.
الخطوة 1: احظر مجلد الترقية أولًا
اللحظة الحرجة هي لحظة التحديث نفسها، لذا أغلق هذه الثغرة قبل أن تبدأ التحديث. أضف هذه القاعدة إلى ملف .htaccess في المجلد الجذر لموقعك (في cPanel: File Manager › public_html، مع إظهار الملفات المخفية)، فوق كتلة # BEGIN WordPress:
# Block web access to WordPress update staging files (CVE-2026-119977)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>ضعها في ملف .htaccess الموجود في المجلد الجذر، وليس داخل مجلد الترقية: إذ يُفرغ WordPress هذا المجلد قبل كل تحديث. ولا تؤثر القاعدة على التحديثات، لأن WordPress يقرأ هذه الملفات على الخادم وليس عبر الويب. وهي تعمل على خوادم LiteSpeed لدى WebGee، وعلى أي خادم متوافق مع Apache.
الخطوة 2: التحديث
أنشئ نسخة احتياطية جديدة أولًا. على استضافة cPanel من WebGee، يمكن لأداة JetBackup إنشاء نسخة عند الطلب ببضع نقرات. ثم حدِّث من لوحة التحكم › التحديثات › التحديث إلى الإصدار 7.1.4، أو عبر SSH:
# Check the current version
wp core version
# Update core, then the database if asked
wp core update
wp core update-db
# Confirm
wp core versionمن المفترض أن تكون المواقع التي تفعّل التحديثات التلقائية في الخلفية قد انتقلت بالفعل إلى 7.1.4، لكن تحقق من ذلك على أي حال. فالتحديثات التلقائية تفشل بصمت أكثر مما يظن الكثيرون، كما يحدث مثلًا بعد تغيير في أذونات الملفات أو امتلاء القرص.
الخطوة 3: تحقق من عدم حدوث اختراق
لم تُسجَّل أي حالات اختراق مؤكدة حتى وقت كتابة هذا المقال، ولا توجد قوائم منشورة بعناوين IP أو ملفات خاصة بالمهاجمين. لذا ابحث عن السلوكيات المريبة بدلًا من ذلك:
بعد التحديث، تحقق من وجود
- حسابات مسؤولين لا تعرفها (المستخدمون › كل المستخدمين، مع التصفية حسب دور المسؤول)
- إضافات لم تثبّتها، بما فيها إضافات تحمل اسم نطاقك
- ملفات PHP غير متوقعة داخل wp-content/upgrade/ أو wp-content/uploads/
- طلبات إلى setup-config.php أو ملفات PHP أخرى داخل wp-content/upgrade/ في سجلات الوصول
- تغييرات في wp-config.php أو .htaccess في الفترة التي جرت فيها تحديثات النواة
على استضافة cPanel من WebGee، يمكنك أيضًا إجراء فحص للبرمجيات الخبيثة من cPanel، كما يعرض تقرير CMS Threats في cPGuard كل عمليات تثبيت WordPress في الحساب مع إصدار النواة لكل منها، فتظهر بوضوح أي نسخة منسية لا تزال تعمل على إصدار قديم. وإذا عثرت على شيء مريب، فاتبع خطوات تنظيف البرمجيات الخبيثة أو افتح تذكرة دعم.
لا تنسَ النسخ الأخرى عمليات التثبيت القديمة في مجلدات مثل /old أو /test أو /staging تتعرض للهجمات نفسها التي يتعرض لها موقعك الرئيسي، وغالبًا ما تكون هي النسخ التي لا يحدّثها أحد. حدّثها أو احذفها.
أربعة إصدارات أمنية منذ سبتمبر
يأتي الإصدار 7.1.4 بعد 7.1.1 و7.1.2 و7.1.3 في أقل من ستة أسابيع، ومن المقرر صدور WordPress 7.2 في 8 ديسمبر. ومجرد مواكبة ذلك وحده يمثل عبئًا حقيقيًا. مع استضافة WordPress من WebGee تحصل على نسخ احتياطية، وفحص أمني على مستوى الخادم، وبيئة تجريبية (Staging) بدءًا من خطة Turbo، ومهندسين متاحين عبر الدردشة المباشرة على مدار الساعة طوال أيام الأسبوع يتعاملون مع تحديثات WordPress يوميًا.
الأسئلة الشائعة
ما الإصدارات التي تعالج CVE-2026-119977؟
WordPress 7.1.4، إضافة إلى إصدارات مُصلحة للفروع الأقدم، منها 7.0.8 و6.9.11 و6.8.12 وصولًا إلى 4.7.39. أما WordPress 4.6 والإصدارات الأقدم فلا تحصل على أي إصلاح.
موقعي يُحدَّث تلقائيًا. هل عليّ فعل أي شيء؟
تحقق من أن التحديث قد تم فعلًا: يجب أن تعرض صفحة لوحة التحكم › التحديثات أو الأمر wp core version الإصدار 7.1.4 أو الإصدار المُصلح من فرعك. فالتحديثات التلقائية قد تفشل دون أي تنبيه، كما يحدث مثلًا عند وجود مشكلات في أذونات الملفات.
هل يمكن استغلال الثغرة عندما لا يكون هناك تحديث قيد التشغيل؟
لا. فالثغرة لا توجد إلا خلال الثواني القليلة التي يفك فيها تحديث النواة الكامل الملفات داخل wp-content/upgrade/. ولهذا فإن حظر الوصول إلى هذا المجلد قبل التحديث يسدّها.
هل تعرّض أحد للاختراق عبرها؟
حتى وقت كتابة هذا المقال، لم تُسجَّل أي حالات اختراق مؤكدة، بل أعداد كبيرة من المحاولات التي تم صدّها. لكن الوضع قد يتغير بسرعة، فلا تنتظر.
هل سيؤدي حظر wp-content/upgrade/ إلى تعطيل التحديثات؟
لا. يقرأ WordPress هذا المجلد ويكتب فيه على الخادم نفسه؛ والقاعدة تمنع فقط المتصفحات والروبوتات من طلب الملفات الموجودة فيه.
