ثغرة تحديث WordPress تعرّض المواقع للخطر أثناء تثبيت الإصلاح

تبقى بعض مواقع WordPress عرضة للهجمات أثناء تثبيتها إصلاحاً لثغرة يجري استغلالها فعلياً، بحسب ما أفاد به أوموت بايرام، باحث في Picus Security.

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

تصيب الثغرة، المسجلة باسم CVE-2026-119977، إصدارات WordPress من 4.7 حتى 7.1.3. وأثناء تحديث النواة، يفكّ WordPress نسخة من الإصدار الجديد في مجلد مؤقت داخل wp-content/upgrade، يتضمن مثبّت WordPress المتاح لخادم الويب.

يمكن لمهاجم لا يملك حساباً استغلال ذلك عبر تحديد اسم المجلد والوصول إلى المثبّت قبل أن يحذف WordPress النسخة. وأضافت وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية (CISA) هذه الثغرة مؤخراً إلى كتالوج الثغرات المعروفة التي يجري استغلالها.

أصدر WordPress إصلاحاً في الإصدار 7.1.4 وتحديثات مقابلة للفروع الأقدم وصولاً إلى 4.7، وفق ما فصّله في استشارته الأمنية. ويُسنِد الإصلاح اسماً عشوائياً إلى المجلد المؤقت، لكن التحديث لا يزال يستخدم الشيفرة القديمة الموجودة على الموقع لفكّ ملفاته. وفي المواقع التي تعمل بالإصدار 5.9 أو أحدث، تسمّي هذه الشيفرة القديمة المجلد باسم الملف الذي جرى تنزيله، ما يجعل التسمية قابلة للتوقع.

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

يوضح بايرام أنه إذا استغل المهاجم التوقيت أثناء التحديث، فيمكنه إعداد النسخة المؤقتة من WordPress بقاعدة بيانات خاصة به وتنفيذ شيفرة PHP بصلاحيات خادم الويب قبل حذف النسخة، ما قد يتيح له قراءة الملفات أو كتابتها على الموقع الفعلي.

من يتعرض للخطر أثناء التحديث

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

فحصت The Hacker News خدمة التحديث في WordPress.org لإصدارات مختلفة. فبالنسبة إلى التحديثات داخل الفرع نفسه، مثل الانتقال من 7.1.3 إلى 7.1.4، قدّمت حزمة جزئية. أما التحديثات من فرع أقدم، مثل الانتقال من 7.0.7 إلى 7.1.4، فلم تُعرض لها سوى حزم كاملة.

بعد تثبيت الإصدار 7.1.4 أو إصلاح الفرع، تستخدم التحديثات اللاحقة اسماً عشوائياً للمجلد، ولا يُنسخ ملف wp-config.php الموجود في النسخة المؤقتة أبداً فوق الملف الفعلي.

ما يجب فعله قبل التحديث

يوصي بايرام بمنع خادم الويب من تقديم wp-content/upgrade كلياً. وحجب الوصول عبر الويب لا يعطّل التحديثات.

• احجب المجلد في إعدادات خادم الويب. في Nginx، أضف location ^~ /wp-content/upgrade/ { deny all; }. وفي Apache، أدرج Require all denied داخل كتلة لذلك المجلد.
• إذا كان بإمكانك تعديل .htaccess فقط، فأضف RedirectMatch 403 ^/wp-content/upgrade/ إلى ملف .htaccess في جذر WordPress.
• تجنّب وضع ملف .htaccess داخل wp-content/upgrade، لأن أداة التحديث القديمة تحذف كل ما في ذلك المجلد قبل فكّ التحديث.
• تأكد من أن طلباً إلى /wp-content/upgrade/ يعيد الخطأ 403.
• حدّث إلى الإصدار 7.1.4 أو الإصدار المُصلح لفرعك.

ثمة نهج آمن آخر هو إجراء تحديث يدوي خارج جذر الويب. ويتضمن ذلك نسخ ملفات الموقع وقاعدة البيانات احتياطياً، وفكّ الإصدار الجديد في مجلد غير متاح لخادم الويب، ثم تنفيذ تحديث قاعدة بيانات WordPress.

لم تعد إصدارات WordPress 4.6 والأقدم تتلقى تحديثات أمنية، ما يتركها دون إصلاح. ويشير بايرام إلى أن هذه الثغرة تعود إلى WordPress 2.7 الذي صدر في 2008، ويحث تلك المواقع على الترقية إلى إصدار مدعوم.

الهجمات وما يجب فحصه

استندت إضافة CISA للثغرة إلى كتالوجها إلى أدلة على استغلال فعلي. وأفادت Wordfence برصد محاولات هجوم بدأت بعد نشر قاعدة جدار حماية للثغرة بوقت قصير. ودرجتها للثغرة في سجل CVE هي 8.1 من 10 على مقياس CVSS.

بالنسبة إلى المواقع التي بقيت على إصدار متأثر بعد الإصدار، تقترح Wordfence مراقبة ما يلي:

• طلبات غير متوقعة إلى ملفات PHP تحت wp-content/upgrade
• حسابات مسؤول غير مألوفة
• إضافات لم تُثبَّت
• ملفات PHP في wp-content/upgrade لم يضعها مالك الموقع هناك

أبلغ بايرام The Hacker News بأن تعرّض التحديث الجزئي للخطر يعتمد على محتويات الحزمة المحددة. فالحزمة الجزئية تتضمن فقط الملفات التي تغيرت بين إصدارين، وإذا لم تكن تلك الملفات تحتوي ملفات المثبّت، فلا يمكن للنسخة المؤقتة أن تعمل كتثبيت WordPress.

العامل الحاسم هو ما إذا كانت أداة التحديث المثبتة على الموقع قد جرى إصلاحها.

 

المصدر: The Hacker News