اسم البرنامج الإضافي	نشر تحديثات PublishPress
نوع الضعف	حقن SQL
رقم CVE	CVE-2026-32539
الاستعجال	عالي
تاريخ نشر CVE	2026-03-22
رابط المصدر	CVE-2026-32539

عاجل: ثغرة حقن SQL في تحديثات PublishPress (<= 3.7.23) — ما يجب على مالكي مواقع ووردبريس القيام به الآن

تم الكشف عن ثغرة حقن SQL عالية الخطورة (CVE-2026-32539) في مكون تحديثات PublishPress تؤثر على الإصدارات حتى 3.7.23 بما في ذلك. تم تصنيف هذه الثغرة بـ CVSS 9.3 وتسمح للمهاجمين غير المصرح لهم بحقن SQL في استعلامات قاعدة بيانات المكون. تم تصحيحها في الإصدار 3.7.24.

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

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

---

ملخص سريع (ما حدث)

• برمجة: تحديثات PublishPress (مكون ووردبريس)
• الإصدارات المتأثرة: <= 3.7.23
• الإصدار المصحح: 3.7.24
• نوع الثغرة: حقن SQL (OWASP A03: حقن)
• CVE: CVE-2026-32539
• سي في إس إس: 9.3 (عالية)
• الامتياز المطلوب: غير مصرح به (يمكن استغلاله دون تسجيل الدخول)
• مخاطرة: قراءة/تعديل كامل لقاعدة البيانات، احتمال الاستيلاء على الحساب، تسريب البيانات، أبواب خلفية دائمة مكتوبة في قاعدة البيانات، وهجمات متسلسلة.

إذا كنت تستطيع التحديث إلى 3.7.24 الآن — افعل ذلك. إذا لم تتمكن، اتبع خطوات التخفيف أدناه.

---

كيف يمكن أن تؤدي ثغرة حقن SQL في مكون ووردبريس إلى كسر موقعك

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

تشمل عواقب نجاح SQLi:

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

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

---

نمط ضعيف نموذجي والبديل الآمن (موجه للمطورين)

يبدو نمط غير آمن شائع هكذا (مبسط):

global $wpdb;

لماذا هذا غير آمن:

• $revision_id يأتي من إدخال المستخدم ($_GET) ويتم تضمينه مباشرة في سلسلة SQL.
• يمكن للمهاجم حقن حمولات SQL عبر revision_id المعلمة.

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

global $wpdb;

أفضل الممارسات:

• استخدم دائما $wpdb->تحضير() مع عناصر نائب (%d، %s، %f) للبيانات الخارجية.
• تحقق من الأنواع (إنتفال, قيمة عائمة) واستخدام wp_validate_boolean للقيم المنطقية.
• نتائج الهروب للإخراج (esc_html, esc_attr) بدلاً من الهروب للاستخدام في قاعدة البيانات.
• تجنب أسماء الجداول الديناميكية من مدخلات المستخدم؛ إذا لزم الأمر، تحقق من قائمة السماح.

---

لماذا تعتبر ثغرة PublishPress Revisions خطيرة بشكل خاص

• استغلال غير مصادق عليه: لا حاجة لتسجيل الدخول. يمكن لأي زائر أو روبوت محاولة الحقن.
• سطح واسع: غالبًا ما يكون التعامل مع المراجعات متاحًا للجمهور، وقد يقبل معلمات متنوعة عبر GET/POST، AJAX، أو نقاط نهاية REST.
• هدف ذو تأثير عالٍ: يمكن ربط المراجعات بالمحتوى وبيانات تعريف المستخدم - يمكن استخدام الوصول إلى بيانات المراجعة أو تعديلها لصياغة استغلالات إضافية.
• سرعة الاستغلال: تقوم الماسحات الآلية بسرعة بدمج توقيعات CVE المعروفة، لذا من المتوقع حدوث عمليات مسح واسعة النطاق ومحاولات استغلال.

---

علامات تشير إلى أن موقعك قد يكون تحت الهجوم

تحقق من المؤشرات التالية للاختراق (IOCs) والسلوك المشبوه:

• ارتفاعات غير عادية في حركة المرور إلى الموقع، خاصة على نقاط النهاية المتعلقة بإضافة المراجعات أو معلمات الاستعلام مثل revision_id, معرف المنشور, أو ما شابه ذلك.
• أخطاء 400/500 متكررة في سجلات الوصول التي تشير إلى ملفات الإضافات أو نقاط النهاية المخصصة.
• زيادة عدد محاولات تسجيل الدخول الفاشلة أو المستخدمين الجدد بمستوى إدارة في قاعدة البيانات.
• يختار استعلامات في السجلات تتضمن محتوى غير متوقع يشبه الحمولة أو تسلسلات طويلة من الأحرف الخاصة.
• تدهور أداء قاعدة البيانات أو استعلامات كبيرة وبطيئة تنشأ من جداول الإضافات.
• إدخالات جديدة مشبوهة في خيارات wp التي تشير إلى عناوين URL بعيدة، أو سلاسل eval/base64، أو كود غير معروف.
• تغييرات في نظام الملفات (ملفات PHP جديدة في دلائل التحميل، ملفات ثيم/إضافة معدلة).
• تنبيهات من الماسحات أو تقارير مزود الاستضافة حول أنماط SQL خبيثة.

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

---

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

إذا كنت تدير مواقع WordPress، اتبع هذه القائمة المرجعية ذات الأولوية:

1. قم بتحديث المكون الإضافي الآن
   • قم بتحديث PublishPress Revisions إلى الإصدار 3.7.24 أو أحدث. هذه هي أسرع وأضمن طريقة إصلاح.
2. إذا لم تتمكن من التحديث على الفور - قم بتطبيق تخفيفات مؤقتة:
   • قم بتعطيل إضافة PublishPress Revisions حتى تتمكن من اختبار التحديث بأمان.
   • إذا لم يكن من الممكن التعطيل، قم بتقييد الوصول إلى نقاط النهاية المعرضة للخطر باستخدام قواعد WAF، أو .htaccess، أو ضوابط الوصول على مستوى الخادم.
   • قم بحظر أنماط الإدخال المشبوهة (رموز SQL الخاصة) عند الحافة عبر جدار حماية تطبيق الويب الخاص بك.
3. قم بتطبيق تصحيح افتراضي مُدار
   • إذا كنت تستخدم جدار حماية/WAF يدعم التصحيح الافتراضي، قم بتمكين قاعدة لهذه الثغرة لحظر توقيعات الاستغلال المعروفة حتى تتمكن من التحديث.
4. قم بعمل نسخة احتياطية
   • قم بأخذ لقطة لقاعدة البيانات ونظام الملفات على الفور (قم بتخزينها في موقع خارجي). هذا يحافظ على الأدلة الجنائية ونقطة الاسترداد.
5. قم بتغيير أسرار WordPress
   • قم بتدوير كلمات مرور المسؤول ومفاتيح API إذا كنت تشك في وجود اختراق.
   • فرض إعادة تعيين كلمة المرور لجميع المسؤولين.
6. زيادة التسجيل والمراقبة
   • قم بتمكين تسجيل قاعدة البيانات وخادم الويب بالتفصيل (إذا لم يكن ذلك موجودًا بالفعل). راقب الوصول إلى ملفات الإضافة والاستعلامات المشبوهة أو معلمات POST.
7. قم بإخطار مزود الاستضافة أو شريك الأمان الخاص بك
   • قد يكون لديهم أدوات تخفيف ويمكنهم المساعدة في الاحتواء وجمع الأدلة الجنائية.

هذه هي خطوات الفرز - إنها تشتري الوقت وتقلل من المخاطر الفورية بينما تقوم بإجراء التحقيق والإصلاح.

---

كيفية التخفيف عندما لا يمكنك التحديث على الفور (خيارات تقنية)

• قواعد WAF / التصحيح الافتراضي:
  • حظر الطلبات التي تحتوي على رموز SQL مشبوهة في المعلمات التي تقبلها الإضافة (مثل، الفواصل المنقوطة، التعليقات --, /*, اتحاد, يختار, النوم, معيار) المستهدفة فقط لنقاط النهاية المستخدمة بواسطة PublishPress Revisions.
  • قم بتحديد معدل الطلبات المتكررة لهذه النقاط النهائية لتعطيل الماسحات الآلية.
• .قواعد .htaccess / nginx:
  • إذا كان المكون الإضافي يكشف عن ملف أو مسار معين، قم بتقييد الوصول بواسطة IP أو تطلب رمز سري (فقط على المدى القصير).
  • مثال: منع الوصول المباشر إلى مسارات ملفات المكون الإضافي من الخارج، أو توجيهها عبر وكيل للتحكم في الوصول.
• تعطيل نقاط نهاية REST/AJAX:
  • إذا كان الكود المعرض للخطر متاحًا عبر admin-ajax.php أو مسار REST يمكن للمستخدمين غير المصرح لهم الاتصال به، قم بتقييد أو إزالة الوصول العام إلى تلك المسارات مؤقتًا.
• إزالة المكون الإضافي من الإنتاج:
  • إذا كان موقعك يمكنه تحمل ذلك، قم بإزالة المكون الإضافي حتى يتم تطبيق التحديث واختباره.

ملحوظة: قواعد شاملة تمنع يختار أو اتحاد للموقع بالكامل يمكن أن تكسر الوظائف الشرعية. قم بتحديد نطاق القواعد بدقة لنقاط النهاية والمعلمات المحددة.

---

التحقق من علامات الاختراق الناجح (خطوات الطب الشرعي)

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

1. الحفاظ على الأدلة
   • قم بأخذ نسخ احتياطية فورية من قاعدة البيانات ونظام الملفات (نسخ وتخزين للقراءة فقط).
   • تصدير سجلات خادم الويب (الوصول + الخطأ) لفترة الوقت ذات الصلة.
2. ابحث عن مستخدمين جدد كمديرين
   • استعلام مستخدمو wp لحسابات بمستوى مدير تم إنشاؤها مؤخرًا (تحقق من created_at / user_registered).
   • افحص wp_usermeta من أجل تصعيد الأدوار.
3. البحث عن خيارات تم حقنها
   • تحقق خيارات wp لقيم مشبوهة، سلاسل base64 طويلة، أو إشارات إلى مجالات بعيدة في قيمة_الخيار.
4. فحص ملفات المكون الإضافي / السمة
   • ابحث عن تقييم(, فك تشفير base64, gzinflate, create_function, file_put_contents في دلائل الإضافات / السمات.
   • ابحث عن الملفات المعدلة مؤخرًا خارج أنماط التحديث العادية.
5. تحقق من دلائل التحميل والتخزين المؤقت
   • تفقد التحميلات/ وأي ذاكرة التخزين المؤقت/ دلائل لملفات PHP أو تنفيذية غير معروفة.
6. راجع استعلامات قاعدة البيانات في السجلات
   • حدد استعلامات SQL الشاذة التي لا تتطابق مع سلوك الموقع العادي.
7. أزل الأبواب الخلفية وقم بتدوير المفاتيح
   • إذا وجدت مؤشرات على الاختراق، قم بالحجر الصحي للموقع، وأزل الملفات والمدخلات الضارة، وقم بتدوير جميع الأسرار.
8. استعادة من نسخة احتياطية نظيفة إذا لزم الأمر
   • إذا كانت عملية الإصلاح واسعة أو غير مؤكدة، استعد إلى نسخة احتياطية معروفة جيدة قبل تاريخ الاستغلال، وطبق تصحيح الإضافة، ثم راقب.

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

---

إرشادات المطور: تصحيح الكود بأمان

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

• استبدل الاستعلامات المجمعة بـ $WP4Twpdb->تجهيز.
• تحقق من القيم الواردة وقم بتحويلها إلى الأنواع المتوقعة (مثل،, إنتفال للمعرفات).
• قم بإدراج قيم المعلمات في القائمة البيضاء حيثما كان ذلك مناسبًا (مثل، أسماء الإجراءات المسموح بها).
• تجنب استخدام قيم POST/GET غير المعقمة في ORDER BY، LIMIT، أو أسماء الجداول.
• استخدم فحوصات القدرة للعمليات الحساسة (current_user_can('edit_posts'), ، إلخ)، ولا تفترض أن التوجيه أو المصادقة في مكان آخر يمنع الوصول.

مثال: مقتطف غير آمن (لا تستخدم):

$where = "post_id = " . $_REQUEST['post_id']; // غير آمن;

إعادة كتابة آمنة:

$post_id = isset($_REQUEST['post_id']) ? intval($_REQUEST['post_id']) : 0;

• استخدم الرموز غير القابلة للتكرار وفحوصات القدرات للإجراءات التي تعدل البيانات.
• هرب والتحقق من المدخلات الشبيهة بالاسم باستخدام sanitize_title() وأسماء الخيارات باستخدام sanitize_key().

---

توصيات التقوية (طويلة الأجل)

لتقليل المخاطر عبر أسطول WordPress الخاص بك، اعتمد الضوابط التالية:

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

---

قائمة التحقق من الاستجابة للحوادث (خطوة بخطوة)

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

---

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

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

الحمايات الرئيسية التي نقدمها:

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

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

---

قم بتأمين موقعك في دقائق مع خطة WP-Firewall المجانية

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

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

جرب خطة WP-Firewall الأساسية مجانًا وأضف طبقة إضافية من الحماية أثناء تطبيق تحديثات البائع: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(ملاحظة: إذا كنت تدير مواقع لعملاء أو تتعامل مع أصول ذات قيمة عالية، فكر في خطط Standard أو Pro للتنظيف التلقائي والتقارير الشهرية.)

---

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

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

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

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

س: كم من الوقت تستغرق نشر التصحيحات الافتراضية لـ WAF؟
ج: بالنسبة للثغرات المعروفة عالية المخاطر، نهدف إلى دفع القواعد المضبوطة في غضون ساعات من التحقق. التصحيحات الافتراضية مؤقتة ويجب أن تتبعها تحديثات ملحق مناسبة.

---

كلمات أخيرة - العجلة، ولكن خطوات واضحة

تعتبر هذه الثغرة في حقن SQL في PublishPress Revisions خطرًا حقيقيًا وفوريًا لأنها يمكن أن تُفعل بدون مصادقة ويمكن أن تؤدي إلى اختراق كامل لقاعدة البيانات. الإجراء الأبسط والأكثر أمانًا هو تحديث الملحق إلى 3.7.24 الآن.

إذا لم تتمكن من التحديث فورًا:

• قم بتعطيل الملحق أو تطبيق قواعد WAF محددة بدقة لحظر محاولات الاستغلال.
• قم بعمل نسخة احتياطية آمنة، وزد من المراقبة، ودوّر الأسرار، وتحقق من مؤشرات الاختراق.

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

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

ابقَ يقظًا. قم بالتحديث بسرعة. عزز الأمان بشكل شامل.