إصدار أمني وليس تحديثاً روتينياً
يحمل إعلان ووردبريس 7.1.4 الرسمي تاريخ 28 أكتوبر 2026 ويقدمه بوصفه إصداراً أمنياً: يوصي بالتحديث فوراً، والمواقع المفعّل فيها التحديث التلقائي في الخلفية تتحدث من تلقاء نفسها. بحسب Patchstack يحصي ووردبريس 22 ثغرة موزعة على 17 نشرة، مقابل 7 في الإصدار 7.1.3 الذي صدر قبل ثلاثة أسابيع. سبع نشرات من أصل سبع عشرة تخص واجهة Interactivity API، ومعظم البقية ثغرات XSS مخزنة تتطلب حساب مساهم على الأقل. وهناك أيضاً كشف مسودات التخصيص غير المنشورة لزائر مجهول، وضعف في عملية التحديث نفسها. لا الإعلان الرسمي ولا Patchstack يذكران أي استغلال، وهذا المقال لا يزعم أي استغلال.
سباق التحديث الحرج ولماذا لا ننتظر
قبل 7.1.4 كان لمجلد الاستخراج المنشأ تحت wp-content/upgrade/ اسم يمكن توقعه للحزم المرفوعة من لوحة الإدارة، وكان التنظيف يحذف كل محتواه بما فيه الملف index.php الذي يمنع عرض محتوى المجلد. وخلال التحديث كانت نسخة كاملة من ووردبريس تقع إذن على عنوان يمكن تخمينه وتصفحه، بما فيها wp-admin/setup-config.php. لا حاجة إلى حساب ولا إلى تفاعل مستخدم، لكن على المهاجم أن يصيب نافذة من بضع ثوان. تصنف Patchstack الاستغلال بأنه صعب وغير عملي؛ ومع ذلك تعود النافذة عند كل تحديث، حتى التلقائي منها. يضيف الإصلاح 16 حرفاً عشوائياً إلى اسم المجلد، ويعيد إنشاء index.php دون حذفه، ويمنع نسخ wp-config.php خارج مجلد العمل. يبقى اعتراض الوكالة: إذا كان الاستغلال صعباً فلماذا نتحرك الآن؟ لأن تحديث النواة يأتي أولاً وكلفته أمر واحد لكل موقع، ولأن إغلاق المجلد على مستوى الخادم دفاع متعدد الطبقات. جدار حماية التطبيق في PHP لا يستطيع حمله، لأن النسخة المستخرجة تعمل بدون mu-plugins الخاصة بالموقع.
جرد مواقع العملاء ثم تحديث كل موقع
ثماني خطوات بـ WP-CLI من الفحص إلى التحقق
النسخ الاحتياطي أولاً
صدّر قاعدة بيانات كل موقع، ثم انسخ
wp-contentإن لم توجد نسخة ملفات:wp db export pre-update.sqlالعثور على التثبيتات
على خادم يستضيف عدة حسابات، اعرض ملفات
wp-config.php:find /home -name wp-config.php -not -path '*/wp-content/*' 2>/dev/nullقراءة إصدار كل موقع
لموقع واحد، ثم لقائمة مسارات (مسار في كل سطر من
sites.txt):
`wp core version
wp core check-update`while read -r d; do printf '%s ' "$d"; wp --path="$d" core version --skip-plugins --skip-themes; done < sites.txtرصد الفروع بلا إصلاح
قارن كل إصدار بالجدول أدناه: الفرع 4.6 أو الأقدم بلا إصلاح ويخرج من جولة التحديث.
تحديث النواة
للانتقال إلى أحدث إصدار شغّل الأمر الأول؛ وللبقاء على الفرع المثبت وتطبيق إصلاحه فقط شغّل الثاني:
wp core updatewp core update --minorتحديث قاعدة البيانات
طبّق أي ترحيلات للمخطط:
wp core update-dbالتحقق من النتيجة
أعد قراءة الإصدار ثم افحص سلامة ملفات النواة:
`wp core version
wp core verify-checksums`التكرار على المواقع كلها
أعد تحديث الفرع على كل مسار في القائمة:
while read -r d; do wp --path="$d" core update --minor && wp --path="$d" core update-db; done < sites.txt
النسخة المصححة لكل فرع، 28 أكتوبر 2026
مرّر الجدول أفقيًا
| الفرع المثبت | النسخة المصححة | إجراء الوكالة |
|---|---|---|
| 7.1 | 7.1.4 | حدّث؛ يتكفل بها التحديث التلقائي للنواة إن كان مفعلاً |
| 7.0 | 7.0.8 | تحديث ثانوي ثم خطط للانتقال إلى فرع أحدث |
| 6.9 | 6.9.11 | تحديث ثانوي ثم خطط للانتقال إلى فرع أحدث |
| 6.8 | 6.8.12 | تحديث ثانوي ثم خطط للانتقال إلى فرع أحدث |
| 6.7, 6.6, 6.5, 6.4 | 6.7.11, 6.6.11, 6.5.14, 6.4.14 | تحديث ثانوي ثم انتقال ذو أولوية إلى فرع أحدث |
| 6.3 إلى 4.7 | إصلاح لكل فرع حتى 4.7.39 | تحديث ثانوي ثم ترحيل الموقع إلى فرع حالي |
| 4.6 وما قبله | لا يوجد إصلاح | لا ترقّع: رحّل الموقع |
قاعدة الوكالة تختصر في جملة: الموقع الواقع على فرع بلا إصلاح يُرحَّل ولا يُرقَّع. يذكر الإعلان الرسمي أن الإصلاحات تُنقل إلى كل الفروع المؤهلة، حالياً حتى 4.7، وأنها تُنشر تدريجياً؛ فتأكد من wordpress.org من الرقم المتاح لكل فرع قبل أن تعد العميل بموعد. أما المسؤولية، فأنت من يتصل به العميل إذا تعطل موقع: دوّن لكل موقع الإصدار قبل العملية وبعدها ووقت التنفيذ، وأبقِ هذا السجل في متناول العميل. لجرد إصدارات PHP لنفس المواقع راجع المقال المخصص، ولثغرة سابقة في النواة راجع مقال الإصدار 7.1.2.
إغلاق wp-content/upgrade/ على مستوى الخادم
المصدر يقرر أمراً واحداً فقط: منع الوصول عبر الويب إلى wp-content/upgrade/ والتأكد من أن المجلد لا يمكن عرض محتواه؛ وبين تحديثين لا ينبغي أن يحتوي إلا على index.php. القواعد التالية إذن تحصين عام نقترحه نحن وليست توجيهاً من النشرة. يمر التحديث عبر نظام ملفات PHP لا عبر طلب HTTP، فلا يعيقه منع الوصول عبر الويب. هذا الحجب لا يغني عن تحديث النواة: إنه يغلق النافذة أثناء العمليات القادمة. ضع القاعدة دائماً على مستوى الموقع أو الخادم، وليس داخل المجلد نفسه الذي تتعامل معه عملية التحديث.
ثمانية إجراءات بحسب البيئة من الحجب إلى الإثبات
nginx: حجب المجلد
أضف إلى كتلة
serverللموقع قبل الكتلة التي تعالج ملفات PHP؛ المعدِّل^~يمنع تقدم تعبير نمطي عليه:
`location ^~ /wp-content/upgrade/ {
return 404;
}`
ثم اختبر وأعد التحميل:nginx -t && systemctl reload nginxnginx: قاعدة واحدة لكل المواقع
ضع القاعدة في ملف مقتطف وضمّنه في كل vhost حتى ينالها الموقع الجديد أيضاً:
include /etc/nginx/snippets/wp-upgrade-deny.conf;Apache: كتلة Directory
في إعداد vhost مع المسار الفعلي للموقع:
`<Directory "/var/www/your-domain.com/wp-content/upgrade">
Require all denied
</Directory>`
ثم تحقق وأعد التحميل:apachectl configtest && systemctl reload apache2استضافة مشتركة أو cPanel: ملف .htaccess
بدون وصول إلى إعداد الخادم، أضف في جذر الموقع داخل ملف
.htaccessالقائم إعادة توجيه إلى خطأ 404:RedirectMatch 404 ^/wp-content/upgrade(/|$)Docker: أين تُوضع القاعدة
تُوضع القاعدة في الحاوية التي تقدم HTTP: الوكيل العكسي nginx أو إعداد Apache في الصورة. اربطها كحجم (volume) لتبقى بعد إعادة البناء، ثم أعد تحميل الحاوية.
إثبات أن الرد 403 أو 404
اختبر المجلد وملف
index.phpمن الخارج؛ يجب أن يعيد كل سطر 403 أو 404 لا 200:
`curl -I https://your-domain.com/wp-content/upgrade/
curl -I https://your-domain.com/wp-content/upgrade/index.php`تغطية كل vhost
اعرض المواقع التي تفتقد القاعدة؛ يجب أن تكون القائمة فارغة بعد كل نشر:
grep -L -E 'wp-content/upgrade|wp-upgrade-deny' /etc/nginx/sites-enabled/*فحص محتوى المجلد
خارج أي تحديث جارٍ، يجب ألا يظهر إلا
index.php:ls -A /var/www/your-domain.com/wp-content/upgrade
المؤلفون الخارجيون: ما الذي تغيره ثغرات XSS لدور المساهم
خمسة فحوص على حسابات موقع العميل
- اعرض الحسابات — حدد أدوار المساهم وما فوقها:
wp user list --role=contributor --fields=ID,user_login,user_registered - أزل غير المستعمل — احذف أو خفّض حسابات المتعاقدين السابقين والكتّاب الذين غادروا.
- لا تفتح حسابات للراحة — الثغرة المخزنة تحتاج حساباً يكتب؛ حسابات أقل تعني سطح هجوم أصغر.
- نبّه المدراء — تنطلق عدة ثغرات حين يفتح مدير محتوى ملغوماً أو شاشة التخصيص.
- حدّث قبل المراجعة — طبّق 7.1.4 قبل إعادة فتح مسودات المساهمين الخارجيين.
الإصدار الأمني اختبار للمنهج قبل كل شيء. إن استغرق الجرد والتحديث وقاعدة الخادم صباحاً على عشرة مواقع، فسيستغرقان ثلاثة أيام على مئة. تجمع مساحة الوكالة حسابات cPanel والاستضافات وتواريخ الانتهاء في مكان واحد، لتبدأ الجولة من قائمة محدّثة لا من بحث.
