إصلاح ثغرة مستغلة في WordPress قد يعرّض بعض المواقع مؤقتاً أثناء التحديث

قد تُهاجم بعض مواقع WordPress أثناء تثبيت إصلاح ثغرة مستغلة بنشاط، وفقاً لـ Umut Bayram، باحث Picus Security الذي اكتشفها. ما زال التحديث الذي يثبت الإصلاح يفك الملفات باستخدام رمز الموقع القديم غير المصحح، لذا يمكن لمهاجم يضرب في اللحظة المناسبة تشغيل رمز على الخادم. تُتتبّع الثغرة بوصفها CVE-2026-119977 وتؤثر على WordPress من 4.7 إلى 7.1.3.

لماذا نافذة التحديث مهمة

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

من هم المعرّضون

ليس كل تحديث يعرّض المثبت. تشمل الحزم الكاملة المثبت دائماً؛ أما الحزمة الجزئية فتعرّض الموقع فقط إذا كانت تحتوي ملفات المثبت. تستخدم التحديثات التلقائية نفس أداة التحديث. فحصت The Hacker News خدمة التحديث في WordPress.org: فقد قدّمت حزمة جزئية داخل فرع، مثل 7.1.3 إلى 7.1.4، وفقط حزم كاملة من فرع أقدم، مثل 7.0.7 إلى 7.1.4. في 4.4 إلى 5.8، يضيف الرمز القديم أحرفًا عشوائية تُخفي اسم المجلد ما لم يُسَرَّب. بعد تثبيت 7.1.4 أو إصلاح الفرع، تستخدم التحديثات اللاحقة اسماً عشوائياً، ولا يُنسخ ملف wp-config.php من النسخة المؤقتة فوق الملف الحقيقي بعد الآن. قال Bayram إن التعرّض الجزئي يعتمد على ما تحتويه الحزمة المحددة، وأن الموقع يعود إلى حزمة كاملة إذا لم تتطابق قيم التحقق أو أثناء إعادة التثبيت. العامل الحاسم هو ما إذا كانت أداة التحديث المثبتة مصححة بالفعل.

ماذا يجب على المدراء فعله

يوصي Bayram بحظر الوصول عبر الويب إلى wp-content/upgrade قبل التحديث. يستخدم WordPress المجلد مباشرة على القرص، لذا حظر الوصول عبر الويب لا يكسر التحديثات. على Nginx، أضف location ^~ /wp-content/upgrade/ { deny all; }. على Apache، أضف Require all denied في كتلة دليل. في .htaccess، أضف RedirectMatch 403 ^/wp-content/upgrade/ فوق قواعد إعادة الكتابة، لكن لا تضع .htaccess داخل المجلد لأن أداة التحديث القديمة تحذفه. تأكد من أن الطلب يُرجع 403. حدّث إلى 7.1.4 أو الإصدار المصحح للفرع. التحديث اليدوي خارج جذر الويب مسار آمن آخر. WP-CLI wp core update ليس بديلاً. WordPress 4.6 والإصدارات الأقدم لا تلقي تحديثات أمنية، والثغرة تعود إلى 2.7، الذي صدر عام 2008.

الاستغلال والفحوصات

استندت CISA في إضافة الثغرة إلى كتالوجها إلى دليل على استغلال نشط، لكنها لم تصف الهجمات. رأت Wordfence، شركة أمن WordPress التي أسندت معرّف CVE، محاولات تبدأ بعد تسع دقائق من نشر قاعدة جدار ناري في يوم الإصدار؛ وفحص أكبر مصدرين مجموعات صغيرة من المواقع لنحو 14.5 ساعة، وهو ما تقول الشركة إنه يتوافق مع محاولات الإمساك بلحظة تحديث الموقع. درجة السجل في CVE هي 8.1 من 10 على مقياس CVSS، بينما تُقيِّم WordPress الثغرة منخفضة. ظهر كود في مستودعات GitHub العامة يصفه مؤلفوه بأنه استغلال، ويقول أحدها إنه يعمل أيضاً على المواقع التي ما زالت تستخدم مجلداً قابلاً للتوقع أثناء التحديث بالحزمة الكاملة؛ ولم يُثبت أنه يعمل. تحقق من طلبات PHP غير المتوقعة تحت wp-content/upgrade، وحسابات مسؤولين لا يعرفها أحد، وإضافات لم يثبتها أحد، وملفات PHP هناك لم يضعها أحد.

المصادر: The Hacker News