| اسم البرنامج الإضافي | بروفايل غريد |
|---|---|
| نوع الضعف | ثغرة في التحكم بالوصول |
| رقم CVE | CVE-2026-2488 |
| الاستعجال | قليل |
| تاريخ نشر CVE | 2026-03-08 |
| رابط المصدر | CVE-2026-2488 |
عاجل: خلل في التحكم بالوصول في بروفايل غريد <= 5.9.8.1 — ما يجب على مالكي مواقع ووردبريس فعله الآن
تاريخ: 7 مارس 2026
CVE: CVE-2026-2488
خطورة: منخفض (CVSS 4.3) — خلل في التحكم بالوصول
كفريق أمان WP‑Firewall، قمنا بمراجعة ثغرة جديدة تم الكشف عنها تتعلق بالتحكم بالوصول المكسور الذي يؤثر على إضافة بروفايل غريد (الإصدارات <= 5.9.8.1). بينما يتم تصنيف شدة المشكلة علنياً على أنها “منخفضة”، فإن الخطأ يسمح لمستخدم مصدق لديه دور مشترك بتحفيز حذف الرسائل التي يجب ألا يكون قادراً على حذفها — وهي مشكلة تتعلق بالخصوصية والتوافر لمواقع المجتمع والعضوية. يشرح هذا المنشور السبب الجذري الفني على مستوى عالٍ، وسيناريوهات التأثير في العالم الحقيقي، والتخفيفات الفورية التي يمكنك تطبيقها اليوم (بما في ذلك قواعد WAF التي نوصي بها)، وخطوات تعزيز الأمان على المدى الطويل، وكيف يمكن لـ WP‑Firewall مساعدتك في حماية موقعك أثناء تصحيح المشكلة.
هذه المقالة مكتوبة من منظور مدافع عملي. نتجنب خطوات الاستغلال التفصيلية، لكننا نقدم إرشادات آمنة وقابلة للتنفيذ لمشرفي ومطوري ووردبريس.
الملخص التنفيذي (TL؛DR)
- ماذا: كانت إصدارات بروفايل غريد <= 5.9.8.1 تعاني من مشكلة في التحكم بالوصول المكسور التي قد تسمح لمشترك مصدق بحذف الرسائل التي يجب ألا يمتلكها.
- تأثير: حذف الرسائل (فقدان البيانات / خرق الخصوصية) للمجتمعات، ورسائل الملف الشخصي، ومواقع العضوية التي تستخدم رسائل بروفايل غريد.
- الإصلاح: قم بالترقية إلى بروفايل غريد 5.9.8.2 أو أحدث على الفور.
- إذا لم تتمكن من الترقية على الفور: قم بإلغاء تنشيط الإضافة أو تطبيق تخفيفات قصيرة الأجل (قاعدة WAF، قيود الدور، فحوصات الكود المؤقتة).
- مستخدمو WP‑Firewall يمكنهم تفعيل الحمايات الافتراضية، وقواعد WAF، والدفاعات الأخرى أثناء تصحيح المشكلة.
ماذا حدث — شرح الثغرة (بعبارات بسيطة)
المشكلة هي خلل كلاسيكي في التحكم بالوصول: نقطة نهاية خادم في الإضافة التي تحذف الرسائل فشلت في التحقق بشكل صحيح مما إذا كان المستخدم المسجل لديه إذن فعلي لحذف الرسالة المستهدفة. بدلاً من التحقق من الملكية (أو الدور/القدرة المناسبة)، كان الكود يتطلب فقط أن يكون المستخدم مصدقًا — وهو شرط منخفض يشمل حسابات المشتركين. ونتيجة لذلك، كان بإمكان مشترك مصدق تقديم طلب (عبر admin‑ajax.php، نقطة نهاية شبيهة بـ REST، أو إجراء الإضافة) يقدم معرف الرسالة ويتسبب في حذف الإضافة لتلك الرسالة بغض النظر عن من نشرها في الأصل.
مهم: هذه الكتابة لا تتضمن عمدًا تعليمات استغلال خطوة بخطوة. هدفنا هو مساعدة المشرفين على فهم المخاطر والتخفيف منها.
من هم المتضررون؟
- المواقع التي تعمل بإضافة بروفايل غريد بالإصدار 5.9.8.1 أو أقدم.
- المواقع التي تستخدم ميزات الرسائل الخاصة/العامة أو لوحة الرسائل المدمجة في بروفايل غريد.
- مواقع المجتمع أو العضوية أو الشبكات الاجتماعية التي تسمح بتسجيل الحسابات (بما في ذلك المشتركين) — لأن الخطأ يتطلب فقط المصادقة، وليس دورًا مرتفعًا.
- أي موقع حيث تمثل الرسائل المحذوفة بيانات تجارية أو بيانات مستخدم (سلاسل الدعم، الرسائل الخاصة، سجلات الاعتدال).
على الرغم من أن الثغرة ليست تنفيذ كود غير مصادق عليه عن بُعد، إلا أن عواقبها يمكن أن تكون كبيرة على المجتمعات المعتدلة وسير عمل دعم العملاء: محادثات تم العبث بها، فقدان الأدلة، ارتباك المستخدمين، وأضرار بالسمعة.
السبب الجذري الفني (مستوى عالٍ)
عادة ما تنشأ مشاكل التحكم في الوصول المكسور من فشل واحد أو أكثر من الفشل التالي؛ تظهر مشكلة ProfileGrid مجموعة فرعية من هذه الفشل:
- فحص القدرة المفقود: لم يستدعِ معالج حذف الرسائل الدالة current_user_can() أو فحص قدرة مخصص.
- فحص الملكية المفقود: لم يقارن الكود بين معرف المستخدم المسجل الدخول ومعرف مالك الرسالة قبل الحذف.
- حماية nonce / CSRF المفقودة: قد لا يكون قد تم التحقق من nonce ووردبريس في نقطة النهاية، مما يسمح بإنشاء طلبات مصادق عليها من جلسات/أدوات مصادق عليها أخرى.
- تعرض نقطة النهاية بشكل غير صحيح: كانت هناك إجراء أو نقطة نهاية REST تقبل وتتصرف بناءً على معلمة معرف الرسالة دون تحقق كافٍ.
نظرًا لأن الثغرة موجودة على مستوى التحكم في الوصول، يجب أن يكون المهاجم مستخدمًا مصادقًا عليه (مشترك أو أعلى). ليست مشكلة تنفيذ كود غير مصادق عليه عن بُعد، لكنها عيب منطقي له عواقب حقيقية.
سيناريوهات الهجوم الواقعية (ما يمكن أن يحققه المهاجم)
- يقوم مشترك خبيث أو مخترق بحذف رسائل مستخدمين آخرين (خاصة أو عامة)، مما يعطل المحادثات.
- يقوم المهاجم بحذف أدلة على الإساءة أو البريد العشوائي لإخفاء آثار الجريمة.
- يمكن لمهاجم منسق حذف الرسائل بشكل جماعي، مما يتسبب في فقدان البيانات وإجبار المسؤولين على الاستعادة من النسخ الاحتياطية.
- يمكن للمهاجمين تعطيل خيوط الدعم/المعاملات التي تعتبر حيوية للأعمال.
نظرًا لأن المشكلة تتطلب حسابًا مسجلاً، يحتاج المهاجم إما إلى إنشاء حساب مشترك (إذا كانت التسجيل في الموقع مفعلًا) أو أن يكون لديه حساب بالفعل. العديد من مواقع المجتمع تسمح بالتسجيل، لذا فإن هذا يمثل خطرًا عمليًا.
قائمة التحقق من الإجراءات الفورية (ماذا تفعل الآن - خطوة بخطوة)
- قم بتحديث ProfileGrid إلى 5.9.8.2 أو إصدار لاحق على الفور.
هذه هي الخطوة الأكثر أهمية. أصدرت الشركة المصنعة تصحيحًا؛ قم بتطبيقه من خلال إدارة ووردبريس الخاصة بك أو عبر CLI (wp plugin update). - إذا لم تتمكن من التحديث الآن، قم بإلغاء تنشيط المكون الإضافي مؤقتًا.
إذا كان المكون الإضافي يدعم ميزات غير حيوية، فإن إلغاء التنشيط يمنع المزيد من الإساءة. تذكر أن إلغاء التنشيط قد يغير سلوك الموقع؛ قم بأخذ النسخ الاحتياطية المناسبة. - قم بتطبيق تدابير WP-Firewall WAF (موصى به إذا لم تتمكن من التحديث على الفور).
- قم بحظر طلبات POST/GET للإجراءات المحددة للمكون الإضافي التي تقوم بالحذف (انظر إرشادات الكشف أدناه).
- رفض طلبات الحذف المقدمة من المستخدمين ذوي دور المشترك الذين يقومون بإجراءات حذف الرسائل.
- تحديد معدل الطلبات إلى نقاط نهاية الرسائل لمنع الحذف الجماعي.
- سجلات التدقيق وابحث عن نشاط الحذف المشبوه.
ابحث في سجلات الويب/الوصول وسجلات نشاط ووردبريس عن طلبات الحذف والشذوذ منذ آخر وقت معروف آمن. - استعادة أي رسائل حرجة محذوفة من النسخة الاحتياطية إذا كان ذلك ممكنًا.
إذا تمت إزالة بيانات مهمة، استعد من أحدث نسخة احتياطية نظيفة. - فرض ضوابط أقوى على المستخدمين.
إذا كنت تسمح بالتسجيل المفتوح، فكر في تعطيل التسجيلات مؤقتًا أو الانتقال إلى نموذج دعوة/موافقة حتى يتم تصحيح المشكلة. - مراقبة تقارير المستخدمين.
إبقاء دعم العملاء/المجتمعات على علم حتى يتمكنوا من الإبلاغ عن الرسائل المفقودة أو المحذوفة بسرعة.
كيفية اكتشاف الاستغلال (إرشادات السجل والتدقيق)
- ابحث في سجلات الخادم الخاصة بك عن طلبات إلى admin-ajax.php أو نقاط نهاية المكونات الإضافية التي تتضمن معرفات الرسائل (مثل، معلمات مثل message_id، msg_id، delete_message). ابحث عن طلبات POST من جلسات مصادق عليها.
- تحقق من مكون سجل النشاط الخاص بك (إذا كان موجودًا) عن إدخالات حذف الرسائل أو إجراءات المشترك غير العادية.
- إذا كان موقعك يخزن الرسائل في جدول محدد (مثل، wp_pg_messages أو ما شابه)، تحقق من أنماط الحذف الجماعي أو الفجوات في المعرفات.
- مراجعة الشكاوى الأخيرة من المستخدمين تسأل لماذا اختفت الرسائل.
- نصيحة الطب الشرعي: ربط طوابع حذف الوقت مع جلسات المستخدمين المصادق عليهم (كوكي أو IP) في سجلات الويب الخاصة بك للعثور على الحسابات المبدئية.
تخفيف الكود على المدى القصير (شيفرة آمنة ودفاعية)
إذا كنت مرتاحًا مع الكود ولا يمكنك تحديث المكون الإضافي على الفور، يمكنك إضافة مكون إضافي وقائي (مكون إضافي يجب استخدامه) أو شيفرة صغيرة في مكون إضافي مخصص تعترض محاولات الحذف المشبوهة وتمنعها ما لم يتم اجتياز فحص الملكية/القدرة المناسب.
أدناه هو نمط دفاعي مثال (شيفرة زائفة آمنة للإنتاج). أضفها كمكون إضافي يجب استخدامه (قم بإسقاطها في wp-content/mu-plugins/) حتى لا يمكن إزالتها بسهولة:
<?php
/*
Plugin Name: PG Temporary Deletion Guard (mu)
Description: Temporary guard to block unauthorized message deletion until ProfileGrid is updated.
Version: 1.0
Author: WP-Firewall
*/
add_action( 'init', function() {
// Only act on POST requests
if ( $_SERVER['REQUEST_METHOD'] !== 'POST' ) {
return;
}
// Example: block known action param used by the plugin. Adjust to your site's parameters.
$action = isset( $_POST['action'] ) ? sanitize_text_field( $_POST['action'] ) : '';
$message_id = isset( $_POST['message_id'] ) ? intval( $_POST['message_id'] ) : 0;
// If this looks like a message deletion request, perform ownership/capability checks
if ( $action === 'profilegrid_delete_message' && $message_id > 0 ) {
// Ensure user is logged in
if ( ! is_user_logged_in() ) {
wp_die( 'Unauthorized', 403 );
}
$current_user_id = get_current_user_id();
// Look up message author from DB (adjust table/column names to match your setup)
global $wpdb;
$table = $wpdb->prefix . 'profilegrid_messages'; // adjust as needed
$author_id = $wpdb->get_var( $wpdb->prepare( "SELECT user_id FROM {$table} WHERE id = %d", $message_id ) );
// Fail closed: only allow deletion if user owns the message or user has moderation capability
if ( intval( $author_id ) !== intval( $current_user_id ) && ! current_user_can( 'moderate_comments' ) ) {
// Prevent deletion
wp_die( 'Insufficient permissions to delete this message', 403 );
}
// Additional nonce check could be enforced if plugin emits a known nonce.
// if ( ! isset( $_POST['_wpnonce'] ) || ! wp_verify_nonce( $_POST['_wpnonce'], 'profilegrid_delete_nonce' ) ) {
// wp_die( 'CSRF check failed', 403 );
// }
}
}, 1 );
ملحوظات:
- الشيفرة أعلاه محافظة عمدًا (أنكر إذا كنت غير متأكد). قم بتعديل أسماء الجداول والأعمدة لتتناسب مع قاعدة بياناتك.
- تجنب تعديل ملفات النواة الخاصة بالملحقات مباشرة؛ فإن الملحقات المتعددة البقاء تنجو من التحديثات ولا يمكن تعطيلها من خلال واجهة إدارة المستخدم.
- هذه حل مؤقت. قم بتطبيق تصحيح البائع في أقرب وقت ممكن.
قواعد WAF الموصى بها (أنماط للحظر أو الفحص)
إذا كنت تدير WAF (سحابة أو ملحق)، أضف قواعد مستهدفة حتى لا تعطل عن غير قصد وظائف الموقع الأخرى:
- حظر أو تحدي (كابتشا) طلبات POST إلى قيم إجراء AJAX في ووردبريس التي تتطابق مع روتين حذف الملحق (مثل، action=profilegrid_delete_message). إذا كنت لا تعرف أسماء الإجراءات الدقيقة، تحقق من تتبع الشبكة عند إجراء حذف مشروع كمسؤول (بعد التصحيح) لالتقاط النمط.
- أنكر الطلبات حيث:
- طريقة HTTP = POST و
- URI تحتوي على /wp-admin/admin-ajax.php و
- المعامل message_id موجود و
- دور الجلسة (إذا كان معروفًا) يساوي مشترك (أو الطلب يأتي من وكيل مستخدم بدون ملف تعريف ارتباط إداري) - تحدى بدلاً من الحظر الكامل لتجنب الإيجابيات الكاذبة.
- قم بتحديد معدل طلبات حذف الرسائل المتكررة من نفس عنوان IP أو نفس جلسة المستخدم.
- إذا كان ذلك ممكنًا، تطلب رأس X-WP-Nonce صالح لنقاط نهاية الحذف وحظر الطلبات التي تفتقر إليه.
مهم: يجب اختبار قواعد WAF في بيئة الاختبار لضمان عدم كسر العمليات المشروعة.
الاسترداد: ماذا تفعل إذا تم حذف الرسائل
- حدد نطاق البيانات المحذوفة (أي الرسائل، أي المستخدمين، الإطار الزمني).
- استعد من نسخة احتياطية حديثة إذا كانت بيانات الرسائل حرجة. يفضل نسخة احتياطية جديدة قبل توقيت الحادث.
- إذا كان لديك سجلات معاملات قاعدة البيانات أو سجلات ثنائية (MySQL binlog)، فكر في استرداد النقطة الزمنية لاستعادة سجلات معينة.
- أبلغ المستخدمين المتأثرين (الشفافية تبني الثقة). أخبرهم بما حدث، وما قمت باستعادته، وما الخطوات التي اتخذتها لتأمين الموقع.
- قم بتقوية الموقع بعد ذلك: قم بتصحيح، تدوير كلمات مرور المسؤول، تدقيق الحسابات، إلغاء حسابات مشبوهة.
لماذا تم تصنيف الثغرة على أنها “منخفضة” - ولكن لماذا يجب أن تهتم بها
درجة CVSS للمشكلة منخفضة (4.3) لأن:
- يجب أن يكون المهاجم مصدقًا (لا استغلال عن بُعد غير مصدق).
- الثغرة لا تسمح بتنفيذ الشيفرة أو الاستيلاء الكامل على الموقع.
لكن “منخفض” لا يعني “غير مهم”. بالنسبة للمجتمعات النشطة والمواقع التي تكون فيها الرسائل حساسة (تذاكر الدعم، مناقشات العقود، مسارات الاعتدال)، فإن حذف الرسائل له دلالة: يمكن أن يمحو السجلات ويعيق العمليات. التصنيف يقلل من تأثير الأعمال في العالم الحقيقي في العديد من الحالات. تعامل معها بجدية.
تعزيز طويل الأمد والدروس المستفادة
استخدم هذه الحادثة لتحسين وضع أمان ووردبريس العام لديك:
- مبدأ أقل الامتيازات: حدد ما يمكن لكل دور القيام به. يجب أن تكون حقوق المشتركين في الحد الأدنى.
- تعزيز تدفق التسجيل: استخدم تأكيد البريد الإلكتروني، CAPTCHA، الموافقة اليدوية للأدوار التي يمكنها الوصول إلى ميزات المجتمع.
- فرض حماية CSRF وnonces على جميع نقاط النهاية التي تعدل الحالة.
- مراجعة ممارسات الإضافات من الطرف الثالث: تفضل البائعين الذين يستجيبون للأمان في الوقت المناسب ولديهم سجلات تغييرات شفافة.
- استخدام تسجيل النشاط والمراقبة التي تلتقط إجراءات المستخدمين (الحذف، تغييرات الأدوار).
- احتفظ بنسخة احتياطية موثوقة وعملية استعادة؛ اختبر الاستعادة بشكل دوري لضمان موثوقية النسخ الاحتياطية.
- استخدم WAF والتصحيح الافتراضي لتقليل فترة التعرض بين الكشف والتصحيح.
- تحديث تلقائي للتصحيحات الأمنية غير المكسورة حيثما كان ذلك عمليًا - ولكن اختبر في بيئة التجريب أولاً.
كيف يساعد WP-Firewall أثناء التصحيح
في WP-Firewall، نحمي مواقع ووردبريس باستخدام نهج متعدد الطبقات: قواعد جدار حماية مُدارة، جدار حماية تطبيقات الويب (WAF)، فحص البرمجيات الضارة، وخيارات استجابة عملية مصممة لمالكي المواقع الذين يحتاجون إلى حماية سريعة.
الميزات الرئيسية التي تساعد في حوادث مثل هذه:
- جدار حماية مُدار وWAF يمكنه نشر قواعد افتراضية تحظر نقاط النهاية المشبوهة للإضافات وتوقف حركة المرور الهجومية قبل أن تصل إلى التطبيق.
- ماسح البرمجيات الضارة وفحوصات السلامة لاكتشاف التلاعب.
- تدابير OWASP العشر العليا لتقليل طرق الهجوم الشائعة (بما في ذلك أنماط التحكم في الوصول المكسور عند اقترانها بقواعد التطبيق).
- قدرات التحديث التلقائي والترقيع الافتراضي المتاحة في الفئات الأعلى لتقليل نافذة التصحيح (انظر تفاصيل الخطة أدناه).
إذا كنت ترغب في حماية موقعك الآن وأثناء نافذة التصحيح الطارئة، نقدم خطة مجانية تغطي الحمايات الأساسية وتسمح لك بالحفاظ على أمان موقعك أثناء إجراء التحديثات واستعادة البيانات.
احمِ موقعك اليوم - جرب خطة WP‑Firewall المجانية
اشترك في خطة WP‑Firewall Basic (مجانية) على:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
لماذا تجرب الخطة المجانية؟
- حماية أساسية: جدار ناري مُدار، WAF، ماسح للبرمجيات الضارة، عرض نطاق غير محدود.
- التخفيف من مخاطر OWASP Top 10 خارج الصندوق.
- إعداد سهل وسريع لتقليل التعرض أثناء تحديث المكونات الإضافية مثل ProfileGrid.
- إذا كنت بحاجة إلى المزيد، قم بالترقية إلى Standard أو Pro لإزالة البرمجيات الضارة تلقائيًا، وقائمة سوداء/بيضاء لعناوين IP، وتقارير شهرية، وترقيع افتراضي تلقائي.
نظرة عامة على الخطة:
- الأساسي (مجاني): جدار حماية مُدار، نطاق ترددي غير محدود، WAF، ماسح للبرمجيات الضارة، تخفيفات OWASP Top 10.
- المعيار ($50/السنة): جميع ميزات Basic، بالإضافة إلى إزالة البرمجيات الضارة تلقائيًا وقائمة سوداء/بيضاء لعناوين IP (حتى 20 عنوان IP).
- برو ($299/السنة): جميع ميزات Standard، بالإضافة إلى تقارير أمان شهرية، وترقيع افتراضي تلقائي للثغرات (مفيد أثناء نوافذ التصحيح)، وإضافات متميزة (مدير حساب مخصص، تحسين الأمان، خدمات مُدارة).
احصل على طبقة الدفاع المجانية الآن: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
إرشادات المطور: تحقق من نقاط نهاية المكونات الإضافية وساهم بمسؤولية
إذا كنت مطور مكون إضافي أو مُدمج موقع:
- راجع كود المكون الإضافي لنقاط النهاية التي تقوم بأفعال مدمرة وتأكد من أنها:
- تحقق من nonces (wp_verify_nonce)؛;
- تحقق من current_user_can() مع القدرة أو الدور المناسب؛;
- تحقق من أن المستخدم المعتمد هو مالك المورد قبل تعديل/حذف الموارد؛;
- تعقيم وإثبات صحة جميع المدخلات.
- أضف اختبارات وحدات واختبارات تكامل للتحقق من التحكم في الوصول وفحوصات الملكية.
- اشترك في إشعارات أمان البائع واحتفظ ببيئة staging للتحديثات.
- إذا وجدت ثغرة، اتبع ممارسات الإفصاح المسؤول وتنسيق مع بائع المكون الإضافي.
التعليمات
س: لقد قمت بتحديث المكون الإضافي - هل لا يزال يتعين علي القيام بأي شيء؟
A: بعد التحديث إلى 5.9.8.2 (أو أحدث)، تأكد من التحقق من أن التحديث قد تم تطبيقه واختبر وظيفة الرسائل في بيئة الاختبار. تحقق من سجلات التدقيق للاستخدام غير المشروع السابق واستعد من النسخ الاحتياطية إذا لزم الأمر. إذا كنت قد قمت بتطبيق إضافات mu مؤقتة أو قواعد WAF، قم بإزالتها أو تعديلها بعد التحقق من التصحيح.
Q: هل يمكنني الاعتماد على جدار حماية فقط؟
A: WAF هو طبقة تخفيف قوية ويمكن أن تقلل بشكل كبير من التعرض، ولكن يجب أن تكمل - لا أن تحل محل - التصحيحات في الوقت المناسب. قم بتطبيق إصلاحات البائع في أقرب وقت ممكن.
Q: هل يجب أن أعيد تعيين كلمات مرور المستخدمين؟
A: إذا اكتشفت نشاطًا مشبوهًا أو حسابات مخترقة، قم بتدوير كلمات المرور وفرض المصادقة الثنائية للأدوار المرتفعة. كإجراء احترازي عام، شجع المستخدمين على استخدام كلمات مرور قوية وتمكين المصادقة متعددة العوامل حيثما أمكن.
أفكار ختامية
تذكّر أن ثغرات التحكم في الوصول المكسور مثل هذه تذكير بأن منطق التطبيق وفحوصات القدرة مهمة تمامًا مثل منع حقن SQL أو XSS. تعتمد مواقع المجتمع والعضوية على نزاهة محتوى المستخدم؛ حتى الثغرة ذات الدرجة المنخفضة نسبيًا يمكن أن تعطل العمليات وتضر بالثقة.
إجراء فوري: قم بتحديث ProfileGrid إلى 5.9.8.2 أو أحدث. إذا لم تتمكن من التحديث على الفور، استخدم التخفيفات قصيرة الأجل الموضحة أعلاه - قم بإلغاء تنشيط الإضافة، نشر قواعد WAF، أو إضافة إضافات mu مؤقتة - وتحقق من سجلاتك بحثًا عن علامات الاستخدام غير المشروع.
إذا كنت ترغب في الحصول على مساعدة في تنفيذ قواعد WAF، أو التصحيحات الافتراضية، أو الاستجابة للحوادث، يوفر WP-Firewall دعمًا عمليًا وخطط حماية مُدارة. ابدأ بالخطة المجانية لوضع طبقة حماية حول موقعك أثناء التصحيح:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
ابق آمنًا - نحن هنا لمساعدتك في الدفاع عن مواقع WordPress الخاصة بك.
