اسم البرنامج الإضافي	مكون إضافي لعرض محفظة ووردبريس، معرض الصور وشبكة المنشورات
نوع الضعف	تضمين الملف المحلي
رقم CVE	CVE-2026-32537
الاستعجال	عالي
تاريخ نشر CVE	2026-03-22
رابط المصدر	CVE-2026-32537

تضمين ملف محلي في عرض المحفظة (<= 3.5.1): ماذا يعني ذلك وكيف تحمي موقع ووردبريس الخاص بك

مؤلف: فريق أمان جدار الحماية WP
تاريخ: 2026-03-22

---

الملخص: تم الكشف عن ثغرة تضمين ملف محلي (LFI) (CVE-2026-32537) تؤثر على مكون ووردبريس الإضافي “عرض المحفظة، معرض الصور وشبكة المنشورات” (الإصدارات ≤ 3.5.1، تم تصحيحها في 3.5.2). نظرًا لأن الثغرة يمكن أن يتم تفعيلها بواسطة حساب منخفض الامتيازات، فهي ذات أولوية عالية. يشرح هذا المنشور ما هي هذه الثغرة، ولماذا هي مهمة، وكيف يستغلها المهاجمون، وإرشادات الكشف، وخطة تخفيف ذات أولوية (فورية إلى طويلة الأجل)، وكيف يمكن لـ WP-Firewall مساعدتك في الحفاظ على أمان موقعك - بما في ذلك خيار حماية مجاني.

---

جدول المحتويات

• ما هو تضمين الملفات المحلية (LFI)؟
• لماذا تعتبر هذه الثغرة في عرض المحفظة LFI خطيرة
• من المتأثر (الإصدارات والامتيازات)
• تقنيات استغلال LFI الشائعة (كيف يسيء المهاجمون استخدامها)
• مؤشرات الاختراق (ماذا تبحث عنه في السجلات والاستجابات)
• قائمة التحقق للاستجابة الفورية (الساعات الـ 24 الأولى)
• تخفيفات قصيرة الأجل (حتى تتمكن من التحديث)
• قواعد WAF الموصى بها وقواعد تعزيز الأمان (أمثلة)
• التحقيق والتنظيف (كيف تتحقق من أن موقعك نظيف)
• خطوات ما بعد الحادث لتقليل المخاطر المستقبلية
• كيف يحميك WP-Firewall (بما في ذلك خطتنا المجانية)
• الملحق: مقتطفات سريعة من .htaccess و nginx

---

ما هو تضمين الملفات المحلية (LFI)؟

تضمين ملف محلي (LFI) هو نوع من الثغرات حيث تأخذ تطبيق ويب إدخالًا وتستخدمه لتضمين ملفات من نظام الملفات المحلي دون التحقق أو تطهير ذلك الإدخال بشكل صحيح. إذا كان بإمكان المهاجم التحكم في اسم الملف/المسار الذي يتم تضمينه، فقد يتمكن من قراءة ملفات حساسة (على سبيل المثال،, wp-config.php أو /etc/passwd) أو، باستخدام تقنيات إضافية، تحقيق تنفيذ كود عن بُعد (RCE).

في مكونات ووردبريس الإضافية، غالبًا ما تنشأ LFI عندما يتضمن الكود ملفات PHP أو أجزاء ملفات ديناميكيًا بناءً على معلمات الطلب (على سبيل المثال: include( $plugin_dir . '/' . $_GET['template'] . '.php' )). إذا لم يكن ذلك المعامل مقيدًا، يمكن للمهاجم تزويد تسلسلات تنقل الدليل (../) أو مخططات التغليف (php://filter) لاسترجاع أو التلاعب بملفات عشوائية.

---

لماذا تعتبر هذه الثغرة في عرض المحفظة LFI خطيرة

هذه الثغرة الأمنية المحددة تحتوي على عدة ميزات تجعلها ذات أولوية عالية:

• مخاطر مشابهة لـ CVSS: قد تسمح الثغرة بالكشف عن ملفات تحتوي على بيانات اعتماد (اسم مستخدم/كلمة مرور قاعدة البيانات، الأملاح) أو مفاتيح خاصة، وفي بعض التكوينات يمكن استخدامها للتصعيد إلى اختراق كامل للموقع.
• متطلبات امتياز منخفضة: تشير التقارير إلى أن الاستغلال يمكن أن يتم بواسطة حسابات ذات دور المشترك - مما يعني أن المهاجمين الذين يمكنهم التسجيل أو الذين يتحكمون بالفعل في حساب منخفض الامتياز قد يكونون قادرين على استغلالها.
• بصمة واسعة: الإضافة المتأثرة شائعة وتستخدم في العديد من المواقع، مما يزيد من احتمالات المسح الجماعي الآلي ومحاولات الاستغلال.
• سهل الأتمتة: تعتبر عمليات تجاوز الدليل وتحميل الملفات بسيطة في البرمجة؛ يمكن للمهاجم إطلاق حملات جماعية تستهدف آلاف المواقع بسرعة.

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

---

من المتأثر (الإصدارات والامتيازات)

• الإضافة المتأثرة: محفظة بصرية، معرض الصور وشبكة المنشورات
• الإصدارات الضعيفة: ≤ 3.5.1
• تم تصحيحها في: 3.5.2
• CVE: CVE-2026-32537
• الامتياز المطلوب: مشترك (حساب منخفض الامتياز)

إذا كان موقعك يستخدم إصدارًا أقدم من 3.5.2، اعتبر ذلك أمرًا عاجلاً. حتى المواقع ذات الحركة المرورية الصغيرة يمكن أن تكون مستهدفة خلال حملات المسح الآلي.

---

كيف يستغل المهاجمون LFI (مستوى عالٍ، بدون كود استغلال)

تدفق الهجوم (نموذجي):

1. يقوم المهاجم بتحديد نقطة نهاية المكون الإضافي التي تقوم بإجراء تضمينات الملفات بناءً على معلمة يقدمها المستخدم.
2. يقومون بصياغة طلبات تحتوي على تسلسلات تجاوز الدليل (../) و/أو مخططات التغليف (php://filter, البيانات:) أو تسلسلات مشفرة (%2e%2e%2f) لقراءة الملفات خارج الدليل المقصود.
3. يتضمن التطبيق الملف المستهدف أو محتوياته المعالجة في استجابة الصفحة - مما يؤدي غالبًا إلى تسرب قيم التكوين أو بيانات الاعتماد أو شفرة المصدر للتطبيق.
4. مع بيانات الاعتماد الحساسة، قد يتصل المهاجم بقاعدة البيانات ويستخرج أسرارًا إضافية أو ينشئ مستخدمين إداريين.
5. في بعض الإعدادات، من خلال دمج LFI مع تسمم السجل أو قدرات كتابة الملفات الأخرى، قد يحقق المهاجمون RCE.

طرق الاستغلال الشائعة التي نراها في البرية:

• طلبات تحتوي على ../ أو تسلسلات تجاوز متعددة.
• استخدام php://filter/convert.base64-encode/resource=... لإجبار الخادم على إخراج شفرة PHP في تنسيق قابل للقراءة.
• طلبات تحاول تضمين wp-config.php, .env, ، أو ملفات النظام مثل /etc/passwd.

ملحوظة: نحن نتجنب عمدًا عرض شفرة الاستغلال. إذا كنت تدافع عن موقع، ركز على الكشف، والحظر، والتصحيح.

---

مؤشرات الاختراق (IoCs) - ما الذي يجب البحث عنه

قم بمسح سجلات الوصول وسجلات الأخطاء الخاصة بك بحثًا عن أنماط مشبوهة. ابحث عن:

• معلمات الاستعلام التي تحتوي على ../ (حرفية أو مشفرة في عنوان URL: %2e%2e%2f, %2e%2e/).
• طلبات تتضمن سلاسل مثل wp-config.php, /etc/passwd, .env, php://filter.
• طلبات مع لا شيء بايت أو %00 (غالبًا ما تستخدم لإنهاء السلاسل في بعض السياقات).
• طلبات إلى نقاط نهاية محددة للإضافات التي عادةً لا تأخذ أسماء الملفات، ولكنها الآن تحتوي على مدخلات تشبه مسارات الملفات.
• ردود غير متوقعة تتضمن بيانات اعتماد قاعدة البيانات، أو كود مصدر PHP، أو مقتطفات تكوين الخادم.
• زيادة في الطلبات من عنوان IP واحد أو من مجموعة من عناوين IP التي تؤدي إلى حمولات مشابهة.
• مستخدمون إداريون تم إنشاؤهم حديثًا، محتوى تم تغييره، أو مهام مجدولة مشبوهة (مدخلات wp_cron).
• وجود ملفات تشبه الويب شيل (ملفات تحتوي على محتوى base64 مشبوه، evals، أو أسماء عشوائية طويلة) في wp-content/uploads أو أدلة المكونات الإضافية.

مصطلحات البحث لاستخدامها عند مسح السجلات (منقحة):

• ..%2f أو ..%2e أو \.\./
• wp-config.php, php://filter, etc/passwd, .env
• %00
• ترميزات مشبوهة تبدو كأغلفة base64 في المعلمات

---

قائمة التحقق للاستجابة الفورية (الساعات الـ 24 الأولى)

إذا كان لديك الإضافة المعرضة للخطر مثبتة ولا يمكنك التحديث على الفور، قم بما يلي بالترتيب:

1. تحديث الإضافة إلى 3.5.2 (أو الأحدث) — هذه هي أفضل وأسرع حل.
2. إذا لم تتمكن من التحديث على الفور، قم بإلغاء تنشيط الإضافة. إلغاء التنشيط يمنع تنفيذ الكود المعرض للخطر.
3. إذا لم يكن إلغاء التنشيط ممكنًا، قم بحظر الوصول إلى دليل الإضافة باستخدام قواعد على مستوى الخادم أو التطبيق (أمثلة أدناه).
4. تغيير جميع كلمات مرور المسؤولين في ووردبريس وتدوير بيانات الاعتماد لـ FTP/SFTP، قاعدة البيانات، ولوحة التحكم في الاستضافة إذا كنت تشك في الاختراق.
5. مراجعة سجلات الوصول الأخيرة للـ IoCs أعلاه وعزل عناوين IP المشبوهة.
6. استعادة من نسخة احتياطية نظيفة إذا اكتشفت دليلًا على الاختراق ولا يمكنك إزالة العناصر الضارة بالكامل.
7. إجراء مسح كامل للموقع باستخدام ماسح ضوئي موثوق للبرامج الضارة ومراجعة يدوية للملفات الجديدة/المعدلة في محتوى wp (بما في ذلك التحميلات, المكونات الإضافية, المواضيع).
8. تمكين المراقبة والتنبيهات الإضافية - مراقبة سلامة الملفات، إشعار تسجيل الدخول، وتنبيهات تحميل الملفات الخطرة.

إذا وجدت دليلًا على نشاط استغلال (كشف الملفات، webshells، أو تصدير قاعدة البيانات)، اعتبر ذلك اختراقًا وانتقل إلى سير عمل استجابة الحوادث (انظر التحقيق والتنظيف أدناه).

---

تخفيفات قصيرة الأجل (حتى تتمكن من التحديث)

إذا لم يكن من الممكن تطبيق التصحيح الفوري (لأسباب تتعلق بالتوافق أو التشغيل)، قم بتطبيق هذه التخفيفات المؤقتة:

• حظر الطلبات التي تحتوي على حمولة تجاوز الدليل على مستوى خادم الويب أو WAF.
• رفض الوصول إلى نقاط دخول PHP الخاصة بالمكونات الإضافية من المستخدمين المجهولين باستخدام قواعد .htaccess/nginx (مقتطفات نموذجية أدناه).
• تقييد عمليات التحميل أو نقاط كتابة الملفات قدر الإمكان.
• تحديد ما يمكن أن تفعله حسابات مستوى المشتركين: إزالة المشتركين غير الموثوقين، تعطيل التسجيل العام إذا لم يكن مطلوبًا، وزيادة التحقق من الحسابات الجديدة (التحقق عبر البريد الإلكتروني، CAPTCHA).
• تعطيل المكون الإضافي في بيئات الاختبار والنسخ الاحتياطي كإجراء احترازي.
• استخدم تصحيحًا افتراضيًا (قاعدة WAF) تحظر أنماط الاستغلال المعروفة - هذا يشتري الوقت أثناء التخطيط لدورة تحديث واختبار كاملة.

هذه التدابير قصيرة المدى تقلل من التعرض ولكن لا تحل محل تطبيق تصحيح البائع. اعتبرها كحلول مؤقتة.

---

قواعد WAF الموصى بها وقواعد تعزيز الأمان (أمثلة)

أدناه أمثلة قواعد عملية مناسبة للإدراج في جدار حماية تطبيق الويب (WAF)، ModSecurity، أو تكوين الخادم. تم كتابتها لتكون واضحة، ويجب عليك تعديلها واختبارها في بيئتك - حظر حركة المرور المشروعة عن طريق الخطأ يمكن أن يعطل المستخدمين.

مهم: اختبر القواعد على موقع اختبار أولاً. استخدم وضع التسجيل فقط في البداية لضبط الإيجابيات الكاذبة.

1) حظر تسلسلات تجاوز الدليل في سلسلة الاستعلام:

ModSecurity (مثال)

SecRule ARGS|REQUEST_URI "@rx (\.\./|%2e%2e%2f|%2e%2e\\x2f)" \
  "id:10001,phase:2,deny,log,msg:'Block directory traversal attempt',severity:2"

تعبير عادي عام لحظر ../ والنسخ المشفرة في سلاسل الاستعلام:
النمط: (\.\./|%2e%2e%2f|%2e%2e\\x2f)

2) حظر php:// محاولات التغليف و php://filter الاستخدام لفرض الكشف عن مصدر PHP:

مود سكيورتي

SecRule ARGS|REQUEST_URI "@rx php://(filter|input|output)" \"

3) حظر الطلبات التي تطلب أسماء ملفات حساسة عبر الاستعلام:

الرفض إذا كان الاستعلام يحتوي على wp-config.php, .env, /etc/passwd، إلخ.

SecRule ARGS|REQUEST_URI "@rx (wp-config\.php|\.env|/etc/passwd)" \"

4) حظر محاولات حقن بايت فارغ:

SecRule REQUEST_URI|ARGS "@rx %00" \
  "id:10004,phase:2,deny,log,msg:'Null byte in request'"

5) تقييد الوصول إلى دليل الإضافات عبر إعدادات الخادم (مثال nginx)

حماية ملفات PHP الخاصة بالإضافات من الوصول الخارجي ما لم يكن ذلك ضرورياً:

location ~* /wp-content/plugins/visual-portfolio/.*\.php$ {

6) قاعدة .htaccess آمنة لحظر سلاسل الاستعلام المشبوهة (Apache):

ضعها في الجذر .htaccess (أضفها إلى قواعد WordPress):

<IfModule mod_rewrite.c>
RewriteEngine On
# Block directory traversal and php wrapper attempts
RewriteCond %{QUERY_STRING} (\.\./|%2e%2e%2f|php://|%00) [NC]
RewriteRule .* - [F,L]
</IfModule>

7) تحديد معلمات تضمين الملفات إلى القوائم البيضاء (إصلاح على مستوى التطبيق)

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

---

التحقيق والتنظيف - خطوة بخطوة

إذا اكتشفت أن استغلالاً قد حدث، اتبع هذه الخطوات:

1. ضع الموقع في وضع الصيانة وعزله عن الشبكة حيثما كان ذلك ممكنًا.
2. التقط لقطات الطب الشرعي: اجمع السجلات (خادم الويب، PHP-FPM، قاعدة البيانات)، سجل الطوابع الزمنية، وانسخ الملفات المشبوهة للتحليل غير المتصل.
3. حدد متجهات الوصول الأولية والإطار الزمني باستخدام سجلات الوصول. ابحث عن مؤشرات الاختراق المذكورة سابقًا.
4. ابحث عن ملفات PHP جديدة أو معدلة في wp-content/uploads, wp-content/المكونات الإضافية, wp-content/themes. يتم تخزين الويب شيل عادةً في دلائل التحميل.
5. تحقق من التغييرات غير المصرح بها في قاعدة البيانات: مستخدمون جدد كمديرين، منشورات معدلة، خيارات مشبوهة أو مهام مجدولة (خيارات wp, مستخدمو wp, wp_usermeta, خيارات wp مع التحميل التلقائي).
6. قم بتدوير بيانات الاعتماد: كلمات مرور مديري ووردبريس (جميع المديرين)، كلمة مرور مستخدم قاعدة البيانات، FTP/SFTP، وبيانات اعتماد لوحة التحكم في الاستضافة.
7. قم بإزالة أو حجر أي ملفات خبيثة. إذا كنت غير متأكد من الملفات التي يجب إزالتها، استعد من نسخة احتياطية نظيفة، قبل الاختراق.
8. نظف المؤشرات: أزل ملفات الباب الخلفي، أزل المهام المجدولة المشبوهة، وتأكد من أن الإضافات/الثيمات شرعية.
9. طبق تصحيح البائع (قم بتحديث الإضافة إلى 3.5.2 أو أحدث).
10. أعد فحص الموقع باستخدام أدوات متعددة (ماسح البرمجيات الخبيثة، مراقبة سلامة الملفات).
11. عزز الموقع وأضف مراقبة مستمرة: WAF، مراقبة سلامة الملفات، حماية تسجيل الدخول، و2FA لحسابات الإدارة.

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

---

توصيات ما بعد الحادث لتقليل المخاطر المستقبلية

بعد الإصلاح، اتخذ هذه الخطوات لتقليل فرصة تكرار الحوادث:

• حافظ على تحديث نواة ووردبريس، والثيمات، والإضافات بشكل منتظم. طبق التصحيحات الحرجة على الفور.
• قلل من استخدام الإضافات إلى الإضافات الموثوقة، التي يتم صيانتها بنشاط. أزل الإضافات والثيمات غير المستخدمة.
• قلل من الامتيازات: امنح المستخدمين فقط القدرات التي يحتاجونها. تجنب منح امتيازات المؤلف/المحرر/المدير دون داع.
• نفذ المصادقة الثنائية (2FA) لجميع حسابات الإدارة.
• استخدم كلمات مرور قوية وفريدة واحتفظ بها في مدير كلمات المرور.
• فرض أقل الامتيازات لحسابات قاعدة البيانات ونظام الملفات.
• قم بعمل نسخ احتياطية بانتظام (نسخ احتياطية خارج الخادم، محفوظة تاريخيًا) واختبر الاستعادة.
• استخدم جدار حماية تطبيقات مُدار يمكنه توفير تصحيح افتراضي، وتحديثات توقيع، ومراقبة.
• تنفيذ مراقبة سلامة الملفات والتنبيه.
• حافظ على عملية الكشف عن الثغرات للاستجابة بسرعة إذا تم العثور على مشكلات جديدة.

---

كيف يساعد WP-Firewall (ما تقدمه خدمتنا)

كفريق WP-Firewall، نبني ونشغل طبقات دفاعية مصممة خصيصًا لـ WordPress. نهجنا عملي ومتعدد الطبقات:

• جدار حماية تطبيق مُدار (WAF): نحافظ على قواعد تكشف وتمنع تجاوز الدليل، ومحاولات php:// wrapper، والترميزات المشبوهة، وأنماط استغلال محددة للإضافات. معلومات التهديد من مجتمعنا تُعلم التحديثات السريعة.
• التصحيح الافتراضي: عندما تهدد ثغرة يوم الصفر أو ثغرة مكشوفة المواقع، يمكننا نشر قواعد التخفيف التي تمنع حركة استغلال قبل تحديث الإضافة. هذا يمنحك مجالًا للتنفس لاختبار وتطبيق التصحيح الرسمي بأمان.
• فحص البرمجيات الضارة: فحص مستمر للملفات الخبيثة وأنماط الويب الشل الشائعة.
• تخفيفات OWASP Top 10: يتم مراقبة أنماط الحركة المتعلقة بالحقن، LFI/RFI، ومخاطر OWASP الأخرى وحظرها.
• التنبيهات والتقارير: تنبيهات فورية لمحاولات الاستغلال المحظورة وتقارير شهرية/في الوقت الحقيقي (على الخطط الأعلى).
• إرشادات الخبراء: نصائح خطوة بخطوة للتعامل مع الحوادث والتوصيات من خبراء أمان WordPress.

نوصي بتحديث الإضافة إلى الإصدار المصحح على الفور. بالنسبة للفرق التي لا يمكنها التحديث على الفور، يمكن لقواعد التصحيح الافتراضي من WP-Firewall تقليل المخاطر الفورية وحظر حمولات الاستغلال المعروفة بينما تخطط للتحديث.

---

ابدأ في حماية موقعك مجانًا — احصل على حماية WAF الأساسية الآن

احمِ موقع WordPress الخاص بك مع خطة WP-Firewall الأساسية المجانية. تشمل:

• جدار حماية مُدار وWAF قوي
• عرض نطاق غير محدود من خلال طبقة الحماية لدينا
• ماسح البرامج الضارة
• التخفيف من مخاطر OWASP العشرة الأوائل

إذا كنت ترغب في إضافة إزالة البرمجيات الضارة التلقائية، وقوائم الحظر/القوائم البيضاء لعناوين IP، وتقارير شهرية، وتصحيح افتراضي تلقائي، فكر في الترقية إلى خططنا المدفوعة.

اشترك في الخطة المجانية هنا:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(إذا كنت تحت ضغط للعمل الآن — قم بتمكين جدار الحماية المُدار وWAF، ثم قم بتحديث الإضافة كخطوتك التالية.)

---

الملحق: مقتطفات تكوين سريعة

استخدم هذه كنقاط انطلاق. اختبر دائمًا في بيئة الاختبار.

Apache (.htaccess) — حظر التنقل في سلاسل الاستعلام:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (\.\./|%2e%2e%2f|php://|%00) [NC]
RewriteRule .* - [F,L]
</IfModule>

nginx — رفض الوصول إلى ملفات PHP الخاصة بالمكونات الإضافية:

location ~* /wp-content/plugins/visual-portfolio/.*\.php$ {

أمثلة على قواعد ModSecurity (مفاهيمية):

# Block traversal sequences
SecRule ARGS|REQUEST_URI "@rx (\.\./|%2e%2e%2f)" \
  "id:10001,phase:2,deny,log,msg:'LFI traversal blocked'"

# Block php:// filters
SecRule ARGS|REQUEST_URI "@rx php://filter" \
  "id:10002,phase:2,deny,log,msg:'php://filter blocked'"

---

ملاحظات نهائية من خبراء أمان WP-Firewall

1. قم بتصحيح أولاً: التحديث إلى الإصدار المقدم من البائع (3.5.2+) هو الإصلاح الصحيح والدائم.
2. حظر الآن: إذا لم تتمكن من تطبيق التصحيح على الفور، استخدم WAF أو قواعد على مستوى الخادم لحظر التنقل في الدليل وأنماط php wrapper — هذه الحواجز فعالة في منع محاولات الاستغلال الشائعة القائمة على LFI.
3. التحقيق: تحقق من السجلات للـ IoCs المقدمة أعلاه واعتبر أن هناك اختراقًا إذا رأيت دليلًا على الوصول إلى wp-config.php أو ملفات حساسة أخرى.
4. تعزيز: بعد الإصلاح، قم بتقوية ضوابط الوصول، وتدوير بيانات الاعتماد، واستمر في المراقبة.

نعلم أن هذا يبدو كثيرًا — الأمان دائمًا كذلك — لكن الإجراءات السريعة والمحددة تعطي الفرق. إذا كنت بحاجة إلى مساعدة عملية، فإن فريق WP-Firewall يقدم خدمات استجابة للحوادث وحماية مُدارة لمساعدتك في العودة إلى حالة آمنة.

ابقى آمنًا
فريق أمان جدار الحماية WP