اسم البرنامج الإضافي	تقويم الأحداث
نوع الضعف	حقن SQL غير مصادق عليه
رقم CVE	CVE-2025-12197
الاستعجال	عالي
تاريخ نشر CVE	2025-11-05
رابط المصدر	CVE-2025-12197

إشعار أمني عاجل: تقويم الأحداث (WP) — حقن SQL غير مصادق عليه (CVE-2025-12197)

إشعار أمان WP-Firewall ودليل التخفيف

ملخص: تم نشر ثغرة حرجة في حقن SQL غير مصادق عليه تؤثر على إصدارات مكون تقويم الأحداث في ووردبريس من 6.15.1.1 إلى 6.15.9 (CVE-2025-12197). أطلق المطور إصدارًا مصححًا 6.15.10. تصنيف CVSS: 9.3 (مرتفع). نظرًا لأن الثغرة غير مصادق عليها وتؤثر على مكون مستخدم على نطاق واسع، قد يتم أتمتة الاستغلال واستهدافه بشكل جماعي. يشرح هذا الإشعار المخاطر، والتخفيفات الفورية وطويلة الأجل، وإرشادات الكشف، وخطوات الاستجابة للحوادث من منظور فريق أمان وجدار حماية ووردبريس محترف.

---

جدول المحتويات

• ماذا حدث (على مستوى عال)
• لماذا هذا مهم لمالكي مواقع ووردبريس
• ما هو حقن SQL غير مصادق عليه؟
• الإصدارات المتأثرة والإصدار المصحح
• إجراءات فورية (الـ 60-120 دقيقة الأولى)
• التخفيفات الموصى بها عندما لا يمكنك تصحيح المشكلة على الفور
• كيفية اكتشاف محاولات أو استغلال ناجح
• خطوات الطب الشرعي والاسترداد إذا كنت تشك في الاختراق
• تعزيز طويل الأجل والوقاية
• قائمة مراجعة سريعة (قابلة للطباعة)
• احصل على حماية مُدارة فورية مع WP-Firewall (الخطة المجانية) — سجل الآن
• الملحق: أوامر ومراجع WP-CLI المفيدة

---

ماذا حدث (على مستوى عال)

تم اكتشاف ثغرة حقن SQL عالية الخطورة في مكون تقويم الأحداث لووردبريس. تسمح الثغرة لمهاجم غير مصادق عليه بحقن SQL عبر مدخلات تتم معالجتها بواسطة المكون (تم الإبلاغ عنها ضد معلمة تُسمى عادةً س, ، وهي معلمة بحث/استعلام). توجد الثغرة في الإصدارات من 6.15.1.1 إلى 6.15.9 وتم إصلاحها في الإصدار 6.15.10.

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

---

لماذا هذا مهم لمالكي مواقع ووردبريس

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

---

ما هو حقن SQL غير مصادق عليه؟

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

تشمل التأثيرات المحتملة:

• قراءة بيانات حساسة (بريد المستخدمين الإلكتروني، كلمات المرور المشفرة، مفاتيح API، بيانات الدفع المخزنة في قاعدة البيانات)
• إنشاء أو تعديل مستخدمي إدارة ووردبريس
• حقن محتوى دائم/أبواب خلفية في المشاركات أو الخيارات التي تسمح بالوصول المستقبلي
• حذف أو إفساد البيانات
• في بعض إعدادات قاعدة البيانات، تنفيذ أوامر SQL إدارية تؤدي إلى مزيد من التهديد

---

الإصدارات المتأثرة والإصدار المصحح

• معرض للخطر: مكون أحداث التقويم — الإصدارات 6.15.1.1 حتى 6.15.9
• تم الإصلاح في: 6.15.10
• CVE: CVE-2025-12197
• ائتمان الاكتشاف: الباحث المعتمد (الإفصاح العام)

إذا كان موقعك يعمل بإصدار معرض للخطر، يجب عليك اتخاذ إجراء على الفور.

---

إجراءات فورية (الـ 60-120 دقيقة الأولى)

اتبع هذه التسلسل ذي الأولوية. لا تتخطى الخطوات — كلما تصرفت بسرعة، كان الخطر أقل.

1. تحقق من إصدار المكون (سريع)
   • لوحة التحكم: إدارة ووردبريس > المكونات > المكونات المثبتة > مكون أحداث التقويم
   • WP-CLI: wp plugin list --status=active | grep the-events-calendar
2. إذا كنت تستطيع التحديث على الفور، قم بالتحديث إلى 6.15.10 (موصى به)
   • واجهة الإدارة: المكونات > تحديث الآن لمكون أحداث التقويم
   • WP-CLI: wp plugin update the-events-calendar --version=6.15.10
3. إذا لم تتمكن من التحديث على الفور، قم بإلغاء تنشيط المكون مؤقتًا
   • واجهة الإدارة: المكونات > إلغاء التنشيط (إذا كانت الوظائف مقبولة للتعطيل)
   • WP-CLI: wp plugin deactivate the-events-calendar
   • إذا كانت الإضافة تدعم وظائف حيوية ولا يمكن تعطيلها، انتقل إلى خيارات التخفيف أدناه (قواعد WAF، تقييد الوصول).
4. ضع الموقع في وضع دفاعي أعلى
   • قم بتمكين قواعد WAF التي تحظر أنماط SQLi ضد الطلبات التي تستهدف نقاط نهاية الحدث/البحث ومعلمات الاستعلام (التفاصيل أدناه).
   • فرض تحديد المعدل وحظر عناوين IP المشبوهة.
5. قم بعمل نسخة احتياطية (قاعدة البيانات + الملفات) قبل إجراء التغييرات
   • أنشئ نسخة غير متصلة الآن - قد تكون مطلوبة للتحليل الجنائي.
6. راقب السجلات والتنبيهات عن كثب
   • زيادة verbosity السجلات حيثما أمكن، والحفاظ على السجلات خارج المضيف.

---

التخفيفات الموصى بها عندما لا يمكنك تصحيح المشكلة على الفور

إذا لم يكن تحديث الإضافة الفوري ممكنًا (مخاوف التوافق، متطلبات المرحلة، إلخ)، قم بتطبيق ضوابط تعويضية لتقليل التعرض.

1. التصحيح الافتراضي عبر جدار حماية تطبيق الويب (WAF)
   • نشر قاعدة لحظر مؤشرات SQL المشبوهة في معلمات الاستعلام المستخدمة من قبل الإضافة (على سبيل المثال، المعلمة المسماة عادةً س).
   • يجب أن تكون القاعدة مرنة بما يكفي لتجنب تعطيل الأعمال ولكن صارمة بما يكفي لالتقاط أنماط الحقن (انظر قسم إرشادات القاعدة أدناه).
   • التصحيح الافتراضي يشتري الوقت حتى تتمكن من تثبيت الإصلاح العلوي.
2. حظر أو تقييد الوصول إلى نقاط النهاية التي تقبل س أو معلمات استعلام مشابهة
   • إذا كانت الإضافة تعرض نقطة بحث أو نقطة نهاية REST محددة، قم بتقييد الوصول حسب IP (فقط للمسؤولين) أو تطلب رمزًا للبحث.
   • مثال: استخدم تكوين الخادم (nginx/Apache) لرفض الطلبات التي تحتوي على سلاسل استعلام معينة من الوصول العام ما لم تكن قادمة من عناوين IP موثوقة.
3. تعزيز مؤقت عبر .htaccess / قواعد الخادم

   # حظر أنماط حقن SQL البسيطة في سلسلة الاستعلام
   

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

4. تحديد معدل الطلبات وتصنيف سمعة IP
   • تحديد عدد الطلبات في الثانية/الدقيقة لنقاط نهاية البحث.
   • حظر أو تحدي (CAPTCHA) الطلبات المتكررة التي تضرب نفس نقطة النهاية بأنماط حمولة مشبوهة.
5. الحد الأدنى من الامتيازات لمستخدم قاعدة البيانات
   • تأكد من أن مستخدم قاعدة بيانات WordPress الخاص بك ليس لديه امتيازات أكثر من اللازم. قم بإزالة SUPER وFILE أو أي أذونات مرتفعة أخرى إذا كانت موجودة. عادةً ما تحتاج WordPress إلى SELECT وINSERT وUPDATE وDELETE وCREATE وALTER وINDEX.
   • تقييد الوصول إلى قاعدة البيانات فقط لمضيف خادم الويب.
6. إزالة أو عزل نموذج البحث العام مؤقتًا
   • إذا كانت سمة موقعك أو موقعك يستخدم بحثًا عامًا يستعلم عن المكون الإضافي، فكر في إخفاء النموذج مؤقتًا أو استبداله بصفحة نتائج مخزنة على الخادم.

---

إرشادات قواعد WAF (أفضل الممارسات للتصحيح الافتراضي)

بصفتها بائع WAF وفريق أمان، توصي WP-Firewall بنهج كشف متعدد الطبقات:

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

منطق القاعدة المقترح (كود زائف - قم بضبطه واختباره قبل النشر):

• إذا كانت مسار الطلب يتطابق مع نقاط نهاية المكون الإضافي (على سبيل المثال، يحتوي على /events/ أو نقاط نهاية AJAX/REST المعروفة للمكون الإضافي) أو يتطابق المحيل مع صفحات الموقع حيث يتم استخدام بحث المكون الإضافي، إذن:
• إذا كان معلمة الاستعلام س (أو أي معلمة استعلام) تحتوي على كليهما:
• كلمة SQL رئيسية (مطابقة غير حساسة لحالة SELECT|UNION|INSERT|UPDATE|DELETE|DROP|INFORMATION_SCHEMA) و
• حرف ميتا SQL أو تعليق (--, ;, /*, */, ' أو ", xp_),
• ثم قم بحظر أو تحدي باستخدام CAPTCHA (أعطِ المستخدمين الشرعيين فرصة لإثبات أنهم بشر).

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

---

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

الكشف أمر حاسم قبل وبعد الحادث. ابحث عن هذه الإشارات:

1. سجلات خادم الويب / سجلات الوصول
   • طلبات GET/POST إلى صفحات الأحداث أو نقاط نهاية البحث التي تحتوي على كلمات SQL الرئيسية، أو تعليقات، أو سلاسل مشفرة طويلة في سلاسل الاستعلام.
   • زيادة مفاجئة في الطلبات إلى نفس نقطة النهاية من نفس نطاق IP.
2. سجلات التطبيق وتنبيهات WAF
   • تطابق قواعد WAF مع أنماط SQLi، خاصة الطلبات غير المصرح بها.
   • استجابات متكررة 400/403/500 حول نفس الطابع الزمني.
3. شذوذات قاعدة البيانات
   • تغييرات غير متوقعة على wp_users، wp_usermeta (حسابات مسؤول جديدة، تغييرات في قدرات الدور).
   • صفوف جديدة أو تعديلات على الجداول التي تديرها إضافة تقويم الأحداث.
   • زيادة غير متوقعة في نشاط قراءة قاعدة البيانات أو استعلامات طويلة الأمد (غالبًا ما يستخدم المهاجمون SQLi المعتمد على الوقت لاستنتاج البيانات).
4. فحوصات النزاهة
   • ملفات النواة/الإضافة/القالب المعدلة (تغيرات في الطوابع الزمنية، ملفات PHP غير معروفة).
   • اختلافات بين تجزئات الملفات وقاعدة معروفة جيدة.
5. علامات سلوكية على الموقع
   • محتوى غير متوقع مضاف إلى الصفحات، إعادة توجيهات، JavaScript محقونة، أو أحداث كرون غير معروفة.
   • مستخدمو الإدارة يبلغون عن سلوك غريب أو عدم القدرة على تسجيل الدخول.

إذا رأيت عدة من الإشارات أعلاه، افترض وجود اختراق واتبع الخطوات الجنائية أدناه.

---

خطوات الطب الشرعي والاسترداد إذا كنت تشك في الاختراق

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

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

   wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 50;"

   find /var/www/html -type f -name "*.php" -mtime -7 -print

   افحص wp_options بحثًا عن تغييرات غير متوقعة في siteurl/home، أو خيارات جديدة يتم تحميلها تلقائيًا.

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

---

تعزيز طويل الأجل والوقاية

لتقليل فرصة حدوث حوادث مماثلة، اعتمد موقف الدفاع المتعمق.

1. الحفاظ على تحديثات في الوقت المناسب
   • وضع سياسة: اختبار ونشر تحديثات المكونات الإضافية والنواة في فترة زمنية قصيرة (يفضل خلال 24-72 ساعة للقضايا ذات الخطورة العالية).
   • استخدام بيئة اختبار للتوافق واستراتيجية تحديث آلية للتصحيحات الطارئة.
2. جرد كامل للمكونات الإضافية وتقييم المخاطر
   • تتبع المكونات الإضافية المثبتة، النشطة، وتواريخ آخر تحديث لها.
   • تعطيل وإزالة المكونات الإضافية غير المستخدمة على الفور.
3. مبدأ الحد الأدنى من الامتياز
   • تقليل صلاحيات مستخدمي قاعدة البيانات.
   • استخدام أذونات ملفات ودلائل قوية (منع الملفات القابلة للكتابة من قبل الجميع).
   • استخدام حسابات مستخدمين منفصلة للإدارة - عدم استخدام بيانات اعتماد مشتركة.
4. استخدام حماية متعددة الطبقات
   • جدار حماية تطبيقات الويب مع قواعد محددة للتطبيقات وقدرة على التصحيح الافتراضي.
   • مراقبة سلامة الملفات (FIM) لاكتشاف التلاعب.
   • فحص البرمجيات الضارة بانتظام وإجراء تدقيقات مجدولة.
5. فرض المصادقة متعددة العوامل (MFA) وسياسات كلمات مرور قوية لمستخدمي الإدارة
   • الجمع مع التحكم في الوصول القائم على الدور.
6. النسخ الاحتياطية وخطط الاسترداد
   • حافظ على نسخ احتياطية غير قابلة للتغيير خارج الموقع واختبر الاستعادة بشكل دوري.
   • احتفظ بنسخة نظيفة ومعروفة جيدة من موقعك وقاعدة البيانات.
7. التسجيل والتنبيه
   • مركزية السجلات (ويب، تطبيق، قاعدة بيانات) وضبط تنبيهات للانحرافات.
   • احتفظ بالسجلات لفترة احتفاظ مناسبة للاحتياجات الجنائية.

---

قائمة مراجعة سريعة

استخدم هذه القائمة الآن إذا كنت تدير تقويم الأحداث:

• تحديد إصدار المكون الإضافي (6.15.1.1 — 6.15.9 معرض للخطر)
• قم بالتحديث إلى 6.15.10 على الفور (مفضل)
• إذا لم يكن التحديث ممكنًا، قم بإلغاء تنشيط المكون الإضافي أو تطبيق تصحيح افتراضي لـ WAF
• قم بعمل نسخ احتياطية من الملفات وقاعدة البيانات قبل إجراء تغييرات كبيرة
• تطبيق حماية مؤقتة على مستوى الخادم (تحديد معدل، قواعد .htaccess/nginx)
• مراجعة السجلات بحثًا عن الشكوك س استخدام المعلمات وكلمات SQL الرئيسية
• البحث عن حسابات المسؤول غير المتوقعة، والملفات الجديدة، والملفات المعدلة
• تدوير بيانات الاعتماد الحرجة وتمكين MFA لمستخدمي المسؤول
• جدولة مراجعة أمنية بعد الحادث وخطة تعزيز

---

احصل على حماية مدارة فورية مع WP-Firewall (الخطة المجانية)

حماية الموقع الفورية — ابدأ مع WP-Firewall Basic (مجاني)

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

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

ابدأ في حماية موقعك في دقائق وقلل من التعرض للهجمات الآلية ومحاولات الاستغلال على نطاق واسع. اشترك في الخطة المجانية واحصل على حماية أساسية للموقع الآن: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(الترقية إلى المستويات المدفوعة تضيف إزالة البرمجيات الضارة تلقائيًا، وقوائم الحظر/القوائم البيضاء لعناوين IP، وتقارير شهرية، وتصحيح افتراضي تلقائي للثغرات الحرجة.)

---

الملحق - أوامر WP-CLI والمراجع المفيدة

تحقق من المكون الإضافي المثبت والإصدار:

wp plugin list --format=table

تحديث المكون الإضافي عبر WP-CLI:

wp plugin update the-events-calendar --version=6.15.10

تعطيل المكون الإضافي:

wp plugin deactivate the-events-calendar

البحث عن ملفات PHP المعدلة مؤخرًا (مثال):

find /var/www/html -type f -name '*.php' -mtime -14 -print

تفريغ إدخالات wp_users الأخيرة:

wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 50;"

إنشاء تفريغ قاعدة بيانات (لحفظ الأدلة):

wp db export /path/to/backups/site-db-before-update.sql

مراجع مفيدة:

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

---

ملاحظات نهائية من فريق أمان WP-Firewall

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

إذا كنت مالك موقع أو مسؤولاً وترغب في المساعدة، فإن WP-Firewall يوفر تخفيفاً مُداراً، ومراقبة في الوقت الحقيقي، وتصحيحاً افتراضياً لحماية المواقع خلال الفترات الحرجة. اعتبر البدء بالخطة المجانية للحماية الأساسية السريعة، ثم تقييم خطط Standard أو Pro للتصحيح التلقائي، والإزالة، والمراقبة المستمرة.

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