اسم البرنامج الإضافي	ملحق تبديل حسابات ووردبريس
نوع الضعف	ثغرة في المصادقة
رقم CVE	CVE-2026-6456
الاستعجال	عالي
تاريخ نشر CVE	2026-05-21
رابط المصدر	CVE-2026-6456

عاجل: ملحق تبديل الحسابات (<= 1.0.2) — مصادقة معطلة (CVE‑2026‑6456) وما يجب عليك فعله الآن

ملخص: توجد ثغرة عالية الخطورة (CVSS 8.8) في ملحق ووردبريس “تبديل الحسابات” بالإصدارات <= 1.0.2 تتيح للمستخدمين المعتمدين من مستوى المشترك تجاوز فحوصات المصادقة وزيادة الامتيازات. لا يوجد تصحيح رسمي متاح في وقت هذه الإشعار. إذا كنت تستخدم هذا الملحق، اعتبره حالة طارئة: اتبع على الفور خطوات التخفيف والكشف أدناه، أو استخدم حل تصحيح افتراضي مُدار من WP-Firewall لمنع الاستغلال أثناء تخطيطك لإصلاح آمن.

---

لماذا هذا مهم (نسخة قصيرة)

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

تم تصنيف هذه الثغرة على أنها عالية (CVSS 8.8) وهي خطيرة بشكل خاص لأنها يمكن أن تكون مؤتمتة وتستخدم على نطاق واسع. تابع القراءة للحصول على إرشادات عملية للكشف والتخفيف والتعافي من فريق أمان WP‑Firewall.

---

البرمجيات المتأثرة والمعرفات

• برمجة: ملحق ووردبريس — تبديل الحسابات
• الإصدارات المتأثرة: <= 1.0.2
• التصنيف: مصادقة معطلة (OWASP A7 / فشل المصادقة والتفويض)
• CVE: CVE‑2026‑6456
• حالة التصحيح: لا يوجد تصحيح رسمي متاح (في وقت النشر)
• الامتياز المطلوب للاستغلال: مشترك موثق (امتياز منخفض)
• تقارير Patchstack/طرف ثالث: تم نشر إشعارات عامة — اعتبر المشكلة نشطة وعاجلة

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

---

ما هي “المصادقة المعطلة” في هذا السياق؟

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

مع ملحق تبديل الحسابات (<=1.0.2)، يكشف الملحق عن وظيفة لتبديل أو تقليد الحسابات. يمكن إساءة استخدام هذه الوظيفة — عندما لا تكون محمية بفحوصات القدرة الصحيحة وnonces — من قبل المستخدمين المعتمدين الذين لا ينبغي أن يكونوا قادرين على إجراء التبديل. عند الاستغلال، يمكن للمهاجم تنفيذ إجراءات كمستخدم آخر (ربما مدير)، أو إنشاء حساب مرتفع مستمر.

---

لماذا هذا خطير بشكل خاص

1. حاجز دخول منخفض: حساب منخفض الامتيازات يكفي (مشترك). العديد من مواقع ووردبريس تسمح بتسجيل المشتركين أو لديها حسابات مشتركين خاملة.
2. زيادة الامتيازات: يؤدي الاستغلال الناجح إلى الوصول إلى المدير أو السيطرة المعادلة على وظائف الموقع المهمة.
3. إمكانية الأتمتة: يمكن للمهاجمين بناء سكريبتات للعثور على المواقع الضعيفة ومحاولة الاستغلال بشكل جماعي.
4. التأثير downstream: بمجرد الارتفاع، يمكن للمهاجمين حقن أبواب خلفية، وإنشاء مستخدمين إداريين خبيثين، واستخراج البيانات، وتغيير المحتوى، أو الانتقال إلى أنظمة أخرى مستضافة في نفس البيئة.
5. لا يوجد تصحيح فوري: عندما لا يتوفر تحديث رسمي للإضافة، تكون المواقع معرضة للخطر حتى يتم التخفيف منها بوسائل أخرى.

---

كيف يمكن للمهاجمين استغلال ذلك (على مستوى عالٍ)

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

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

---

تقييم المخاطر الفورية لموقعك

• إذا كنت تستخدم Account Switcher <= 1.0.2 وتسمح بتسجيلات المشتركين أو لديك حسابات مشتركين → خطر مرتفع.
• إذا كانت موقعك لا يسمح بتسجيلات مشتركين جديدة وتدقق في جميع المشتركين أنهم موثوقون → خطر معتدل — لا يزال عاجلاً لأن المهاجم قد يكون لديه حساب بالفعل.
• إذا لم تستخدم الإضافة على الإطلاق (ولم يتم تثبيتها) → غير قابل للتطبيق.
• إذا كان لديك الإضافة وهي نشطة → اعتبرها ثغرة حرجة واتخذ خطوات فورية.

---

الإجراءات الفورية — ماذا تفعل الآن (قائمة مرتبة حسب الأولوية)

1. تدقيق وجود الإضافة وحالتها
   – قم بتسجيل الدخول إلى wp-admin كمالك/مدير وتحقق مما إذا كانت إضافة Account Switcher مثبتة ونشطة. إذا لم تكن الإضافة موجودة، فأنت غير متأثر بثغرة هذه الإضافة.
2. إذا كانت الإضافة مثبتة ونشطة — قم بإيقافها:
   – أسرع وأمان إجراء هو تعطيل الإضافة على الفور. إذا لم تتمكن من الوصول إلى wp-admin بسبب الاختراقات، قم بإعادة تسمية دليل الإضافة عبر SFTP/SSH: wp-content/plugins/account-switcher → إعادة التسمية إلى account-switcher.disabled.
   – إذا كنت بحاجة إلى وظيفة الإضافة ولا يمكنك إزالتها، تابع إلى التخفيفات الوقائية أدناه (WAF/تصحيح افتراضي)، لكن يُوصى بشدة بالتعطيل حتى يتوفر تصحيح.
3. تعزيز التسجيل والحسابات:
   – تعطيل تسجيلات المستخدمين الجدد حتى يتم تصحيح الإضافة. (الإعدادات → عام → العضوية: قم بإلغاء تحديد “يمكن لأي شخص التسجيل”.)
   – مراجعة جميع حسابات المشتركين وإزالة الحسابات غير المعروفة أو المشبوهة.
   – اجبر جميع مستخدمي المسؤولين على إعادة المصادقة، وتدوير كلمات المرور، وتمكين كلمات مرور قوية (وMFA حيثما أمكن).
4. إلغاء الجلسات وإعادة تعيين المفاتيح:
   – إبطال جميع الجلسات النشطة إذا أمكن. استخدم مكونًا إضافيًا أو تحديث قاعدة بيانات لتغيير الأملاح والمفاتيح (wp-config.php AUTH_KEY، إلخ) بعد إجراء النسخ الاحتياطي اللازم. ملاحظة: تغيير الأملاح سيؤدي إلى تسجيل خروج جميع المستخدمين.
   – تدوير أي أسرار API أو كلمات مرور التطبيقات التي قد تم استخدامها من قبل الموقع.
5. تدقيق كامل للموقع:
   – ابحث عن مستخدمي المسؤولين الجدد، والملفات المشبوهة تحت wp-content/uploads, ، والمهام المجدولة غير المتوقعة (cron)، وأي ملفات أساسية/مكون إضافي/ثيم معدلة.
   – إذا كانت هناك أي مؤشرات على الاختراق، قم بإيقاف الموقع (وضع الصيانة) وابدأ استجابة الحوادث.
6. استعادة من نسخة احتياطية نظيفة إذا تم الاختراق:
   – إذا تم اختراق الموقع ولا يمكنك تنظيفه بثقة، استعد من نسخة احتياطية معروفة جيدة تم أخذها قبل الاستغلال. تأكد من تصحيح أو تخفيف ثغرة المكون الإضافي قبل إعادة الاتصال.
7. سجلات المراقبة:
   – راقب سجلات خادم الويب للطلبات POST المشبوهة أو الطلبات المعتمدة إلى نقاط نهاية المكون الإضافي. إذا كان لديك تسجيل مركزي، قم بتعيين تنبيهات للأنماط غير العادية.
8. تطبيق التصحيح الافتراضي على الفور (موصى به):
   – استخدم جدار حماية تطبيق الويب (WAF) أو حل التصحيح الافتراضي لحظر محاولات الاستغلال التي تستهدف أنماط طلبات المكون الإضافي أثناء انتظار تحديث رسمي أو إعادة بناء بيئتك. يوفر WP‑Firewall مجموعات قواعد مُدارة يمكن أن تحظر محاولات الاستغلال لهذه الثغرة.

---

قائمة التحقق من الكشف - علامات على أن هذه الثغرة قد تم محاولة استغلالها أو استغلالها

تحقق من المواقع التالية للنشاط المشبوه:

• مستخدمو المسؤولين الجدد في مستخدمو wp جدول (wp_users.user_login, wp_users.user_email)
• تغييرات غير متوقعة على جدول الخيارات (خيارات wp) أو إعدادات عنوان URL للموقع
• ملفات PHP جديدة أو معدلة في wp-content/uploads أو دلائل الإضافات/القوالب
• مهام مجدولة غير عادية: أحداث wp-cron التي تشغل كود غير مألوف
• ملفات بتوقيتات تغيير حديثة تتزامن مع نشاط غير معروف
• تعديلات غير متوقعة على ملفات القالب أو الملفات الأساسية (الفهرس.php, wp-config.php)
• أدلة في سجلات الخادم على طلبات POST مصادق عليها إلى نقاط نهاية الإضافات، خاصة من وكلاء مستخدمين أو عناوين IP لمشتركين مع محاولات متعددة
• سجلات تسجيل الدخول تظهر مشتركًا يقوم بإجراءات خاصة بالمسؤول (إذا كان لديك تسجيل تدقيق)

استعلامات WP‑CLI مفيدة (يتطلب الوصول إلى محطة المسؤول):

• قائمة المستخدمين الذين لديهم دور ‘المسؤول’:
  wp user list --role=administrator --fields=ID,user_login,user_email,registered
• قائمة بجميع المستخدمين والأدوار:
  wp user list --format=csv
• البحث عن الملفات المعدلة مؤخرًا (صدفة لينكس):
  ابحث . -نوع f -mtime -14 -printf '%TY-%Tm-%Td %TT %p
' | فرز -r
• التحقق من أحداث cron غير المعروفة:
  قائمة أحداث wp cron

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

---

خطوات التنظيف إذا كنت تشك في الاختراق

1. عزل البيئة:
   – قم بإيقاف الموقع أو تقييد الوصول عبر قوائم بيضاء لعناوين IP أثناء التحقيق.
2. الحفاظ على الأدلة:
   – تصدير السجلات، ونسخ قواعد البيانات، وقوائم الملفات للمراجعة الجنائية. لا تقم بكتابة السجلات فوق.
3. إعادة إنشاء الموقع على بنية تحتية نظيفة:
   – إذا اكتشفت اختراقًا، فإن الطريق الأكثر أمانًا هو إعادة بناء الموقع من أصول معروفة نظيفة ونسخة احتياطية قبل الاختراق. مراجعة الإضافات/القوالب يدويًا وإعادة التثبيت من مصادر البائع الأصلية.
4. إزالة الأبواب الخلفية والملفات المشبوهة:
   – إزالة الملفات غير المعروفة في التحميلات، mu-plugins، wp-content، والتحقق من وجود ملفات PHP جديدة في أي مكان لا ينبغي أن تكون فيه.
5. تدوير بيانات الاعتماد:
   – تغيير جميع رسائل البريد الإلكتروني الخاصة بالمسؤولين، وكلمات المرور، ومفاتيح API، وبيانات اعتماد قاعدة البيانات، وبيانات اعتماد الخادم.
6. إعادة التثبيت والتحديث:
   – إعادة تثبيت الإضافة فقط بعد توفر تصحيح أمان رسمي أو بعد أن يكون لديك سياسة تصحيح افتراضية موثوقة. خلاف ذلك، اترك الإضافة غير مفعلة.
7. تعزيز الدفاعات:
   – تنفيذ MFA لحسابات المسؤولين، إعداد سياسات كلمات مرور قوية، تثبيت وتكوين تسجيل الدخول والتنبيهات، وتمكين WAF.
8. مراقبة ما بعد الحادث:
   – الاستمرار في مراقبة السجلات والوصول لمدة عدة أسابيع على الأقل بعد الإصلاح لأي علامات على الحركة الجانبية أو إعادة العدوى.

---

حلول مؤقتة وتخفيفات (إذا كان يجب عليك إبقاء الإضافة نشطة)

إذا لم تتمكن من تعطيل الإضافة على الفور لأن عملك يعتمد عليها، قم بما يلي كإجراءات مؤقتة:

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

تذكر: هذه حلول مؤقتة — يجب تصحيح الإضافة أو إزالتها لإصلاح كامل.

---

كيف يساعد WP‑Firewall — التصحيح الافتراضي والحماية المستمرة

كمزود أمان WordPress مُدار، يقدم WP‑Firewall طبقات متعددة من الحماية مصممة لتخفيف الثغرات مثل هذه بينما تخطط لإصلاح طويل الأمد:

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

إذا كنت بحاجة إلى حماية فورية وليس لديك تصحيح آمن متاح بعد، فإن التصحيح الافتراضي عبر WP‑Firewall يمنحك الوقت لإجراء تصحيح كامل ودقيق دون ترك الموقع مكشوفًا.

---

تعزيز طويل الأمد موصى به (بخلاف الإصلاح الفوري)

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

---

سيناريوهات الحوادث النموذجية - ما الذي يمكن أن يمكّنه استغلال ناجح

• إنشاء حساب مسؤول خلفي يستمر بعد التنظيف الأولي.
• تثبيت مكون إضافي خبيث أو تعديل مكون إضافي موجود لتنفيذ PHP عشوائي.
• تشويه الموقع والبريد العشوائي SEO الذي يضر بالسمعة وترتيب البحث.
• تسرب البيانات - رسائل البريد الإلكتروني للمستخدمين والبيانات الشخصية المخزنة في قاعدة البيانات.
• الانتقال من الموقع المصاب إلى مواقع أخرى على نفس المضيف المشترك أو إلى الخدمات المتصلة عبر بيانات اعتماد مسروقة.

---

ما يجب مراقبته في السجلات (أنماط عملية)

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

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

---

الجدول الزمني والإفصاح المسؤول (ما يحدث عادة)

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

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

---

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

إذا أكدت حدوث اختراق:

1. عزل الموقع وإيقافه عن العمل.
2. الحفاظ على السجلات والجدول الزمني للنشاط للتحليل الجنائي.
3. تحديد النطاق - تحديد الحسابات أو الملفات أو البيانات التي تأثرت.
4. استعادة من نسخة احتياطية نظيفة قبل الاختراق (إذا كانت متاحة).
5. تحديث جميع بيانات الاعتماد وتدوير المفاتيح.
6. إعادة تثبيت نواة ووردبريس والسمات / المكونات الإضافية من مصادر موثوقة معروفة.
7. تقوية الموقع وتثبيت WAF مع قواعد التصحيح الافتراضي.
8. راقب إعادة العدوى لمدة 30-90 يومًا.

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

---

التعليمات

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

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

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

---

روابط ومراجع مفيدة

• صفحة المكون الإضافي لـ WordPress (تحقق من المكون الإضافي والإصدار)
• تفاصيل CVE

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

---

احمِ موقعك اليوم مع WP‑Firewall Basic (مجاني)

عنوان: تأمين موقع WordPress الخاص بك في دقائق - حماية مجانية متاحة

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

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

---

كلمات أخيرة من فريق أمان WP‑Firewall

هذه ثغرة عالية الأولوية وعالية التأثير لأنها تسمح لمستخدم مصدق منخفض الامتياز بتجاوز فحوصات المصادقة والحصول على تحكم مرتفع. إذا كان موقعك يعمل على Account Switcher (<=1.0.2)، تصرف على الفور: ألغِ تنشيط المكون الإضافي، تدقيق المستخدمين، إلغاء الجلسات، وتطبيق التصحيح الافتراضي أو حماية WAF. إذا لم تكن متأكدًا من كيفية المتابعة أو وجدت علامات على الاختراق، اتصل بمزود الأمان الخاص بك أو فريق استجابة الحوادث الموثوق به للمساعدة في احتواء المشكلة وإصلاحها.

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

ابقَ آمنًا، وتعامل مع النصائح المتعلقة بالمصادقة بالجدية التي تستحقها.