اسم البرنامج الإضافي	AIWU
نوع الضعف	حقن SQL
رقم CVE	CVE-2026-2993
الاستعجال	عالي
تاريخ نشر CVE	2026-05-12
رابط المصدر	CVE-2026-2993

حقن SQL العاجل في WordPress AI Chatbot & Workflow Automation (AIWU) <= 1.4.17 — ماذا تفعل الآن

في 12 مايو 2026، تم نشر ثغرة خطيرة (CVE-2026-2993) لإضافة WordPress “AI Chatbot & Workflow Automation بواسطة AIWU” (المعبأة عادةً كـ AI Copilot / AIWU). الإصدارات حتى 1.4.17 مشمولة في حقن SQL غير مصادق عليه في دالة تسمى getListForTbl().

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

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

---

ملخص سريع (لأصحاب المواقع الذين يريدون الأساسيات)

• الإضافة المتأثرة: WordPress AI Chatbot & Workflow Automation بواسطة AIWU (AI Copilot / AIWU)
• الإصدارات المعرضة للخطر: <= 1.4.17
• الثغرة: حقن SQL غير مصادق عليه في getListForTbl() (CVE-2026-2993)
• الخطورة: عالية (CVSS 9.3)
• قابلة للاستغلال عن بُعد بدون مصادقة
• الإجراءات الفورية: تحديث الإضافة عند توفر إصدار آمن؛ إذا لم يكن ذلك ممكنًا، اتخذ تدابير مؤقتة — تعطيل أو إزالة الإضافة، تقييد الوصول إلى نقطة النهاية المعرضة للخطر، أو تطبيق تصحيح افتراضي باستخدام WAF (موصى به).
• إذا كنت تستخدم WP-Firewall، قم بتمكين قاعدة WAF الحية لهذه الثغرة أو اشترك في خطتنا المجانية للحصول على حماية فورية: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

لماذا هذا خطير جداً

تسمح ثغرات حقن SQL (SQLi) للمهاجم بحقن عبارات SQL في استعلامات قاعدة البيانات التي تعمل بها تطبيقك. عندما يتم تشغيل الكود المعرض للخطر بدون تهيئة أو تنظيف مناسب، يمكن للمهاجم التلاعب بالاستعلامات لـ:

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

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

---

نظرة عامة تقنية (مستوى عالٍ — لا يوجد كود استغلال)

يُبلغ عن حدوث الثغرة في دالة تُدعى getListForTbl() داخل الإضافة. استنادًا إلى تفاصيل الإشعار العام، تنشأ المشكلة من بناء استعلامات SQL باستخدام مدخلات غير مُعالجة من معلمات HTTP. نمط غير آمن نموذجي يبدو كأنه يدمج معلمات الطلب مباشرة في سلسلة SQL وينفذها باستخدام كائن قاعدة بيانات ووردبريس ($wpdb) دون استخدام بيانات مُعدة مسبقًا أو هروب صحيح.

لماذا يهم ذلك:

• يوفر WordPress $wpdb->تحضير() لربط المعلمات بأمان. عندما يتجاهل الكود بيانات مُعدة مسبقًا ويقوم بدمج المتغيرات مباشرة في SQL، يمكن لقيمة معلمة خبيثة أن تغير منطق SQL.
• إذا كانت الإضافة تعرض نقطة نهاية AJAX أو واجهة أمامية تقبل المعلمات وتقوم بتمريرها إلى getListForTbl() دون التحقق، يمكن للمهاجم صياغة طلبات تقوم بحقن SQL.

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

---

كيف يمكن أن يستغل المهاجم هذا (سيناريوهات)

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

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

---

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

تحقق من موقعك بحثًا عن العلامات المشبوهة التالية. لا تعتبر أي من هذه الأدلة قاطعة على الاستغلال بمفردها، لكنها تستدعي الانتباه الفوري:

• أخطاء غير مفسرة في السجلات تشير إلى تحذيرات قاعدة البيانات، أخطاء SQL، أو استعلامات مشوهة.
• أعداد كبيرة من الطلبات إلى نقاط نهاية محددة للإضافات (نقاط نهاية AJAX، مسارات REST) من عناوين IP غير عادية أو نطاقات IP.
• استعلامات قراءة قاعدة بيانات غير متوقعة لـ information_schema أو بيانات وصفية أخرى (إذا كانت سجلات قاعدة البيانات أو جدار الحماية لديك يمكن أن تظهر نص الاستعلام).
• حسابات مستخدمين جديدة بصلاحيات مسؤول لم تقم بإنشائها.
• ملفات الإضافات/الثيمات المعدلة أو تغييرات الملفات الأخيرة في wp-content/uploads، wp-content/plugins، أو wp-content/themes التي لم تفوضها.
• مهام مجدولة مشبوهة (cron) أو وظائف cron جديدة في ووردبريس.
• اتصالات الشبكة الصادرة من موقعك التي لا تتوقعها (رفع البيانات إلى مضيفين يتحكم بهم المهاجم).
• إرسال رسائل بريد إلكتروني مزعجة من نطاقك أو تغييرات في إعدادات البريد.
• زيادة في تحميل وحدة المعالجة المركزية أو قاعدة البيانات في وقت قصير.

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

---

خطوات فورية للتخفيف من التعرض (خطوة بخطوة)

إذا كان موقعك يستخدم مكون AIWU ويعمل بإصدار ضعيف (<= 1.4.17)، تصرف على الفور. اختر الخطوات التي تناسب بيئتك وقيود التشغيل.

1. تأكيد وجود الإضافة والإصدار
   • لوحة التحكم: المكونات الإضافية > المكونات الإضافية المثبتة > تحقق من رقم الإصدار.
   • FTP/SSH: افحص مجلد المكون الإضافي (wp-content/plugins//readme.txt أو رأس الملف الرئيسي للمكون الإضافي).
2. إذا كان بإمكانك تحديث المكون الإضافي بأمان إلى إصدار مصحح، فافعل ذلك على الفور.
   • قم بالتحديث عبر لوحة إدارة WP أو باستخدام composer إذا كان موقعك يستخدم إدارة التبعيات.
   • بعد التحديث، قم بمسح الذاكرة المؤقتة وأعد فحص الموقع باستخدام ماسح البرمجيات الخبيثة الخاص بك.
3. إذا لم يكن هناك تصحيح رسمي متاح، أو لا يمكنك التحديث على الفور:
   • قم بإلغاء تنشيط المكون الإضافي مؤقتًا:
     • المكونات الإضافية > تعطيل (سريع وموثوق).
     • إذا لم تتمكن من الوصول إلى واجهة الإدارة، قم بإعادة تسمية دليل المكون الإضافي عبر SFTP/SSH (على سبيل المثال، من aiwu إلى aiwu.disabled).
   • هذا يمنع تشغيل الكود الضعيف.
4. تصحيح افتراضي باستخدام جدار حماية تطبيقات الويب (موصى به عندما لا يكون التحديث ممكنًا)
   • نشر قاعدة WAF لحظر الطلبات التي تحاول أنماط حقن SQL، وحظر الوصول بشكل خاص إلى نقطة النهاية الضعيفة أو المعلمات المستخدمة بواسطة getListForTbl().
   • إذا كنت تستخدم WP-Firewall، قم بتمكين قاعدة التخفيف المنشورة لدينا لهذه الثغرة. تقوم قاعدتنا بحظر أنماط الاستغلال الشائعة لهذه الثغرة حتى يتوفر تصحيح رسمي للإضافة.
5. قيد الوصول إذا كانت نقطة النهاية هي شاشة الإدارة:
   • حدد الوصول إلى wp-admin ونقاط نهاية الإضافات حسب IP (حيثما كان ذلك ممكنًا).
   • استخدم مصادقة HTTP على wp-admin لإضافة حاجز وصول آخر.
   • قم بتعطيل استدعاءات AJAX من الواجهة الأمامية للإضافة (إذا سمحت الإعدادات).
6. قم بتدوير بيانات الاعتماد والأسرار:
   • قم بتدوير أي بيانات اعتماد مستخدم قاعدة بيانات إذا كان هناك أي علامة على الاختراق.
   • قم بتدوير كلمات مرور مسؤول WordPress ومفاتيح API المخزنة في قاعدة البيانات.
7. قم بأخذ النسخ الاحتياطية واللقطات:
   • قبل إجراء تغييرات إضافية، قم بأخذ نسخة احتياطية كاملة من الملفات وقاعدة البيانات للتحليل الجنائي.
   • قم بتخزين النسخ الاحتياطية في موقع خارجي.
8. راقب السجلات وحركة المرور:
   • قم بتمكين تسجيل متقدم لطلبات HTTP واستعلامات قاعدة البيانات.
   • راقب محاولات الاستغلال المتكررة بعد التخفيف (غالبًا ما يعيد المهاجمون المحاولة).

---

إرشادات WAF / التصحيح الافتراضي (أنماط، وليس حمولات الاستغلال)

يمكن أن يمنع WAF العديد من محاولات حقن SQL قبل أن تصل إلى التطبيق. فيما يلي إرشادات قواعد عامة موصى بها يمكنك تطبيقها لحظر أنماط الاستغلال الشائعة. لا تستخدم هذه كخط الدفاع الوحيد - فهي تخفيف حتى يتم تطبيق تحديث رسمي للإضافة.

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

• حظر الطلبات التي تحتوي على كلمات SQL مشبوهة في المعلمات أو URI عندما تظهر بالاقتران مع أحرف ميتا مشبوهة:
  • الأنماط التي يجب مراقبتها: UNION SELECT، information_schema، LOAD_FILE(، INTO OUTFILE، SLEEP(، –، /*، أو محددات الاستعلامات المكدسة مثل ;.
  • مثال (منطق شبه ModSecurity):
    • إذا كانت REQUEST_URI أو أي معلمة REQUEST_BODY تحتوي على: (union.*select|information_schema|load_file\(|into\s+outfile|sleep\(|benchmark\() فقم بالحظر
• حظر الطلبات التي تتضمن رموز SQLi المعتمدة على التكرار الشائع:
  • الأنماط: ' أو '1'='1, " أو "1"="1, أو 1=1، إلخ.
• حظر الطلبات إلى نقاط النهاية المعروفة للإضافة:
  • إذا كانت الإضافة تعرض نقاط النهاية مثل /wp-admin/admin-ajax.php?action=aiwu_get_list أو مسار REST محدد، حظر أو تحديد معدل الوصول إلى تلك المسارات باستثناء من عناوين IP الموثوقة.
• تحديد معدل الطلبات لكل IP إلى نقاط نهاية الإضافة:
  • ستقوم الماسحات الآلية بمحاولة العديد من الحمولة. تحديد المعدل يبطئ وغالبًا ما يمنع الاستغلال الجماعي.

مهم: يجب اختبار قواعد WAF في وضع المراقبة أولاً (حيثما أمكن) لتقليل الإيجابيات الكاذبة. يوفر WP-Firewall قواعد جاهزة مصممة لـ WordPress ويمكن تطبيقها مباشرة.

---

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

# حظر مصطلحات SQLi الواضحة في سلسلة الاستعلام أو الجسم"

مرة أخرى: لا تقم بنسخ ولصق هذا في الإنتاج دون اختبار وضبط. يحتفظ WP-Firewall بقواعد مصممة ويقوم بشحنها لسياقات WordPress وسيقوم بتحديث القواعد مع تطور التهديد.

---

ممارسات الكود الآمن - كيف يجب إصلاح الإضافة

إذا كنت مطورًا يحافظ على كود الإضافة، فهذه هي الطريقة الصحيحة لتجنب حقن SQL في WordPress:

نمط ضعيف (زائف):

// لا تفعل هذا:;

نمط آمن باستخدام $wpdb->تحضير():

$param = isset($_GET['param']) ? $_GET['param'] : '';

للقيم الرقمية استخدم %d; للسلاسل استخدم %s. لاستعلامات LIKE استخدم esc_like() مدمج مع التحضير. لا تستخدم دمج السلاسل البسيط للقيم التي تأتي من إدخال المستخدم.

اتبع أيضًا هذه الممارسات الجيدة:

• تحقق من صحة الإدخال وتنظيفه مبكرًا (تحقق من النوع، قائمة القيم المسموح بها).
• استخدم الاستعلامات المعلمة ($WP4Twpdb->تجهيز).
• تجنب أسماء الجداول الديناميكية أو SQL الخام حيثما كان ذلك ممكنًا - استخدم واجهات برمجة تطبيقات WordPress.
• طبق فحوصات القدرة وnonces لنقاط نهاية AJAX أو REST الإدارية.
• حدد المخرجات وتجنب كشف أخطاء قاعدة البيانات الخام للعملاء.

---

قائمة التحقق من تنظيف ما بعد الاستغلال (إذا كنت تشك في الاختراق)

إذا كان لديك سبب للاعتقاد بأن موقعك كان مستهدفًا وقد تم اختراقه، فاتبع عملية دقيقة. إذا كان ذلك ممكنًا، اعمل مع محترف أمان أو مع مضيفك.

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

إذا لم تكن واثقًا من تنفيذ هذه الخطوات، فاستعن بخبير أمان موثوق به في WordPress.

---

توصيات تعزيز الأمان على المدى الطويل

لتقليل خطر ثغرات الإضافات التي قد تسبب حوادث كبيرة في المستقبل، نفذ هذه الممارسات الأفضل:

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

---

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

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

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

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

---

أمثلة على التوقيع والكشف (للمسؤولين عن المواقع والمضيفين)

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

• قيم المعلمات غير العادية التي تحتوي على كلمات رئيسية SQL: تطابق الطلبات حيث تحتوي المعلمات على رموز مثل اتحاد, INFORMATION_SCHEMA, SLEEP(, LOAD_FILE(، إلخ.
• معدل مرتفع من استجابات 400/403 تستهدف نقاط نهاية المكونات الإضافية من عناوين IP فردية.
• الطلبات إلى admin-ajax.php أو نقاط نهاية REST مع أحمال غير متوقعة تتطابق مع كلمات رئيسية SQL.
• أي طلبات تسبب أخطاء متكررة في قاعدة البيانات تم تسجيلها في سجلات التطبيق.

مرة أخرى، قم بضبط عتبات الكشف لتقليل الإيجابيات الكاذبة.

---

احمِ موقعك الآن - اشترك في خطة WP-Firewall Basic (مجانية)

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

• حماية أساسية: جدار ناري مُدار، عرض نطاق غير محدود، WAF، ماسح للبرامج الضارة، وتخفيف مخاطر OWASP Top 10.
• نشر سريع وتحديثات مستمرة لقواعد WAF عند نشر ثغرات جديدة.
• خيار بدون تكلفة للحفاظ على حماية موقعك أثناء تخطيط التحديثات، أو لاختبار قدرات الخدمة قبل الترقية إلى مستويات مدفوعة.

اشترك في خطة WP-Firewall المجانية وقم بتمكين قواعد WAF النشطة لحقن SQL AIWU: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

إذا كنت بحاجة إلى مزيد من الأتمتة والتحكم، فإن خططنا القياسية والمحترفة تضيف إزالة تلقائية للبرامج الضارة، والتحكم في القوائم السوداء/البيضاء لعناوين IP، والترقيع الافتراضي، وخدمة أمان مُدارة للحماية بدون تدخل.

---

ما يجب التواصل به إلى أصحاب المصلحة لديك

إذا كنت تدير مواقع لعملاء أو موظفين أو مستخدمين، اتبع خطوات التواصل الواضحة:

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

---

ملاحظات نهائية - العجلة والحذر

CVE-2026-2993 هو حقن SQL خطير وغير مصادق عليه يؤثر على مسارات الشيفرة المستخدمة على نطاق واسع في مكون AIWU الإضافي. سطح الهجوم واسع ومن المحتمل أن تزداد عمليات الفحص الآلي بعد الكشف العام. إذا كنت تدير مواقع WordPress تستخدم هذا المكون الإضافي، اعتبر هذا حادثة ذات أولوية عالية للتصحيح والتخفيف.

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

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

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

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