لو عندك موقع ووردبريس، وقف اللي في إيدك خمس دقايق. فيه ثغرة في نواة ووردبريس نفسها، مش في إضافة ولا قالب، بتشتغل من غير تسجيل دخول، وممكن توصل لتنفيذ أكواد على السيرفر. الحل موجود، وهو تحديث واحد.
ماذا حدث بالضبط؟
بحسب كاتب المقال المصدر، تحمل الثغرة المعرف CVE-2026-87902 (الإشعار GHSA-7hp8-65ch-5whp في مستودع WordPress develop)، وتقييمها حرج بدرجة 9.2 على مقياس CVSS 4.0.
تؤثر الثغرة على كل الإصدارات من 4.7.0 حتى 7.1.1. وقد أصدر فريق ووردبريس الإصدار 7.1.2 في 22 سبتمبر 2026، مع ترقيعات خلفية لكل الفروع التي ما زالت تتلقى إصلاحات أمنية، نزولًا إلى 4.7.37.
ويذكر المصدر أن الثغرة أُضيفت إلى كتالوج الثغرات المستغلة فعليًا لدى CISA في 25 سبتمبر 2026، وأن محاولات استغلال تُرصد بالفعل. راجع الإشعار الرسمي في مستودع ووردبريس للتأكد من أرقام الإصدارات المرقّعة لفرعك.
كيف تعمل الثغرة؟
نوع الثغرة اجتياز المسارات (Path Traversal)، وهو حقن تسلسلات مثل ../ في الطلب للوصول إلى ملفات خارج المجلد المقصود. لكن المشكلة هنا أدق من مجرد الخروج من مجلد الموقع.
موضع الخلل في طريقة اختيار قالب الصفحة: يمكن لطلب بلا تسجيل دخول توجيه الدالة get_page_template() لتضمين ملف .php موجود على الخادم من خارج مجلدات القالب النشط. هذا ما يسمى تضمين الملفات المحلية (Local File Inclusion)، ويصنّف ضمن CWE-98.
متى يتحول التضمين إلى تنفيذ أكواد؟
الوصول إلى تنفيذ الأكواد عن بعد (Remote Code Execution) يحتاج ثلاثة شروط مجتمعة:
| الشرط | ما الذي يعنيه عمليًا |
|---|---|
مجلد يبدأ اسمه بـ page- في القالب النشط | مثل page-templates/ الموجود في Twenty Twelve وTwenty Fourteen وقوالب مثل Neve وHestia وSydney |
| — | — |
| ملف PHP يقبل وسائط من المهاجم | عمليًا الملف pearcmd.php |
الإعداد register_argc_argv = On | مفعّل في صور PHP الرسمية على Docker وإعدادات cPanel الافتراضية قبل PHP 8.5 |
لاحظ أن الشرط الثالث شائع جدًا عند شركات الاستضافة المشتركة في المنطقة العربية، فأغلبها يعتمد على cPanel بإعداداته الافتراضية. لا تفترض أن موقعك خارج الخطر.
خطوات التحديث
الإجراء الأهم هو تحديث نواة ووردبريس. على الفرع الحالي يعني ذلك 7.1.2، وإن كنت مضطرًا للبقاء على فرع أقدم فهناك ترقيع له، مثل 7.0.6 أو 6.9.9 أو 6.8.10.
1. خذ نسخة احتياطية أولًا
# Example using WP-CLI to export the database
wp db export backup-$(date +%F).sql --allow-root
احتفظ أيضًا بنسخة من الملفات، خصوصًا مجلد wp-content.
2. حدّث النواة عبر WP-CLI
واجهة أوامر ووردبريس (WP-CLI) هي الطريقة الأسرع على الخوادم:
wp core update --allow-root
wp core version --allow-root
تأكد أن الإصدار الظاهر هو الإصدار المرقّع لفرعك.
3. أو حدّث من لوحة الاستضافة
إذا كنت تدير الموقع من cPanel أو Plesk أو لوحة استضافة مُدارة، استخدم أداة التحديث بضغطة واحدة أو فعّل التحديث التلقائي. ثم تحقق من رقم الإصدار من لوحة التحكم > حول ووردبريس.
4. فعّل التحديثات التلقائية للإصدارات الفرعية
أضف السطر التالي إلى wp-config.php حتى تصل الترقيعات الأمنية القادمة دون تدخل منك:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
لم تستطع التحديث الآن؟ اكسر شروط الاستغلال
هذه الخطوات لا تغلق ثغرة التضمين نفسها، لكنها تقطع الطريق المعروف إلى تنفيذ الأكواد:
- اضبط
register_argc_argv = Offفي إعدادات PHP، ثم تحقق:
php -i | grep register_argc_argv
- ابحث عن
pearcmd.phpعلى الخادم، واحذفه إذا لم يكن هناك ما يحتاج PEAR:
find / -name pearcmd.php 2>/dev/null
على الاستضافة المشتركة غالبًا لن تملك هذه الصلاحيات، فاطلب من الدعم الفني تنفيذها أو تأكيد أن الخادم مرقّع.
تقوية عامة لموقعك
الترقيع يغلق هذه الثغرة تحديدًا، والتقوية تقلل أثر الثغرة القادمة.
امنع تنفيذ PHP في مجلد الرفع
هذا الإجراء لا يحمي من هذه الثغرة لأنها تضمّن ملفًا موجودًا أصلًا، لكنه مفيد ضد ثغرات رفع الملفات. على Nginx:
location ~* /wp-content/uploads/.*.php$ {
deny all;
}
وعلى Apache، ضع ملف .htaccess داخل wp-content/uploads/:
<Files "*.php">
Require all denied
</Files>
عطّل محرر الملفات في لوحة التحكم
define( 'DISALLOW_FILE_EDIT', true );
استخدم جدار حماية تطبيقات الويب (WAF)
Cloudflare أو Wordfence أو ModSecurity يمكنها حجب أنماط اجتياز المسارات قبل وصولها إلى PHP. حتى الخطة المجانية من Cloudflare تضيف طبقة فلترة مفيدة، وهي شائعة الاستخدام مع الاستضافات العربية.
قيّد الوصول إلى صفحة الدخول
إذا كان عنوان IP الخاص بك ثابتًا، قيّد wp-login.php وxmlrpc.php عليه:
# Nginx example: restrict wp-login.php
location = /wp-login.php {
allow [your-admin-IP];
deny all;
}
مشكلات شائعة أثناء التحديث
- الأمر
wpغير موجود: ثبّت WP-CLI من موقعه الرسمي wp-cli.org، والعملية تحميل ملف واحد ومنحه صلاحية التنفيذ. - فشل التحديث بسبب الصلاحيات: تأكد أن مستخدم خادم الويب (غالبًا
www-dataعلى Ubuntu وDebian) يملك ملفات الموقع:
chown -R www-data:www-data /var/www/html/
- الموقع تعطل بعد التحديث: استرجع النسخة الاحتياطية، ثم عطّل كل الإضافات وأعد التجربة لتحديد المتسبب.
- الاستضافة المُدارة لا تعرض تحديثًا: بعض الشركات ترقّع على مستوى الخادم أولًا. راسل الدعم الفني واطلب تأكيدًا مكتوبًا.
افحص سجلات الخادم
بعد التحديث، راجع سجلات الوصول (access logs) بحثًا عن طلبات تحتوي أسماء قوالب تبدأ بـ page- أو تحتوي pearcmd. وجود هذه الطلبات قبل التحديث يعني أن أحدًا جرّب موقعك، فافحص الملفات المعدلة حديثًا.
اقرأ أيضًا
الأسئلة الشائعة
س: هل موقعي متأثر بثغرة ووردبريس الأخيرة؟
ج: إذا كان إصدار ووردبريس بين 4.7.0 و7.1.1 دون الترقيع الخلفي لفرعك، فنعم. تنفيذ الأكواد يحتاج شروطًا إضافية، لكن ثغرة التضمين نفسها موجودة.
س: كيف أعرف إصدار ووردبريس الحالي؟
ج: من لوحة التحكم > حول ووردبريس، أو بالأمر wp core version على الخادم.
س: هل يكفي تفعيل Wordfence بدل التحديث؟
ج: لا. جدار الحماية يقلل الخطر، لكن الإصلاح الوحيد هو تحديث النواة.
س: أنا على استضافة مشتركة ولا أملك صلاحيات SSH، ماذا أفعل؟
ج: حدّث من لوحة ووردبريس أو من أداة الاستضافة، واطلب من الدعم الفني تعطيل register_argc_argv والتأكد من ترقيع الخادم.
الخلاصة
الموضوع مش محتاج تفكير: حدّث النهارده، وفعّل التحديثات التلقائية للإصدارات الفرعية، وبعدين اقفل register_argc_argv لو مش محتاجه. ولو بتدير مواقع لعملاء، ابعتلهم رسالة الأول قبل ما حد تاني يجرّب مواقعهم.
مرجع المقال (بالإنجليزية): WordPress 7.1.2 Patches a Critical Path Traversal to RCE: Update Now
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.
