اسم البرنامج الإضافي	إضافة مساحة مجانية
نوع الضعف	طلب تزوير موقع على الإنترنت
رقم CVE	CVE-2026-6701
الاستعجال	قليل
تاريخ نشر CVE	2026-05-04
رابط المصدر	CVE-2026-6701

تزوير الطلبات عبر المواقع (CSRF) مرتبط بالبرمجة النصية عبر المواقع المخزنة (XSS) في addfreespace <= 0.1.3 — ما يجب أن يعرفه ويفعله مالكو مواقع ووردبريس

تم الكشف عن ثغرة أمنية مؤخرًا تؤثر على إضافة مساحة مجانية مكون ووردبريس الإضافي (الإصدارات <= 0.1.3) وتم تخصيص CVE‑2026‑6701. الثغرة هي مشكلة CSRF (تزوير الطلبات عبر المواقع) يمكن ربطها بحالة XSS مخزنة (البرمجة النصية عبر المواقع). بينما تصنيف CVSS العام منخفض نسبيًا (4.3)، فإن المخاطر في العالم الحقيقي قد تكون أعلى مما تشير إليه الأرقام — خاصة عندما يستهدف المهاجمون المواقع في حملات جماعية أو يعتمدون على خداع المستخدمين المميزين للتفاعل مع رابط أو صفحة مصممة خصيصًا.

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

---

الملخص التنفيذي (ملاحظات سريعة)

• تسمح ثغرة في addfreespace (<= 0.1.3) للمهاجم بتقديم طلبات غير محمية ضد CSRF. إذا تم خداع مستخدم مميز (مدير أو دور مميز آخر) لزيارة صفحة خبيثة أو النقر على رابط خبيث، يمكن للمهاجم تخزين حمولات JavaScript في الموقع (XSS مخزنة).
• يمكن أن تؤدي XSS المخزنة المنفذة في سياق المدير إلى الاستيلاء على الحساب، تصعيد الامتيازات، سرقة البيانات، أو تثبيت أبواب خلفية دائمة.
• لا يوجد تصحيح رسمي للمكون الإضافي متاح في وقت النشر. يُنصح بشدة باتخاذ تدابير فورية.
• الإجراءات الفورية الموصى بها: تعطيل أو إزالة المكون الإضافي؛ تقييد الوصول إلى صفحات إدارة المكون الإضافي؛ تطبيق قواعد WAF أو تصحيحات افتراضية؛ فحص النصوص المدخلة والتعديلات المشبوهة؛ إعادة تعيين بيانات اعتماد المدير وتدوير المفاتيح؛ وتنفيذ تعزيزات طويلة الأجل.
• يمكن لمستخدمي WP‑Firewall تطبيق التصحيح الافتراضي، وقواعد WAF المدارة، والفحص النشط لتقليل المخاطر على الفور.

---

لماذا يعتبر CSRF المرتبط بـ XSS المخزنة خطيرًا (بمصطلحات بشرية)

CSRF و XSS هما نوعان مختلفان من الهجمات، ولكن عند دمجهما يصبحان قويين:

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

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

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

---

الأسباب الجذرية التقنية (ما الذي حدث بشكل خاطئ)

من التفاصيل المبلغ عنها وأنماط الاستغلال النموذجية، تشير السلسلة عادةً إلى الفشل التالي في كود الإضافات:

1. عدم وجود حماية من CSRF
   • عدم استخدام رموز WordPress (مثل، wp_create_nonce / check_admin_referer) للإجراءات التي تغير الحالة.
   • عدم التحقق من مصدر الطلب أو رأس المرجع لضمان أن الطلب جاء من واجهة إدارة موثوقة.
2. تحقق غير كافٍ من القدرات
   • قد لا تحتوي نقاط نهاية الإضافات على تحقق مناسب من قدرات المستخدم (current_user_can) أو تفرض القدرة المناسبة للمهمة.
3. عدم وجود أو عدم كفاية تنظيف البيانات والهروب من المخرجات
   • يتم حفظ بيانات المستخدم الخطرة المقدمة إلى قاعدة البيانات دون تنظيف (مثل، استخدام sanitize_text_field، wp_kses_post) ويتم إخراجها لاحقًا دون هروب (مثل، esc_html، esc_attr، أو تصفية kses المناسبة).
4. واجهات الإدارة التي تكشف عن نقاط نهاية قابلة للكتابة يمكن الوصول إليها عبر طرق HTTP غير مصادق عليها
   • روابط الإجراءات أو نقاط نهاية AJAX التي تقبل طلبات POST دون حماية مناسبة.

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

---

كيف سيتطور الهجوم عادةً (على مستوى عالٍ)

1. يحدد المهاجم نقطة نهاية الإضافة الضعيفة (على سبيل المثال، عنوان URL لإجراء إداري يستخدمه addfreespace).
2. يقوم المهاجم بإنشاء صفحة ويب تقوم بإجراء POST (أو GET) إلى تلك النقطة مع حمولة تحتوي على JavaScript (متجه XSS مخزن). يتضمن تقديم النموذج المعلمات المتوقعة من الإضافة.
3. يزور مسؤول (أو مستخدم مميز آخر) الصفحة الخبيثة أو ينقر على رابط أثناء تسجيل الدخول إلى موقع WordPress الضعيف.
4. نظرًا لأن الإضافة تفتقر إلى حماية CSRF، يتم قبول الطلب ويتم حفظ JavaScript الخبيث في قاعدة البيانات (على سبيل المثال، في خيار، بيانات ما بعد، أو حقل يتحكم فيه الإضافة).
5. عندما يعرض الموقع (أو صفحة الإدارة) لاحقًا تلك القيمة المخزنة دون تنظيف/هروب، يتم تنفيذ JavaScript في سياق متصفح المسؤول.
6. يمكن لـ JavaScript بعد ذلك:
   • قراءة الكوكيز أو التخزين المحلي (وإخراجها);
   • إجراء طلبات مصادق عليها باستخدام بيانات اعتماد المسؤول (مثل، إنشاء مستخدمين إداريين جدد، تثبيت إضافات);
   • تحميل سكريبتات خارجية لتنفيذ إجراءات إضافية أو للحفاظ على الاستمرارية.

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

---

التأثير - ما يمكن أن يحققه المهاجمون

يمكن أن يؤدي تنفيذ XSS المخزنة في جلسة متصفح إدارية إلى:

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

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

---

الإجراءات الفورية التي يجب عليك اتخاذها (أسلوب استجابة الحوادث)

إذا كنت تدير مواقع WordPress تستخدم addfreespace (<= 0.1.3)، اعتبر الوضع عاجلاً:

1. قم بإلغاء تنشيط الإضافة الآن
   • سجل الدخول إلى wp-admin وقم بإلغاء تنشيط addfreespace. إذا لم تتمكن من الوصول إلى wp-admin، قم بإعادة تسمية مجلد الإضافة عبر SFTP/SSH (wp-content/plugins/addfreespace -> addfreespace.disabled).
2. قم بإزالة الإضافة
   • إذا لم تكن بحاجة إليها بشكل صارم، قم بإزالتها من قاعدة الشيفرة. أحيانًا تكون إزالة الإضافة هي الخيار الأكثر أمانًا على المدى القصير حتى يتم إصدار نسخة مصححة.
3. ضع الموقع في وضع الصيانة أثناء التحقيق.
   • قلل من سطح الهجوم أثناء الفحص.
4. قم بتطبيق WAF / التصحيح الافتراضي على الفور.
   • احظر الطلبات إلى نقاط نهاية إدارة المكون الإضافي ورفض POSTs المشبوهة التي تحتوي على حمولة تشبه السكربت.
   • إذا كنت تستخدم WP‑Firewall، قم بتمكين مجموعة قواعد WAF المدارة والتصحيح الافتراضي لهذه الثغرة لمنع محاولات الاستغلال حتى مع بقاء المكون الإضافي موجودًا.
5. افحص الحمولة المدخلة ومدخلات قاعدة البيانات المشبوهة.
   • ابحث في المشاركات، الخيارات، بيانات المستخدم، والتخزين الآخر عن <script, عند حدوث خطأ=, تحميل=, ، أو أي معالجات أحداث JS أخرى تبدو غير متوقعة.
   • مثال (دفاعي، تشغيل كمسؤول عبر WP‑CLI أو عميل قاعدة البيانات):
     • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
     • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
   • ملحوظة: الاستعلامات الدقيقة أعلاه تفترض بادئات جداول قياسية. قم بتعديلها للبادئات المخصصة وسلامة الإنتاج.
6. تدوير بيانات الاعتماد والأسرار
   • إعادة تعيين كلمات المرور لجميع مستخدمي الإدارة.
   • قم بتدوير مفاتيح API، بيانات اعتماد حساب الخدمة، والمفاتيح في wp-config.php إذا كنت تشك في الاختراق.
7. مراجعة حسابات المستخدمين والأدوار
   • ابحث عن حسابات المسؤول غير المتوقعة أو المستخدمين ذوي الامتيازات المرتفعة.
8. مراجعة سجلات الخادم والوصول
   • افحص سجلات خادم الويب ومسارات التدقيق بحثًا عن POSTs أو طلبات مشبوهة إلى نقاط نهاية المكون الإضافي.
9. استعد من نسخة احتياطية معروفة جيدة إذا اكتشفت تغييرات لا يمكنك تنظيفها بأمان.
   • إذا وجدت أبواب خلفية أو تعديلات غير مفسرة، قد يكون الاستعادة النظيفة هي أسرع طريقة للتصحيح.
10. تعزيز وصول المسؤول
    • فرض المصادقة الثنائية (2FA) لجميع الحسابات المميزة.
    • قيد الوصول إلى منطقة الإدارة بواسطة IP إذا كان ذلك ممكنًا.
    • استخدم كلمات مرور قوية وفريدة من نوعها وسياسة قفل الحساب.

---

كيفية اكتشاف XSS المخزنة من هذه الثغرة (مؤشرات الاختراق)

ابحث عن العلامات التالية:

• JavaScript غير المتوقع في المشاركات، الصفحات، الخيارات أو محتوى الأدوات.
• مستخدمو الإدارة الجدد أو التغييرات غير المتوقعة في أدوار المستخدمين.
• محتوى واجهة الإدارة الذي يعرض تنبيهات غريبة أو نوافذ منبثقة أو إعادة توجيه.
• الطلبات الصادرة من الموقع إلى مجالات طرف ثالث غير مألوفة (تشير إلى تسرب البيانات أو الاستدعاء).
• سجلات الخادم التي تظهر طلبات POST إلى نقاط نهاية المكونات الإضافية من محيلين أو وكلاء مستخدمين غير عاديين.
• ارتفاع استخدام وحدة المعالجة المركزية أو جدولة مهام cron بشكل غير متوقع (تشير إلى أبواب خلفية).

فحوصات دفاعية مفيدة:

• بحث WP-CLI عن علامات السكربت في المشاركات والخيارات:
  • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'" --limit=100
  • wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%'" --limit=100
• قم بالمسح باستخدام ماسح ضوئي موثوق للبرامج الضارة (على مستوى الموقع أو المضيف) لاكتشاف الأبواب الخلفية المعروفة وwebshells.
• قارن الملفات الحالية مع لقطة نظيفة أو الملفات الأصلية الموزعة للمكون الإضافي للعثور على الملفات المعدلة.

عندما تجد محتوى مشبوه، عزلها ولا تنفذها في متصفح مباشر. اعتبرها ضارة حتى تثبت العكس.

---

إرشادات تصحيح على مستوى الكود للمطورين

إذا كنت تحافظ على المكون الإضافي أو تطور السمات/المكونات الإضافية، فهذه هي ممارسات الترميز الدفاعية الأساسية التي يجب اتباعها لمنع كل من CSRF وXSS المخزنة:

1. استخدم nonces وتحقق منها في كل طلب يغير الحالة
   • عند إنشاء نموذج أو رابط يقوم بتغيير الحالة:

     $nonce = wp_create_nonce( 'my_plugin_action' );

     قم بتضمينه في النماذج أو AJAX:

     <input type="hidden" name="_wpnonce" value="" />

   • عند معالجة الطلب:

     check_admin_referer( 'my_plugin_action' ); // أو check_ajax_referer لـ AJAX

2. تحقق من قدرات المستخدم
   • قبل تنفيذ الإجراءات، تحقق:

     if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'أذونات غير كافية' ); }

3. قم بتنظيف المدخلات قبل الحفظ
   • استخدم أدوات التنظيف المناسبة:
     • sanitize_text_field()، sanitize_email()، intval()، floatval()
     • لمدخلات HTML: wp_kses_post() أو wp_kses() مع قائمة مسموح بها آمنة
4. الهروب من الإخراج
   • دائماً قم بتشفير البيانات عند الطباعة:
     • esc_html(), esc_attr(), wp_kses_post() حسب السياق.
5. استخدم واجهة برمجة التطبيقات REST وتحقق من ردود أفعال الأذونات
   • بالنسبة لنقاط نهاية REST، نفذ permission_callback التي تتحقق من القدرات والرموز.
6. تحقق من أنواع البيانات المتوقعة والأطوال
   • فرض الأطوال القصوى والأحرف المسموح بها.

مثال (كود زائف دفاعي):

// في النموذج:
wp_nonce_field( 'my_plugin_save_settings'، '_wpnonce'، true );

// في معالج الإرسال:
if ( ! current_user_can( 'manage_options' ) ) {;

لمدخلات HTML التي تحتاج إلى السماح بعلامات محدودة:

$allowed = array(;

---

WAF والترقيع الافتراضي - قواعد عملية للتنفيذ الآن

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

1. حظر محتويات POST/GET المشبوهة إلى نقاط نهاية الإضافات
   • إنشاء قاعدة لفحص الطلبات التي تستهدف إجراءات إدارة الإضافات أو ملفات الإضافات. إذا كان جسم الطلب يحتوي على علامات سكريبت أو معالجات أحداث XSS الشائعة (onerror، onload، javascript:) قم بحظر الطلب.
2. فرض وجود المرجع أو الأصل لطلبات POST الإدارية
   • حظر أو تحدي (CAPTCHA) طلبات POST إلى wp-admin/admin-post.php، admin-ajax.php، أو نقاط نهاية محددة للإضافات التي لا تتضمن مرجعًا صالحًا أو معلمة _wpnonce.
3. تحديد معدل وتحدي الطلبات المجهولة إلى نقاط النهاية الإدارية
   • العديد من محاولات الاستغلال مؤتمتة. يقلل تحديد المعدل من الهجمات الكبيرة المؤتمتة.
4. التصحيح الافتراضي: اعتراض أنماط الاستغلال المعروفة
   • حظر الطلبات التي تتطابق مع أسماء المعلمات الدقيقة أو أنماط URL المستخدمة من قبل الإضافة المعرضة للخطر عند احتوائها على محتوى مشبوه.
5. حظر الطلبات التي تحاول إنشاء/تعديل خيارات بمحتوى سكريبت
   • إذا حاول طلب تحديث wp_options أو الحقول المستخدمة عادةً من قبل الإضافة مع <script في الحمولة، قم بحظره.

مثال على قاعدة جدار حماية مفاهيمي (زائف):

إذا كانت request.path تتطابق مع "/wp-admin/admin-post.php" أو "/wp-admin/*addfreespace*" وكانت request.method ضمن (POST، GET) إذن

ملحوظات:

• تجنب القواعد الواسعة جدًا التي قد تؤدي إلى إيجابيات خاطئة. اختبر في وضع المراقبة أولاً.
• استخدم القواعد المدمجة مع التسجيل والتنبيهات حتى تتمكن من التكيف بسرعة.

إذا كنت مستخدمًا لـ WP‑Firewall، قم بتمكين مجموعة القواعد المدارة التي تستهدف أنماط استغلال CSRF/XSS وقم بتمكين التصحيح الافتراضي لثغرات addfreespace. يوفر هذا حماية فورية أثناء متابعتك للإصلاحات طويلة الأجل.

---

قائمة التحقق بعد الإصلاح (ماذا تفعل بعد إزالة الإضافة أو تطبيق تصحيح)

1. تأكد من إزالة الإضافة أو تحديثها إلى إصدار مصحح عند توفره.
2. إعادة فحص الموقع بالكامل بحثًا عن التعليمات البرمجية الضارة، وwebshells، والملفات المعدلة.
3. راجع قاعدة البيانات للحمولات المخزنة وقم بإزالتها أو تطهيرها.
4. قم بتدوير بيانات الاعتماد: كلمات مرور المسؤول، مفاتيح SSH، مفاتيح API.
5. أعد إصدار أي رموز أو مفاتيح مسربة قد تكون تعرضت.
6. استعد نسخة احتياطية نظيفة إذا لم تتمكن من ضمان أن الموقع نظيف بالكامل.
7. راقب السجلات وكشف التسلل لمحاولات متكررة.
8. وثق الحادث، وإجراءاتك، وأي دروس مستفادة.

---

كيفية التواصل مع العملاء وأصحاب المصلحة (إذا كنت تدير مواقع أخرى)

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

---

قائمة التحقق من تعزيز الأمان التي يجب أن تكون ممارسة قياسية (لمنع مشاكل مماثلة)

• فرض المصادقة الثنائية لكل حساب إداري.
• تحديد وصول منطقة الإدارة عبر قائمة السماح IP حيثما كان ذلك ممكنًا.
• تعطيل تحرير الملفات في wp-admin:

  define( 'DISALLOW_FILE_EDIT', true );

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

---

إذا وجدت JavaScript مشبوه في قاعدة بياناتك - إرشادات تنظيف آمنة.

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

---

لماذا لا تعني درجة CVSS المنخفضة “لا شيء مهم”

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

---

دليل استجابة سريعة للحوادث (صفحة واحدة)

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

---

جرب خطة WP‑Firewall Basic (مجانية) — حماية أساسية دون تكلفة إضافية

إذا كنت تبحث عن حماية عملية وفورية أثناء اتباع الخطوات أعلاه، فكر في الاشتراك في خطة WP‑Firewall Basic (مجانية). تتضمن الحمايات الأساسية التي تساعد في حظر محاولات الاستغلال وتقليل تعرضك بسرعة:

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

يمكنك التسجيل في الخطة المجانية ونشر هذه الحمايات بسرعة على: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

كلمات أخيرة من فريق أمان WP‑Firewall

تعتبر الثغرات مثل سلسلة addfreespace CSRF→stored‑XSS تذكيرًا بأن الإضافات الصغيرة أو المتخصصة يمكن أن تقدم مخاطر كبيرة. الخبر السار: يمكنك اتخاذ إجراءات فعالة على الفور. قم بإلغاء تنشيط أو إزالة الإضافة، وطبق قواعد WAF والتصحيحات الافتراضية، وامسح بحثًا عن الحقن، وبدل بيانات الاعتماد، وقم بتقوية الوصول الإداري. إذا كنت تدير مواقع ويب متعددة (كوكالة أو مضيف)، قم بأتمتة الفحص والتصحيح الافتراضي لتقليل فترة التعرض عبر جميع المواقع.

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

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

— فريق أمان جدار الحماية WP

---

الملحق: أوامر مرجعية سريعة (دفاعية)

• ابحث عن علامات السكربت في المشاركات (قم بتعديل بادئة الجدول إذا لزم الأمر):

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

• ابحث في wp_options عن محتوى يشبه السكربت:

  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• قائمة بالملفات المعدلة مؤخرًا (آخر 7 أيام) على مضيف UNIX:

  find /path/to/wordpress -type f -mtime -7 -print

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