اسم البرنامج الإضافي	مدير الحضور
نوع الضعف	حقن SQL
رقم CVE	CVE-2026-3781
الاستعجال	عالي
تاريخ نشر CVE	2026-04-08
رابط المصدر	CVE-2026-3781

عاجل: حقن SQL للمشتركين المعتمدين في مدير الحضور (<= 0.6.2) — ما يجب على مالكي مواقع ووردبريس القيام به الآن

TL;DR
تم العثور على ثغرة حقن SQL عالية الخطورة (CVE-2026-3781، CVSS 8.5) في إصدارات مكون مدير الحضور لووردبريس <= 0.6.2. يمكن لمهاجم لديه وصول بمستوى مشترك فقط تقديم قيمة خبيثة لـ attmgr_off المعلمة والتسبب في تنفيذ SQL عشوائي ضد قاعدة بيانات ووردبريس الخاصة بك. يمكن أن يؤدي ذلك إلى سرقة البيانات، وخرق الحسابات، والاستيلاء الكامل على الموقع. إذا كنت تستخدم هذا المكون، فاتبع على الفور خطوات التخفيف والتقوية أدناه. إذا لم تتمكن من تحديث أو إزالة المكون على الفور، فقم بتطبيق حماية متعددة الطبقات — بما في ذلك تصحيح افتراضي عبر WAF — لمنع محاولات الاستغلال.

كفريق أمان WP‑Firewall، نعتبر هذا حادثًا عالي الأولوية ونوصي باتخاذ إجراء فوري لجميع المواقع المتأثرة.

---

حقائق سريعة

• البرنامج المتأثر: مكون مدير الحضور لووردبريس
• الإصدارات المعرضة للخطر: <= 0.6.2
• الثغرة: حقن SQL المعتمد (مشترك+) عبر attmgr_off المعلمة
• CVE: CVE-2026-3781
• الخطورة: عالية (CVSS 8.5)
• الامتياز المطلوب: مشترك (امتياز منخفض) — أي مستخدم معتمد بمستوى مشترك أو أعلى يمكنه تفعيلها
• تم الإبلاغ: 8 أبريل 2026

---

ما أهمية ذلك

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

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

نظرًا لما سبق، اعتبر هذه الثغرة حرجة من أجل الإصلاح ذي الأولوية.

---

ملخص تقني (ما يحدث)

على مستوى عالٍ، يقبل المكون الإضافي معلمة HTTP تُسمى attmgr_off ويستخدم لاحقًا قيمتها في استعلام قاعدة بيانات دون تطهير كافٍ أو عبارات مُعدة مسبقًا. هذا يعني أن المهاجم يمكنه صياغة بيانات لتلك المعلمة تغير منطق SQL (مثل، حقن عبارات SQL إضافية، استعلامات UNION، أو استعلامات فرعية).

تشمل الأنماط الضعيفة النموذجية في PHP/WordPress:

• تمرير إدخال المستخدم غير المُطهر مباشرةً إلى سلسلة SQL، على سبيل المثال:
  • $wpdb->get_results( "SELECT ... WHERE off = $attmgr_off" );
• الفشل في استخدام $wpdb->تحضير() أو العبارات المُعدة مسبقًا قبل تنفيذ وظائف الاستعلام.
• افتراض أن المعلمة الرقمية ستكون دائمًا رقمية وعدم التحقق منها بدقة (مثل، استخدام intval() حيثما كان ذلك مناسبًا).

عندما يتدفق الإدخال غير المُراقب إلى استعلام SQL، يمكن للمهاجم تغيير دلالات الاستعلام واستخراج أو تعديل البيانات التي لم يكن التطبيق ينوي كشفها.

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

---

التأثير المحتمل

إذا تم استغلالها، يمكن للمهاجم أن:

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

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

---

كيفية اكتشاف محاولات الاستغلال المحتملة

تشمل العلامات التي قد تشير إلى أن موقعًا ما قد تم استهدافه أو تم استغلاله بنجاح:

• ارتفاعات غير عادية في نشاط قاعدة البيانات أو استعلامات SQL طويلة ومعطوبة في سجلات الاستضافة أو قاعدة البيانات الخاصة بك.
• مستخدمو المسؤولين الجدد غير المعروفين في ووردبريس (تحقق من wp_users و wp_usermeta للمدخلات غير المتوقعة).
• تغييرات غير متوقعة في خيارات الإضافات أو السمات (تحقق من wp_options للقيم الغريبة أو الحمولة المسلسلة).
• طلبات HTTP مشبوهة إلى نقاط النهاية تحتوي على attmgr_off أو إلى نقاط نهاية الإضافة، خاصة حيث تحتوي قيمة المعامل على كلمات SQL الرئيسية (SELECT، UNION، INFORMATION_SCHEMA، إلخ) أو علامات تعليق SQL (/*, --).
• سجلات WAF أو الخادم التي تظهر طلبات تحتوي على أحرف ميتا SQL في معلمات GET/POST.
• Webshells أو ملفات تم تعديلها بعد فترة وجيزة من الطلبات الشاذة.

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

---

خطوات فورية يجب على كل مالك موقع اتخاذها (ترتيب موصى به)

1. إذا أمكن، ضع الموقع في وضع الصيانة وقيّد الوصول العام أثناء التحقيق. هذا يقلل من التعرض الإضافي.
2. تعطيل البرنامج الإضافي مؤقتًا (مدير الحضور) حتى يتوفر إصدار مصحح أو حتى تتمكن من التحقق من التكوين الآمن. هذه هي أسرع وسيلة مؤقتة.
3. إذا لم تتمكن من تعطيل الإضافة, ، طبق قواعد WAF (تصحيح افتراضي) لحظر الطلبات التي تحاول استغلال attmgr_off المعامل (انظر إرشادات WAF أدناه). هذه مجرد تخفيف مؤقت.
4. قم بمراجعة وإزالة حسابات المشتركين غير الموثوق بهم وحسابات أخرى ذات امتيازات منخفضة تم إنشاؤها مؤخرًا دون تحقق.
5. تدوير بيانات الاعتماد الحساسة:
   • قم بتغيير كلمات مرور مسؤولي ووردبريس وتمكين كلمات مرور قوية وفريدة.
   • إذا كان حساب مستخدم قاعدة البيانات مشتركًا أو يُشتبه في تعرضه للاختراق، قم بتدوير بيانات اعتماد قاعدة البيانات وتحديثها wp-config.php وفقًا لذلك (تنسيق مع مزود الاستضافة).
   • قم بتدوير أي مفاتيح API أو رموز مخزنة في قاعدة البيانات أو في إعدادات الإضافة.
6. البحث عن مؤشرات الاختراق:
   • قم بتشغيل فحص كامل للبرامج الضارة وسلامة النظام (نظام الملفات وقاعدة البيانات).
   • تحقق من توقيتات الملفات المتغيرة، وملفات PHP غير المعروفة، أو المهام المجدولة (مدخلات cron).
   • راجع التغييرات الأخيرة على دليل التحميلات، والسمات، ومجلدات الإضافات.
7. استعد من نسخة احتياطية معروفة جيدة إذا أكدت الاختراق ولا يمكنك إزالة العناصر الضارة بثقة؛ تجنب إعادة تقديم الإضافة المعرضة للخطر حتى يتم تصحيحها أو التخفيف منها بالكامل.
8. سجلات المراقبة راقب عن كثب محاولات التكرار وقم بتحديث جدول الحوادث الخاص بك.
9. قم بتطبيق التصحيح الرسمي بمجرد أن يطلق مؤلف الإضافة إصدارًا مصححًا. تحقق من سجل تغيير تحديث الإضافة وتأكد من معالجة الثغرة (على سبيل المثال، استخدام العبارات المعدة، والتحقق من attmgr_off).

---

التخفيفات الموصى بها من WP‑Firewall (التصحيح الافتراضي والتكوين)

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

أدناه توجد إرشادات وقواعد أمثلة يمكنك تعديلها. تهدف هذه إلى حظر محاولات SQLi النموذجية التي تستهدف attmgr_off المعامل مع تقليل الإيجابيات الكاذبة.

إرشادات مهمة عند كتابة قواعد WAF:

• ركز على اسم المعامل attmgr_off, ، لأن الثغرة محددة بالمعامل.
• استخدم مطابقة الأنماط غير الحساسة لحالة الأحرف.
• حظر القيم التي تحتوي على أحرف تحكم SQL والكلمات الرئيسية المدمجة مع استخدام المعامل (على سبيل المثال، UNION، SELECT، INFORMATION_SCHEMA، –، /*، ;).
• استخدم تحديد المعدل والحظر السلوكي لمحاولات ضارة متكررة من عناوين IP واحدة.

مثال (مفاهيمي) مقتطف قاعدة ModSecurity (للمسؤولين ذوي الخبرة):

# حظر قيم المعامل attmgr_off المشبوهة التي تحتوي على أحرف أو كلمات رئيسية SQL"

يمكن لقواعد Nginx (Lua أو WAF آخر) أو Cloud WAF استخدام فحوصات regex المعادلة. الجوهر: حظر الطلبات حيث يحتوي attmgr_off المعامل على كلمات رئيسية لعمليات SQL أو منهيات/تعليقات البيانات.

إذا كنت تفضل نهجًا أخف لتجنب الإيجابيات الكاذبة:

• حظر attmgr_off القيم التي تحتوي على أحرف غير رقمية بالكامل إذا كانت التطبيق يتوقع فقط إزاحات رقمية. قاعدة الأرقام الصارمة فقط فعالة جدًا ومنخفضة المخاطر.

مثال: السماح فقط بالأرقام (آمن وموصى به إذا attmgr_off يجب أن تكون رقمية):

# السماح فقط بالأرقام في attmgr_off"

ملحوظات:

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

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

---

توصيات تعزيز الأمان (بجانب التخفيف الفوري)

1. مبدأ أقل الامتيازات لمستخدمي WordPress
   إعادة النظر فيما إذا كنت بحاجة إلى تسجيل المشتركين المفتوح. حيثما كان ذلك ممكنًا، قم بتقييد إنشاء حسابات المشتركين أو تطلب التحقق من البريد الإلكتروني وموافقة المسؤول للحسابات الجديدة.
2. امتيازات قاعدة البيانات
   يستخدم WordPress بشكل افتراضي حساب مستخدم DB بامتيازات واسعة. حيثما كان ذلك ممكنًا، قم بتقييد امتيازات مستخدم قاعدة البيانات إلى ما يحتاجه WordPress فقط (SELECT، INSERT، UPDATE، DELETE). ملاحظة: بعض الإضافات تتطلب امتيازات إضافية، لذا اختبر التغييرات في بيئة الاختبار قبل الإنتاج.
3. استخدم أفضل ممارسات التطوير الآمن للشفرة المخصصة
   • دائمًا تحقق من صحة وتنظيف جميع مدخلات المستخدم. يفضل استخدام القوائم البيضاء (مثل، الأرقام فقط) بدلاً من القوائم السوداء.
   • يستخدم $wpdb->تحضير() أو العبارات المعدة لتجنب دمج سلاسل الاستعلام مع مدخلات غير موثوقة.
   • قم بتحويل والتحقق من المدخلات الرقمية باستخدام intval() أو فحوصات النوع الصارمة.
4. استخدام الإضافات بأقل امتيازات
   قم بتثبيت وتفعيل الإضافات التي تثق بها فقط، وقم بمراجعة استخدام الإضافات بشكل دوري. قم بإزالة الإضافات والسمات غير المستخدمة.
5. النسخ الاحتياطي المنتظم وخطة الاسترداد المختبرة
   احتفظ بنسخ احتياطية متكررة واختبر الاستعادة. تأكد من تخزين النسخ الاحتياطية في موقع خارجي وأن تكون غير قابلة للتغيير إن أمكن.
6. المراقبة والتنبيه
   قم بتمكين تسجيل الأحداث الحرجة، واضبط تنبيهات للنشاط المشبوه (إنشاء مسؤول غير متوقع، استعلامات قاعدة بيانات غير عادية)، وراقب سجلات الأخطاء.
7. الدفاع في العمق
   استخدم WAF + تدابير أمان المضيف + أفضل ممارسات دليل تقوية ووردبريس (أملاح فريدة، أذونات الملفات، تعطيل تحرير الملفات، مصادقة آمنة).
8. اختبار الأمان ومراجعة الشيفرة
   إذا كنت تحافظ على المكونات الإضافية أو السمات، قم بتضمين اختبار الأمان ومراجعة الشيفرة في دورة إصدارك. التحليل الثابت والاختبار الديناميكي يكتشفان العديد من المشكلات مبكرًا.

---

كيفية التحقق من فعالية التخفيف دون تعريض موقعك للخطر

• ضع قاعدة WAF في وضع الكشف/التسجيل أولاً وقدم حمولة اختبار غير ضارة إلى attmgr_off المعامل (على سبيل المثال، سلسلة تحتوي على كلمة SQL في بيئة تجريبية فقط). تحقق من أن القاعدة تشير إلى الطلب. لا تقم بتنفيذ استغلالات نشطة ضد الإنتاج.
• بعد تأكيدك أن WAF يشير إلى الاختبار، انتقل بالقاعدة إلى وضع الحظر.
• أكد وظيفة المكون الإضافي العادية للمشتركين الشرعيين (على سبيل المثال، قم بإجراء إجراء اختبار للمشترك) لضمان عدم تأثير الإيجابيات الكاذبة على سير العمل الأساسي.
• راجع السجلات لمحاولات الحظر وأضف عناوين IP إلى القوائم السوداء للمخالفين المتكررين.

---

قائمة مراجعة استجابة الحوادث (إذا كنت تعتقد أنك تعرضت للاختراق)

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

---

لماذا تعتبر جدار الحماية المدارة والتصحيح الافتراضي المستمر مهمين

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

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

بصفتنا ممارسين في مجال الأمن، نوصي بالجمع بين: تطبيق التصحيحات الافتراضية بسرعة، ثم تطبيق تصحيحات البائع وتعزيز الموقع كحل دائم.

---

أفضل الممارسات للمطورين (منع حقن SQL في ووردبريس)

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

• استخدم الاستعلامات المعدة: $wpdb->تحضير() لبناء SQL بأمان.
• تحقق من المدخلات حسب النوع والتنسيق. إذا كان يجب أن يكون المعامل عددًا صحيحًا، قم بتحويله والتحقق منه بشكل صريح.
• تجنب بناء SQL عن طريق التراص. لا تقم أبدًا بإدخال مدخلات المستخدم الخام في سلاسل SQL.
• استخدم واجهات برمجة التطبيقات الخاصة بووردبريس حيثما أمكن (مثل WP_Query، get_posts) التي تتعامل مع الهروب وتقلل من استخدام SQL الخام.
• استخدم الاستعلامات المعلمة أو طبقة ORM للعمليات المعقدة.
• أضف اختبارات وحدات واختبارات تكامل تتضمن حالات اختبار سلبية (مدخلات مشوهة، محاولات حقن كلمات SQL).
• قم بإجراء مراجعات شيفرة الأمان واختبار أمان التطبيقات الثابتة (SAST) كجزء من خط أنابيب CI/CD الخاص بك.

---

قواعد المراقبة والكشف الموصى بها

1. أضف هذه القواعد المراقبة إلى سجلات الأمان الخاصة بك حتى يتم اكتشاف الهجمات المحتملة بسرعة: attmgr_off 2. تنبيه عند احتواء الطلب على

• 3. معلمات تحتوي على أحرف غير رقمية. attmgr_off 4. تنبيه عند حدوث زيادة مفاجئة في الطلبات إلى نقاط نهاية المكونات الإضافية التي تتضمن.
• 5. اكتشاف الأنماط مع كلمات SQL الرئيسية داخل معلمات GET/POST (SELECT، UNION، INFORMATION_SCHEMA، إلخ) - توليد تنبيهات عالية الأولوية. attmgr_off.
• 6. ربط تلك التنبيهات بإنشاء حسابات مسؤول جديدة أو تعديلات على.
• 7. السجلات هي شريان الحياة للاستجابة للحوادث. تأكد من الاحتفاظ بها مركزيًا والاحتفاظ بها لفترة كافية للتحقيق الجنائي. خيارات wp.

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

---

أفكار ختامية

9. إذا كان موقعك يعمل بمكون Attendance Manager الإضافي (<= 0.6.2)، اعتبر هذا الأمر مسألة معالجة عاجلة: قم بتصحيح أو إزالة المكون الإضافي، وقم بتقوية موقعك، وطبق تخفيف WAF حتى يتم إصلاح المكون الإضافي والتحقق منه.

10. كما هو الحال دائمًا، حافظ على خطة نسخ احتياطي واستعادة، وراقب السجلات بحثًا عن سلوك غير طبيعي.

11. احمِ موقعك الآن - خطة WP‑Firewall المجانية (حماية أساسية).

---

12. نحن نفهم أن العديد من مالكي المواقع يحتاجون إلى حماية سريعة وموثوقة دون تعقيد تكوين القواعد يدويًا. تقدم WP‑Firewall خطة أساسية (مجانية) مصممة لتوفير حماية أساسية، دائمًا مفعلة لمواقع ووردبريس. إليك لماذا يختار العديد من مالكي المواقع الخطة المجانية كطبقة دفاعهم الأولى:

13. جدار ناري مُدار مع قواعد WAF يتم صيانتها بواسطة خبراء الأمن

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

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

https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

---

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