CVE-2026-119977 في WordPress: ثغرة في عملية التحديث تتيح تشغيل شيفرة على الخادم

في 28 تشرين الأول 2026 أصدر WordPress النسخة 7.1.4، وفيها إصلاح لخلل في طريقة تحديث WordPress لنفسه: أثناء تحديث النواة بالحزمة الكاملة، يفك WordPress الملفات الجديدة في مجلد اسمه متوقَّع ويصل إليه أي زائر من الويب، فيستطيع مهاجم دون أي حساب على الموقع أن يشغّل شيفرة على الخادم. وبعد ساعات من صدور الإصلاح بدأ المهاجمون يحاولون استغلاله، وفي 3 تشرين الثاني أضافت وكالة CISA الثغرة CVE-2026-119977 إلى قائمة الثغرات المستغلة، أي أن لديها دليلاً على استغلالها في هجمات حقيقية. والخلل يطال كل نسخ WordPress من 4.7 حتى 7.1.3، ما لم يكن الموقع يعمل بالنسخة المرقّعة لفرعه. في هذا المقال: كيف تعمل الثغرة، وكيف تعرف إن كان موقعك متأثراً، وكيف تحميه قبل أن تحدّثه، وكيف تحدّثه، وكيف تبحث عن أثر اختراق.

01ما الذي حدث

أبلغ الباحث Umut Bayram من شركة Picus Security فريق WordPress عن الخلل، فأصلحه الفريق في 7.1.4 مع 21 ثغرة أخرى أغلبها من نوع XSS، ونشر نسخاً مرقّعة لكل فرع أقدم حتى 4.7. ونشرت Wordfence قاعدة في جدار حمايتها تصد الهجوم بعد نحو ثلاث ساعات من الإعلان، فوصلها أول طلب يطابقها بعد تسع دقائق، وسجّلت في أول 21 ساعة أكثر من 18,500 طلب يبحث عن المثبّت في مجلد التحديث المؤقت.

وصنّف WordPress الخلل منخفض الخطورة، لأن استغلاله يحتاج توقيتاً دقيقاً. أما Wordfence، التي أعطته رقمه في 31 تشرين الأول، فقيّمته 8.1 من 10، أي عالي الخطورة: الاستغلال صعب، لكن من ينجح فيه يشغّل ما يشاء على الخادم. ثم أضافته CISA إلى قائمتها في 3 تشرين الثاني، وأمهلت الجهات الحكومية الأمريكية حتى 6 تشرين الثاني لتسدّه.

02كيف تعمل الثغرة

حين يحدّث WordPress نواته، ينزّل حزمة النسخة الجديدة ويفكها في مجلد مؤقت داخل wp-content/upgrade، ثم ينقل الملفات إلى أماكنها ويحذف المجلد. والعملية كلها تستغرق ثوانيَ. وقبل 7.1.4 كان اسم المجلد المؤقت مأخوذاً من اسم الحزمة، فيعرفه المهاجم مسبقاً، وكان المجلد يُخدَم من الويب على كثير من الخوادم كأي مجلد آخر في الموقع. بل إن خطوة التنظيف التي تسبق التحديث كانت تحذف ملف index.php الذي يخفي محتوى المجلد عن الزوار.

والحزمة الكاملة نسخة كاملة من WordPress، فيها المثبّت، أي الصفحة التي تكتب ملف الإعداد عند تثبيت موقع جديد، وهي تعمل دون إعداد الموقع لأنها صُممت لموقع لم يُثبَّت بعد. فإن طلبها المهاجم في اللحظة التي ظهر فيها المجلد، وجّهها إلى قاعدة بيانات يملكها، فكتبت في النسخة المؤقتة ملف wp-config.php جديداً يشير إليها. ثم كان التحديث نفسه ينسخ هذا الملف فوق ملف الموقع الحقيقي، فيصير الموقع يقرأ من قاعدة بيانات المهاجم، وفيها حساب مدير أعدّه لنفسه، فيدخل به ويشغّل ما يشاء من شيفرة عبر محرر القوالب أو برفع إضافة.

لهذا تُسمى هذه الثغرة سباق التوقيت: فالمجلد المؤقت لا يوجد على الخادم إلا ثوانيَ أثناء التحديث، ولا ينجح المهاجم إلا إن وصل إليه في تلك الثواني. ولأنه لا يعرف متى سيبدأ موقعك التحديث، يطلب المسار نفسه مرة بعد مرة لساعات، حتى يصادف اللحظة التي يظهر فيها المجلد.

ويسدّ الإصلاح الطريق من ثلاث جهات: يضيف إلى اسم المجلد المؤقت 16 حرفاً عشوائياً فلا يُتوقَّع، ويُبقي ملف index.php في مجلد upgrade، ويمنع التحديث من نسخ ملف wp-config.php من النسخة المؤقتة.

03هل موقعك متأثر

كل موقع يعمل بـ WordPress من 4.7 حتى 7.1.3 متأثر، ما لم يكن يعمل بالنسخة المرقّعة لفرعه. وينجح الهجوم إن اجتمعت أربعة شروط:

1. 01تحديث للنواة بالحزمة الكاملة: الحزمة الكاملة وحدها تحمل ملفات المثبّت، ولا تحمله تحديثات الإضافات والقوالب.
2. 02مجلد wp-content/upgrade يُخدَم من الويب: تعمل فيه ملفات PHP، وهذا هو الوضع الافتراضي على أغلب الخوادم.
3. 03اسم مجلد يمكن توقعه: كما في كل النسخ قبل 7.1.4.
4. 04وقت يكفي: ليصل طلب المهاجم قبل أن يحذف WordPress الملفات المؤقتة.

ولا يختار صاحب الموقع عادة أي حزمة يستخدمها التحديث، فاعتبر كل تحديث للنواة على نسخة متأثرة نافذة مفتوحة، ومنها التحديث الذي يجلب الإصلاح نفسه: فالموقع المتأثر يفك حزمة النسخة المرقّعة بشيفرة التحديث القديمة، مرة أخيرة.

اعرف نسختك

تجد رقم نسختك في لوحة تحكم WordPress، في صفحة Updates، أو بالأمر wp core version إن كان لديك WP-CLI. ثم قارنه بالنسخة المرقّعة لفرعك:

والنسخة 7.1.4 وحدها مدعومة اليوم، أما نسخ الفروع الأقدم فيصدرها WordPress مجاملةً. ولا تصل أي إصلاحات أمنية إلى 4.6 وما قبلها، ويقول Patchstack إن موضع الخلل في شيفرة التحديث يعود إلى WordPress 2.8، فلا تفترض أن هذه النسخ سليمة.

04أغلق مجلد upgrade قبل أن تحدّث

لا يحتاج أحد أن يصل إلى مجلد wp-content/upgrade من الويب، فـ WordPress يقرأ هذا المجلد ويكتب فيه من القرص مباشرة، وحجبه لا يعطّل أي تحديث. فاحجبه قبل أن تحدّث، فتُغلق النافذة حتى في التحديث الأخير بالشيفرة القديمة. وضع القاعدة في إعداد الموقع لا داخل مجلد upgrade نفسه، لأن خطوة التنظيف في النسخ المتأثرة تحذف ما فيه.

على Apache أو LiteSpeed

أضف هذه الأسطر في أول ملف .htaccess في المجلد الرئيسي للموقع، قبل سطر # BEGIN WordPress، فـ WordPress يعيد كتابة ما بين علامتيه:

# يحجب كل طلب من الويب إلى مجلد upgrade، ويرد عليه بـ 403<IfModule mod_rewrite.c>RewriteEngine OnRewriteRule ^wp-content/upgrade/ - [F,L]</IfModule>

على nginx

أضف هذه الكتلة داخل كتلة server الخاصة بموقعك، ثم افحص الإعداد وأعد تحميله:

location ^~ /wp-content/upgrade/ {    deny all;}# ثم: nginx -t && systemctl reload nginx

وتأكد أن الحجب يعمل: يجب أن يطبع الأمران التاليان 403.

curl -sI https://idlib-olives.sy/wp-content/upgrade/ | head -1curl -sI https://idlib-olives.sy/wp-content/upgrade/index.php | head -1

05حدّث WordPress وتحقق من النسخة

1. 01خذ نسخة احتياطية: تشمل ملفات الموقع وقاعدة بياناته معاً، واحفظها في مكان آمن.
2. 02احجب مجلد upgrade: كما في القسم السابق، قبل أن تبدأ التحديث.
3. 03حدّث: من لوحة التحكم افتح Updates واضغط Update Now، أو نزّل 7.1.4 من wordpress.org وارفع ملفاتها بنفسك.
4. 04تحقق من النسخة: افتح Updates مرة أخرى، وتأكد أن الرقم صار 7.1.4 أو النسخة المرقّعة لفرعك.

ومن لديه WP-CLI يفعل الشيء نفسه من الطرفية، في مجلد الموقع:

# النسخة الحالية، ثم التحديث إلى أحدث نسخة، ثم التحققwp core versionwp core updatewp core version# مطابقة ملفات النواة مع النسخة الرسميةwp core verify-checksums

الأفضل أن تنتقل إلى 7.1.4، فهي النسخة الوحيدة المدعومة. وإن كان الانتقال إلى فرع أحدث يحتاج وقتاً لتجربة القالب والإضافات، فالأمر wp core update --minor يحدّث موقعك إلى النسخة المرقّعة لفرعه، وهي تسد هذه الثغرة.

والمواقع التي فيها التحديث التلقائي مفعّل تحدّث نفسها، لكن تأكد من رقم النسخة بنفسك ولا تفترض. أما المواقع التي عُطّل فيها التحديث التلقائي، بالإعداد AUTOMATIC_UPDATER_DISABLED أو WP_AUTO_UPDATE_CORE false، أو التي يديرها مطوّر عبر Composer أو أداة نشر، فلن تتحدث وحدها.

المشكلةظهرت رسالة Another update is currently in progress

الحلتحديث سابق لم يكتمل ترك قفلاً، ويزول وحده بعد 15 دقيقة. انتظر ثم أعد المحاولة.

المشكلةلا يظهر زر التحديث في صفحة Updates

الحلالتحديث معطّل في wp-config.php، أو أن جهة أخرى تدير الموقع. اسأل من يديره، أو حدّث يدوياً من wordpress.org.

المشكلةموقعي يعمل بـ 4.6 أو أقدم

الحللا إصلاح لفرعك. خذ نسخة احتياطية، وجرّب الانتقال إلى نسخة مدعومة على نسخة تجريبية من الموقع أولاً، وأبقِ مجلد upgrade محجوباً حتى تنتهي.

المشكلةحدّثت، فهل انتهى الأمر؟

الحلالتحديث يغلق الباب ولا يُخرج من دخل قبله. افحص موقعك كما في القسم التالي.

06هل استُغل موقعك؟

كانت النافذة تُفتح مع كل تحديث للنواة على نسخة متأثرة، ومنها التحديث الذي جلب الإصلاح، والمهاجمون بدأوا يطرقونها بعد ساعات من صدوره. فحتى الموقع الذي حدّث نفسه تلقائياً يستحق فحصاً سريعاً، وأهم ما تبحث عنه ما جرى في الدقائق المحيطة بوقت التحديث:

# 1. طلبات إلى ملفات PHP داخل مجلد upgrade، والمسار مثال لسجلات nginxzgrep -h 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log*# 2. قاعدة البيانات التي يتصل بها الموقع، ووقت آخر تعديل لملف الإعداد ولملف النسخةgrep -E "DB_(HOST|NAME|USER)" wp-config.phpls -l --time-style=full-iso wp-config.php wp-includes/version.php# 3. حسابات المدير، وسلامة ملفات النواةwp user list --role=administratorwp core verify-checksums

• طلب ناجح إلى ملف PHP داخل wp-content/upgrade: لا يطلب زائر عادي هذه الملفات أبداً. وأخطرها طلب POST إلى setup-config.php ردّ عليه الخادم بـ 200.
• ملف wp-config.php يشير إلى قاعدة بيانات لا تعرفها: أو وقت تعديل يوافق وقت التحديث، فتحديثات النواة لا تكتب هذا الملف أبداً.
• مدير لم تنشئه: أو إضافة أو قالب لا تعرفه، أو ملفات PHP جديدة في مجلد uploads أو mu-plugins، أو ملفات نواة لا تطابق النسخة الرسمية.

07إن كنت من عملاء إليفانتي

• استضافة cPanel: خادم الويب في استضافتنا LiteSpeed، وهو يقرأ ملف .htaccess، فتعمل عليه قاعدة الحجب في هذا المقال كما هي. تضيفها من File Manager في cPanel، بعد أن تُظهر الملفات المخفية من إعداداته.
• سجلات الوصول: تجدها في cPanel في قسم Metrics تحت Raw Access، فنزّلها وابحث فيها عن طلبات إلى wp-content/upgrade.
• نسخ JetBackup: تُؤخذ لموقعك نسخة تلقائية كل يوم، وتُحفظ 15 أو 30 أو 45 يوماً بحسب خطتك. خذ نسخة يدوية قبل أن تحدّث، وإن وجدت أثر اختراق فاستعد من JetBackup نسخة من قبل التحديث.
• خادم CoreVPS: إن كان WordPress على خادمك، اخترته تطبيقاً عند الطلب أو ثبّتّه بنفسك، فخادم الويب وإعداده بيدك: أضف قاعدة nginx أو Apache المناسبة، وحدّث WordPress بنفسك.
• إن احتجت يداً: فريق الدعم الفني معك على مدار الساعة إن احتجت مساعدة في حجب المجلد أو في فحص موقعك.

08الدرس: لحظة التحديث نفسها تحتاج حماية

هذه الثغرة لا تعيش إلا ثوانيَ أثناء التحديث، ومع ذلك صارت هدفاً لعشرات آلاف الطلبات. ثلاث عادات تحمي موقعك من أشباهها:

1. 01المجلدات المؤقتة ليست للويب: أبقِ wp-content/upgrade محجوباً دائماً، لا وقت التحديث وحده، فلا شيء فيه يحتاجه زائر.
2. 02تحديث تلقائي ثم تحقق: أبقِ التحديث التلقائي مفعّلاً للإصدارات الأمنية، وتحقق من رقم النسخة بعد كل إصدار أمني.
3. 03سجلات تكفي للعودة: احتفظ بسجلات الوصول أسابيع لا أياماً، فالثغرة تُعلَن غالباً بعد أن يكون بابها قد فُتح، والسجلات وحدها تخبرك من مرّ منه.