ثغرة Forminator الحرجة: هل موقعك في خطر وماذا تفعل الآن؟

لو عندك نموذج على موقعك بيطلب من العميل يرفع ملف، سيرة ذاتية أو صورة إيصال تحويل، فالمقال ده يخصّك النهارده. إضافة Forminator، المثبتة على أكثر من 600 ألف موقع، كان فيها ثغرة بدرجة خطورة 9.8 من 10 تسمح لأي حد، من غير تسجيل دخول، يرفع ملف PHP على موقعك.

الخبر الكويس إن الإصلاح موجود من أواخر يوليو. الخبر الأقل لطفًا إن مواقع كتير لسه ما اتحدّثتش، وده بالظبط اللي بيدوّر عليه المهاجمين.

الخلاصة السريعة قبل التفاصيل

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

هل موقعك معرّض فعلًا؟

ليس كل موقع يستخدم Forminator معرّضًا بالدرجة نفسها. أجب عن ثلاثة أسئلة بالترتيب:

1. ما إصدار الإضافة؟ إن كان 1.56.2 أو أحدث فالثغرة مغلقة، وانتقل مباشرة إلى قسم الفحص للتأكد أن أحدًا لم يسبقك قبل التحديث.
2. هل لديك نموذج يجمع حقل رفع ملفات (File Upload) وحقل اختيار (Select)؟ هذا الشرط مذكور في تقرير Wordfence كما نقلته المصادر. نموذج تواصل بسيط بلا رفع ملفات لا يحقق الشرط.
3. هل فعّلت مسار تخزين مخصصًا للملفات (Custom File Upload Storage)؟ هنا الفرق الحقيقي بين رفع ملف وتشغيله.

ملاحظة: في السوق العربي النموذج المعرّض أشيع مما تظن. متاجر كثيرة في مصر تطلب من العميل رفع صورة إيصال InstaPay أو التحويل البنكي مع قائمة اختيار لطريقة الدفع، ومواقع التوظيف تطلب السيرة الذاتية مع قائمة بالقسم أو المدينة. هذا بالضبط مزيج «رفع ملف + Select».

كيف تعمل الثغرة دون الدخول في كود الاستغلال

الثغرة ليست خطأً واحدًا، بل خطآن صغيران اجتمعا في مكان واحد.

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

الخطأ الثاني: القائمة السوداء (Blocklist) قارنت النصوص حرفيًا. بقي خط دفاع أخير داخل الدالة handle_file_upload() يرفض أنواع MIME الخطيرة مثل application/x-php. المشكلة أن الفحص كان يبحث عن تطابق تام للمفتاح، فإضافة رمز واحد مثل | في آخر النوع تجعل القيمة «مختلفة» في نظر الكود، فيمر الملف.

النتيجة: ملف PHP باسم ومحتوى يختارهما المهاجم يُكتب على خادمك.

بصراحة: هذا الشرح قراءة لتقارير Wordfence وتحليلات منشورة عنها، لم نعِد إنتاج الثغرة على موقع تجريبي. ولهذا تعمّدنا عدم نشر طلب الاستغلال نفسه؛ ما يهمك كصاحب موقع هو الإغلاق والفحص.

لماذا يفرق مجلد الرفع المخصص كثيرًا؟

رفع ملف PHP شيء، وتشغيله شيء آخر. في الإعداد الافتراضي تضع Forminator ملف .htaccess (ملف إعدادات Apache) داخل مجلد الرفع يمنع تنفيذ PHP، فيعيد الخادم الملف كنص عادي بدل تشغيله.

أما عند تفعيل مسار تخزين مخصص، فحسب وصف Wordfence يُنشأ ملف الحماية هذا «عند الحاجة» أثناء معالجة إرسال من الواجهة الأمامية، لكن دالة ووردبريس المسؤولة عن كتابته لا تكون محمّلة في هذا المسار أصلًا. فتتراكم الملفات في المجلد المخصص بلا أي حماية، ويكفي طلب رابط الملف ليعمل كتنفيذ تعليمات برمجية عن بُعد (Remote Code Execution).

تنبيه: ملف .htaccess لا يعمل إلا على Apache وLiteSpeed. لو موقعك على خادم Nginx (شائع في VPS وبعض الاستضافات المُدارة)، فهذا الملف يُتجاهل تمامًا حتى في المجلد الافتراضي، وتحتاج قاعدة مكافئة في إعدادات الخادم.

خطة الإغلاق والفحص خطوة بخطوة

1. حدّث الإضافة

من لوحة التحكم: الإضافات ← Forminator ← تحديث. ولو تدير مواقع عملاء كثيرة وعندك وصول SSH، فـ WP-CLI أسرع:

# check the installed version
wp plugin get forminator --field=version

# update to the latest release
wp plugin update forminator

لو لا تستطيع التحديث فورًا لسبب ما (توافق، موافقة عميل)، عطّل حقل رفع الملفات مؤقتًا في النماذج التي تجمعه مع حقل اختيار، إلى أن تحدّث.

2. امنع تنفيذ PHP في مجلدات الرفع على مستوى الخادم

لا تعتمد على الإضافة وحدها لحماية مجلدها. على Apache أو LiteSpeed، ضع هذا في ملف .htaccess داخل مجلد الرفع المخصص (أو داخل wp-content/uploads كله):

<FilesMatch ".(php|phtml|phar)$">
    Require all denied
</FilesMatch>

وعلى Nginx، أضف داخل كتلة server ثم أعد تحميل الخادم:

location ~* ^/wp-content/uploads/.*.(php|phtml|phar)$ {
    deny all;
}

عدّل المسار لو كان مجلدك المخصص خارج wp-content/uploads. ولو استضافتك مشتركة بلا وصول لإعدادات Nginx، اطلب من الدعم الفني تطبيق القاعدة.

3. ابحث عن ملفات دخيلة

حتى بعد التحديث، قد يكون أحد سبقك. ابحث عن أي ملف PHP داخل مجلدات الرفع، فهي لا يجب أن تحتوي على أي منها:

find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.phar" ) -ls

لا تكتفِ بالحذف لو وجدت شيئًا. اعتبر الموقع مخترقًا: غيّر كلمات مرور المدير وقاعدة البيانات، وراجع حسابات المستخدمين، واستعد نسخة احتياطية سليمة إن أمكن.

4. راجع سجلات الوصول

ابحث في سجل الخادم (Access log) عن طلبات الإرسال إلى admin-ajax.php الخاصة بـ Forminator:

grep "admin-ajax.php" access.log | grep -i "forminator"

ملاحظة: السجلات العادية لا تحفظ محتوى طلبات POST غالبًا، فلن ترى قيمة حقل الاختيار المشبوهة. ما يفيدك هنا هو نمط الطلبات: عدد كبير من الإرسالات من عنوان واحد، أو إرسال يتبعه مباشرة طلب لملف داخل مجلد الرفع.

في Elementor: هل نموذج Elementor Pro متأثر؟

في Elementor: هذه الثغرة خاصة بإضافة Forminator ولا تمس نماذج Elementor Pro أو JetFormBuilder. لكن الدرس نفسه ينطبق على أي نموذج فيه حقل رفع ملفات: حدّد الأنواع المسموحة صراحةً في إعدادات الحقل (مثل pdf,jpg,png) بدل تركها مفتوحة، وطبّق قاعدة منع PHP السابقة على wp-content/uploads كله، لأنها تحميك من ثغرات أي إضافة قادمة لا من هذه فقط.

الدرس الأكبر للمطوّر والمستقل

لو تبني إضافات أو تعدّل نماذج لعملائك، فالثغرة تختصر قاعدتين:

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

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

الأسئلة الشائعة

س: حدّثت Forminator، هل أنا آمن الآن؟
ج: التحديث إلى 1.56.2 أو أحدث يغلق الثغرة نفسها، لكنه لا يحذف أي ملف رُفع قبل التحديث. افحص مجلدات الرفع بأمر find المذكور أعلاه للتأكد.

س: نموذجي فيه رفع ملفات فقط بدون قائمة اختيار، هل هو معرّض؟
ج: حسب تقرير Wordfence، الاستغلال يحتاج حقل رفع ملفات وحقل Select في النموذج نفسه. مع ذلك حدّث الإضافة، فلا داعي لترك إصدار معروف الثغرات على موقعك.

س: لا أستخدم مجلد رفع مخصصًا، فهل الخطر صفر؟
ج: الخطر أقل بكثير على Apache وLiteSpeed لأن ملف .htaccess الافتراضي يمنع تشغيل PHP. أما على Nginx فهذا الملف لا يعمل، فتحتاج قاعدة المنع في إعدادات الخادم.

س: كيف أعرف إذا كان موقعي اختُرق عبر هذه الثغرة؟
ج: أوضح علامة هي وجود ملفات .php أو .phtml داخل مجلدات الرفع، أو حسابات مدير لم تنشئها. إضافة أمان مثل Wordfence تساعد بفحص ملفات الموقع ومقارنتها بالنسخ الأصلية.

الخلاصة

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

مراجع إضافية: Forminator WordPress Flaw Can Enable Remote Code Execution — The Hacker News

مرجع المقال (بالإنجليزية): CVE-2026-15748 Explained: How One Pipe Character Broke an “Exact Match” Blocklist
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.