اسم البرنامج الإضافي	إضافة تاريخ ووردبريس التالية
نوع الضعف	البرمجة النصية عبر المواقع (XSS)
رقم CVE	CVE-2026-4920
الاستعجال	قليل
تاريخ نشر CVE	2026-05-12
رابط المصدر	CVE-2026-4920

عاجل: CVE-2026-4920 — XSS مخزنة مصادق عليها (مساهم+) في إضافة تاريخ ووردبريس التالية (≤ 1.0)

في 11 مايو 2026، تم الكشف عن ثغرة XSS مخزنة تؤثر على إضافة ووردبريس “تاريخ التالي” (الإصدارات ≤ 1.0) (CVE-2026-4920). تسمح الثغرة لمستخدم مصادق عليه لديه صلاحيات مساهم (أو أعلى) بتخزين HTML/JavaScript ضار يمكن أن يتم عرضه وتنفيذه لاحقًا في متصفح مستخدم إداري أو مستخدم ذو صلاحيات أخرى. تم تقييم نظام تسجيل الثغرات الشائعة (CVSS) لهذه المشكلة عند 6.5، مما يعكس تأثيرًا معتدلًا إلى مرتفع للمواقع التي يُسمح فيها للمساهمين بتقديم محتوى يتم مشاهدته لاحقًا من قبل مستخدمين ذوي صلاحيات أعلى.

يشرح هذا المنشور، بلغة خبراء بسيطة:

• كيف تعمل XSS المخزنة مثل هذه ولماذا هي مهمة
• مسارات الهجوم الواقعية وتأثيرها على موقع ووردبريس الخاص بك
• كيفية اكتشاف ما إذا كنت متأثرًا
• التخفيفات الفورية التي يمكنك تطبيقها (عندما قد لا يكون هناك تصحيح رسمي متاح)
• قواعد WAF القابلة للتنفيذ وأمثلة التكوين التي يمكنك تطبيقها الآن
• التوصيات وقائمة التحقق من استجابة الحوادث

نكتب هذا كفريق أمان WP‑Firewall — مع خبرة في الدفاع عن آلاف مواقع ووردبريس — وهدفنا هو تقديم إرشادات فورية وعملية وإنسانية يمكنك تطبيقها على الفور.

---

ملخص سريع (ماذا تفعل أولاً)

1. إذا كان لديك إضافة تاريخ ووردبريس التالية مثبتة وتستخدم إصدار 1.0 أو أقدم، اعتبرها معرضة للخطر.
2. إذا كان ذلك ممكنًا، قم بإلغاء تنشيط/إزالة الإضافة على الفور حتى يتوفر إصدار مصحح.
3. إذا لم تتمكن من إزالة الإضافة الآن، قم بتطبيق تصحيح افتراضي عبر جدار حماية تطبيق الويب (WAF) وقم بتقوية صلاحيات المستخدمين (تقييد من لديه وصول مساهم+).
4. قم بفحص موقعك بحثًا عن الحمولة المخزنة (ابحث في محتوى المنشورات، الحقول المخصصة، postmeta) وقم بمراجعة نشاط المساهمين الأخير.
5. قم بتدوير أي بيانات اعتماد للحسابات التي قد تكون قد شاهدت أو تفاعلت مع المحتوى وراجع السجلات بحثًا عن إجراءات إدارية مشبوهة.

أدناه نوسع في الكشف، والتخفيف، وقواعد WAF العملية — بما في ذلك كيفية حماية WP‑Firewall لك، بدءًا من خطتنا الأساسية المجانية.

---

ما هي XSS المخزنة ولماذا تعتبر صلاحية “مساهم” ذات صلة؟

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

ما يجعل CVE-2026-4920 ملحوظًا هو الحد الأدنى من الامتيازات المطلوبة للمهاجم: مساهم (أو أعلى). في العديد من مواقع ووردبريس، يتم منح وصول بمستوى مساهم لمبدعي المحتوى الخارجيين، المدونين الضيوف، أو الموظفين الأقل موثوقية. إذا كان بإمكان هؤلاء المستخدمين إدخال تعليمات برمجية في حقول يتم عرضها لاحقًا في متصفح مسؤول أو مستخدم متميز، فإن التأثير يمكن أن يكون كبيرًا - بما في ذلك سرقة جلسة المسؤول، إضافة أبواب خلفية، أو السيطرة على الموقع من خلال الهندسة الاجتماعية للمسؤولين.

يتطلب XSS المخزن عادةً خطوتين:

1. يقوم المهاجم (المساهم) بتخزين الحمولة الضارة عبر نموذج إدخال المكون الإضافي.
2. يقوم مستخدم متميز (محرر، مسؤول) لاحقًا بعرض صفحة أو شاشة إدارة تعرض تلك الحمولة؛ يتم تنفيذ البرنامج النصي لأن التطبيق لم يقم بتفريغ أو تطهير الإخراج.

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

---

سيناريوهات الهجوم الواقعية

• الهندسة الاجتماعية: يقوم المساهم بإنشاء “حدث” أو منشور يحتوي على برنامج نصي مصمم بعناية. عندما ينقر مسؤول الموقع للموافقة أو مراجعة الحدث، يتم تشغيل البرنامج النصي ويسرق ملف تعريف جلسة المسؤول أو رمز CSRF، مما يسمح للمهاجم باختطاف جلسة المسؤول.
• تصعيد الامتيازات: بالاقتران مع سوء إدارة كلمات المرور أو إعادة استخدام بيانات الاعتماد، يمكن للمهاجم السيطرة على حساب المسؤول ثم تثبيت أبواب خلفية دائمة أو مكونات إضافية ضارة.
• تسمم المحتوى & بريد SEO العشوائي: يقوم المهاجمون بحقن برامج نصية مخفية تخلق روابط عشوائية أو تعيد توجيه الزوار إلى مواقع عشوائية/برامج ضارة، مما يضر بـ SEO وثقة العلامة التجارية.
• تحول سلسلة التوريد: إذا كان المسؤولون يديرون مواقع متعددة من حساب شبكة مشترك، يمكن أن تؤدي جلسة مسؤول مخترقة إلى حركة جانبية عبر ممتلكات أخرى.

حتى إذا كان الاستغلال يتطلب نقرة أو تفاعل، يستخدم المهاجمون بانتظام رسائل بريد إلكتروني/رسائل مت disguised كإشعارات مسؤول شرعية لتحفيز تلك النقرات.

---

مؤشرات الاختراق التي يجب أن تبحث عنها الآن

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

• wp_posts.post_content - محتوى المنشور الذي أنشأه المساهمون
• wp_postmeta - بيانات المكون الإضافي والحقول المخصصة
• wp_comments - إذا كان المكون الإضافي الخاص بك يخزن الإدخال في التعليقات
• جداول قاعدة البيانات الخاصة بالمكون الإضافي (بعض المكونات الإضافية تنشئ جداولها الخاصة)

أمثلة SQL مفيدة (تشغيلها من wp‑cli أو مسؤول قاعدة البيانات لديك):

-- ابحث عن علامات السكربت في محتوى المنشور;

باستخدام WP‑CLI:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

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

---

تدابير فورية (دقائق إلى ساعات)

إذا لم يكن هناك تصحيح رسمي متاح، إليك الخطوات الفورية التي يمكنك اتخاذها:

1. قم بإلغاء تنشيط أو إزالة مكون Next Date (أفضل حل إذا كنت لا تحتاجه الآن).
2. قيد صلاحيات المساهمين:
   • قم بإزالة دور المساهمين مؤقتًا عن المستخدمين غير الموثوق بهم.
   • قم بضبط الموقع بحيث تظهر مساهمات المساهمين فقط بعد مراجعة المسؤول وإزالة أي عرض تلقائي في شاشات الإدارة.
3. عزز حسابات الإدارة:
   • فرض المصادقة الثنائية (2FA) لجميع حسابات المحررين/المسؤولين.
   • قم بتدوير كلمات المرور ومفاتيح API المستخدمة من قبل أي حسابات قامت بعرض أو الموافقة على محتوى المساهمين.
4. تصحيح افتراضي باستخدام WAF:
   • أنشئ قواعد مستهدفة تمنع توقيعات XSS الشائعة في أي طلبات POST/PUT إلى نقاط نهاية المكونات الإضافية.
   • حظر الطلبات التي تحتوي على أو javascript: أو معالجات أحداث مشبوهة في المعلمات المخصصة لتكون نصًا فقط.
5. أضف رؤوس سياسة أمان المحتوى (CSP) كدفاع مؤقت: يمكن أن يخفف هذا من تنفيذ السكربتات المضمنة، على الرغم من أنه ليس حلاً كاملاً.
6. قم بفحص الموقع بدقة (سلامة الملفات، ماسح البرامج الضارة) وإزالة أي آثار ضارة تم اكتشافها.
7. راقب السجلات عن كثب بحثًا عن شذوذ في جلسات المسؤولين أو مستخدمين جدد.

إذا كنت تدير WAF مُدار مثل WP‑Firewall، يمكنك تصحيح المشكلة افتراضيًا وتخفيفها بينما تستعد لحل طويل الأمد.

---

تصحيح WP‑Firewall الافتراضي: أمثلة على أنماط قواعد WAF

فيما يلي أمثلة عملية على قواعد WAF يمكنك نشرها في سياسة جدار الحماية الخاصة بك. هذه قواعد دفاعية تهدف إلى حظر الحمولة الضارة التي تستهدف متجهات XSS المخزنة. طبق بحذر: القواعد الواسعة جدًا يمكن أن تنتج إيجابيات خاطئة. اختبر في وضع الحظر→المراقبة قبل التنفيذ.

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

# حظر الحمولة الضارة الشائعة المضمنة في أجسام POST"

إذا كان جدار الحماية الخاص بك يدعم القواعد المعتمدة على المسار، استهدف نقاط نهاية المكون الإضافي بشكل محدد (مثل، /wp-admin/admin-ajax.php?action=nextdate_save أو نقاط نهاية ajax الخاصة بالمكون الإضافي).

تعبير عادي أكثر تفصيلاً لمطابقة مجموعة من توقيعات الهجوم:

(?i)(<\s*script\b||on\w+\s*=|javascript\s*:|data:text/html)

قاعدة مخصصة مقترحة لجدار الحماية WP‑Firewall (زائفة):

• الشرط: طريقة الطلب هي POST أو PUT
• الشرط: URI يتطابق مع نقاط نهاية المكون الإضافي أو شاشات الإدارة حيث يخزن المكون الإضافي البيانات
• الإجراء: إذا تطابق REQUEST_BODY مع التعبير العادي أعلاه، فقم بالحجر الصحي/التسجيل وارجع 403

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

---

قواعد الكشف النموذجية (للسجلات وSIEM)

استخدم هذه الأنماط لاكتشاف المحاولات أو العلامات في سجلاتك:

• سجلات الوصول حيث يتم POST إلى admin-ajax.php بمحتوى جسم مشبوه: ابحث عن <script في حمولات الطلبات
• صفحات الإدارة التي تظهر حقول HTML طويلة بشكل غير عادي أو العديد من الكيانات HTML
• منشورات جديدة أو عناصر ميتا حيث يكون دور المؤلف هو المساهم ويحتوي المحتوى على علامات نصوص مدمجة

عينة من grep:

# ابحث في سجلات الوصول عن أجسام POST المشبوهة (سجلات nginx المجمعة)

---

قائمة التحقق من التنظيف والاستجابة للحوادث

إذا اكتشفت حمولات ضارة أو علامات على الاختراق، اتبع تدفق استجابة الحوادث هذا:

1. عزل: ضع الموقع في وضع الصيانة، قيد وصول الإدارة (قائمة السماح IP).
2. لقطة: أنشئ نسخة احتياطية كاملة من الملفات وقاعدة البيانات للتحقيقات الجنائية.
3. إزالة المحتوى الضار: قم بإزالة المشاركات/المحتوى الميتا المسيء. إذا وجدت نصوص مشوشة، انسخها إلى ملف غير متصل لتحليلها.
4. تدوير بيانات الاعتماد: كلمات مرور المسؤولين، مفاتيح API، بيانات اعتماد قاعدة البيانات، وأي رموز تكامل.
5. المسح والتدقيق: قم بتشغيل فحص كامل للبرامج الضارة وتحقق من الملفات المعدلة للإضافات/النواة/القوالب.
6. استعد من نسخة احتياطية نظيفة إذا لزم الأمر: إذا كانت الاختراقات واسعة، استعد إلى نسخة احتياطية معروفة جيدة وطبق التخفيفات أولاً.
7. تعزيز الأمان: طبق تدابير الأمان الموصى بها (قواعد WAF، 2FA، مبدأ أقل الامتيازات).
8. شاشة: حافظ على مراقبة مشددة وراجع السجلات للعودة على الأقل لمدة 30 يومًا.
9. الإبلاغ: قم بإخطار مزود الاستضافة الخاص بك، وإذا لزم الأمر، الأطراف المعنية ذات الصلة والمسجلين.

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

---

لماذا يمكن استخدام هذه الثغرة في حملات استغلال جماعية

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

لهذا السبب نوصي بالتخفيف السريع والترقيع الافتراضي: تقلل الترقيعات الافتراضية من نافذة التعرض بينما يتم تطوير وإطلاق إصلاح مناسب.

---

أفضل ممارسات تعزيز الأمان (بجانب الإصلاحات الفورية)

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

---

كيف يحمي WP‑Firewall موقعك (ما نقدمه)

في WP‑Firewall نصمم حمايتنا لتكون عملية لمالكي المواقع الذين يحتاجون إلى دفاعات فورية وفعالة. الميزات ذات الصلة التي نقدمها:

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

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

---

قائمة مراجعة مجموعة قواعد WAF الموصى بها لهذه الثغرة

1. حظر طلبات POST التي تتضمن <script أو on\w+= في المعلمات التي من المفترض أن تكون نصوصًا عادية.
2. استهدف نقاط النهاية الخاصة بالمكونات الإضافية أولاً (admin-ajax أو معالجات نماذج المكونات الإضافية).
3. سجل أولاً، ثم احظر — راقب لمدة 24-72 ساعة لضبط القواعد.
4. طبق تحديد المعدل على نقاط النهاية المشبوهة حيث يقدم المساهمون المحتوى.
5. طبق تصفية قائمة على المخرجات حيثما كان ذلك ممكنًا (قم بإزالة علامات HTML غير المسموح بها عند الإدخال).
6. استجابات JSON: افحص وقم بتنظيف محتوى HTML داخل حمولات JSON.
7. فرض سياسة أمان المحتوى الصارمة (CSP): حظر السكربتات المضمنة إذا كانت بنية موقعك تسمح بذلك.

---

أمثلة عملية يمكنك لصقها في واجهة قواعد WP‑Firewall (مفاهيمية)

اسم القاعدة: حظر علامات السكربت المضمنة (وضع المراقبة)

• النطاق: جميع طلبات POST إلى /wp-admin/* أو أي نقاط نهاية معروفة للمكونات الإضافية
• حالة:
  • يتطابق جسم الطلب أو المعلمات مع regex: (?i)(<\s*script\b|on\w+\s*=|javascript\s*:|data:text/html)
• فعل: سجل وأعد 403 (بعد 24-72 ساعة من المراقبة)

اسم القاعدة: حظر تقديمات المساهمين المشبوهين (مستهدف)

• النطاق: الطلبات حيث دور المستخدم الحالي هو مساهم AND الطلب يحتوي على علامات HTML
• حالة:
  • دور المستخدم المكتشف (جلسة/كوكي) = مساهم
  • يحتوي جسم الطلب على < يتبعها سكربت أو على\w+
• فعل: رفض الطلب وإخطار المسؤولين

ملاحظة: التنفيذ الدقيق يعتمد على بيئة الاستضافة/WAF الخاصة بك. إذا كنت على خطة WP‑Firewall المدارة، ستقوم فريقنا بتكوين وضبط هذه القواعد لك.

---

استعلامات الكشف لمشرفي WordPress

• ابحث عن أي منشورات أنشأها المساهمون تحتوي على <script:

SELECT p.ID, p.post_title, u.user_login, p.post_date FROM wp_posts p JOIN wp_users u ON p.post_author = u.ID WHERE u.ID IN ( SELECT ID FROM wp_users WHERE ID IN (SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%contributor%') ) AND p.post_content LIKE '%<script%';

• ابحث عن الحدوث في بيانات ما بعد المقالات:

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value REGEXP '<script|on[A-Za-z]+\\s*=|javascript:'

---

احمِ موقعك على الفور — ابدأ بخطة WP‑Firewall المجانية

إذا كنت تريد شبكة أمان سريعة وعملية أثناء تقييمك أو تصحيحك للإضافات، فإن خطة WP‑Firewall الأساسية (مجانية) توفر لك الحماية الأساسية على الفور: جدار ناري مُدار، حماية غير محدودة من النطاق الترددي، WAF قوي، فحص تلقائي للبرامج الضارة، وتخفيف مدمج لمخاطر OWASP Top 10. تم تصميمها خصيصًا لتقليل نوافذ التعرض لمشكلات مثل CVE‑2026‑4920 أثناء إجراء إصلاحات أعمق. اشترك واحصل على الحماية مُكونة بسرعة على: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(إذا كنت بحاجة إلى إزالة تلقائية للبرامج الضارة وتحديثات افتراضية أكثر تقدمًا، فإن مستوياتنا المدفوعة توسع هذه القدرات مع التنظيف التلقائي، التحكم في القوائم البيضاء/السوداء لعناوين IP، تقارير أمان شهرية، ودعم ذي أولوية.)

---

الإصلاح على المدى الطويل: ما يجب على مطوري الإضافات القيام به

إذا كنت مطورًا تحافظ على إضافة تقبل إدخال المستخدم، فاتبع هذه القواعد:

• قم بتنظيف الإدخال وهرب المخرجات. لا تعتمد أبدًا على التحقق من صحة جانب العميل.
• استخدم واجهات برمجة التطبيقات الصحيحة لـ WordPress: تطهير حقل النص, wp_kses_post(), esc_html(), esc_attr() اعتمادًا على السياق.
• تجنب تخزين HTML الخام من المستخدمين غير الموثوقين. إذا كان يجب عليك، قم بإزالة العلامات والسمات الخطرة.
• صمم شاشات الإدارة بحيث لا يمكن عرض المحتوى المقدم من المستخدمين في سياقات مميزة دون هرب.
• أضف اختبارات تلقائية لأساليب XSS ودمج فحص الأمان في CI.

---

أفكار نهائية وخطوات قادمة

CVE‑2026‑4920 هو تذكير بأن حتى المستخدمين غير الإداريين (المساهمين) يمكن أن يكونوا وسيلة لخرق كبير للموقع إذا لم تقم الإضافات بتنظيف أو هروب المحتوى المخزن. بالنسبة لمالكي المواقع، فإن الخطوات الفورية واضحة: عزل أو إزالة الإضافة المعرضة للخطر، تطبيق تصحيحات افتراضية قائمة على جدار الحماية، تعزيز وصول الحساب، وإجراء تنظيف مركز إذا تم العثور على محتوى مشبوه.

إذا كنت بحاجة إلى مساعدة في حماية موقعك أثناء تقييم تصحيحات الإضافات، يمكن لـ WP‑Firewall نشر تصحيحات افتراضية مؤقتة مصممة لموقعك ومساعدتك في ضبط القواعد لتجنب الإيجابيات الكاذبة. تتضمن خطتنا الأساسية (المجانية) بالفعل حماية جدار الحماية المدارة وتخفيف OWASP حتى تتمكن من تقليل المخاطر في دقائق.

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

ابقى آمنًا
فريق أمان WP‑Firewall