اسم البرنامج الإضافي	إضافة تسجيل الدخول والتسجيل JAY لـ WordPress
نوع الضعف	ثغرة في المصادقة
رقم CVE	CVE-2025-14440
الاستعجال	عالي
تاريخ نشر CVE	2025-12-16
رابط المصدر	CVE-2025-14440

عاجل: تجاوز المصادقة في JAY Login & Register (<= 2.4.01) — ما يجب على مالكي مواقع WordPress القيام به الآن

مؤلف: فريق أمان WP‑Firewall
تاريخ: 2025-12-16
العلامات: WordPress، الأمان، الثغرات، تجاوز المصادقة، WAF، استجابة الحوادث

ملخص: تم الكشف عن ثغرة خطيرة في المصادقة المكسورة (CVE-2025-14440) تؤثر على إضافة JAY Login & Register (الإصدارات <= 2.4.01) في 16 ديسمبر 2025. CVSS 9.8. تسمح الثغرة للمهاجمين غير المصرح لهم بتجاوز المصادقة عن طريق التلاعب بمنطق يعتمد على الكوكيز. إذا كنت تستخدم هذه الإضافة، يجب عليك التصرف على الفور — اتبع خطوات التخفيف والاكتشاف أدناه.

لماذا هذا مهم (قصير)

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

---

ما نعرفه عن الثغرة

• البرنامج المتأثر: إضافة JAY Login & Register لـ WordPress
• الإصدارات الضعيفة: <= 2.4.01
• التصنيف: المصادقة المكسورة (OWASP A07 / فشل التعريف والمصادقة)
• CVE: CVE-2025-14440
• الشدة: عالية (CVSS 9.8)
• الامتياز المطلوب: غير مصادق عليه (لا يتطلب تسجيل دخول)
• تاريخ النشر: 16 ديسمبر 2025
• رصيد البحث: تم الإبلاغ عنه من قبل باحث أمني

ملخص تقني (غير استغلالي):

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

لن نقوم بنشر استغلال أو PoC هنا. النهج المسؤول لمالكي المواقع والمدافعين هو التركيز على الاكتشاف، والاحتواء، والتصحيح.

---

الإجراءات الفورية لمالكي المواقع (مرتبة حسب الأولوية)

1. جرد وتحديد المواقع المتأثرة
   • قم بتسجيل الدخول إلى شبكة WordPress الخاصة بك أو كل موقع وتحقق مما إذا كانت إضافة JAY Login & Register مثبتة.
   • تأكد من إصدار الإضافة. إذا كان <= 2.4.01، اعتبر الموقع معرضًا للخطر.
2. قم بإيقاف الإضافة (إذا كان ذلك ممكنًا)
   • إذا كان ذلك ممكنًا وإذا كان وضع الموقع في وضع الصيانة مقبولًا، قم بإلغاء تنشيط الإضافة على الفور.
   • إذا كان الموقع يعتمد على الإضافة للمصادقة الحالية ولا يمكن إيقافه، تابع مع التخفيفات أدناه.
3. ألغِ الجلسات ودوّر الأسرار
   • دوّر أملاح وبيانات أمان ووردبريس (في wp-config.php). هذا يبطل ملفات تعريف الارتباط والجلسات الحالية.
   • اجبر جميع المستخدمين على تسجيل الخروج: في إدارة ووردبريس > المستخدمون، قم بتحرير كل حساب واستخدم إلغاء الجلسات (أو تغيير كلمة المرور) لإجبار تسجيل الخروج.
   • إذا كان لديك تخزين مؤقت لجلسات جانب الخادم للإضافة، قم بمسحه.
4. غيّر كلمات مرور المسؤولين وراجع حسابات المسؤولين
   • أعد تعيين كلمات المرور لجميع المستخدمين بمستوى المسؤول. فرض كلمات مرور قوية وعشوائية.
   • قم بمراجعة قائمة المستخدمين للبحث عن حسابات مسؤولين غير معروفة أو مشبوهة وأزلها أو قم بتعطيلها.
5. نشر حماية جدار حماية تطبيق الويب (WAF) / التصحيح الافتراضي
   • إذا كنت تستخدم WP-Firewall، قم بتمكين قاعدة التصحيح الافتراضي الطارئة التي نشرناها (انظر قسم التخفيف في WP-Firewall أدناه).
   • بالنسبة للمضيفين ومالكي المواقع على WAFs الأخرى، نفذ قواعد لحظر الطلبات المشبوهة التي تستهدف نقاط نهاية المصادقة، صفحات الإدارة، أو الطلبات التي تحمل قيم ملفات تعريف الارتباط المشبوهة.
   • رفض الطلبات غير المصرح بها التي تحاول التصرف مثل المستخدمين المصرح لهم (انظر التوجيهات الخاصة بالكشف وWAF أدناه).
6. قم بفحص الأبواب الخلفية ومؤشرات الاختراق (IoCs)
   • قم بتشغيل فحص كامل للبرامج الضارة باستخدام ماسح موثوق ومراقب سلامة الملفات.
   • ابحث عن ملفات مشبوهة، ملفات أساسية معدلة، ملفات PHP غير متوقعة في التحميلات، مستخدمين جدد كمسؤولين، مهام مجدولة غير عادية (cron)، أو اتصالات صادرة لم تكن موجودة من قبل.
   • إذا وجدت دليلًا على الاختراق، افترض أن المهاجم كان لديه وصول بمستوى المسؤول واتبع خطوات استجابة الحوادث (عزل، نسخ احتياطي، تنظيف، استعادة من نسخة احتياطية معروفة جيدة، تدوير بيانات الاعتماد).
7. قم بتصحيح المشكلة عند توفرها - أو قم بإزالة الإضافة.
   • إذا نشر مؤلف المكون الإضافي إصدارًا ثابتًا، فقم بتطبيقه على الفور وتحقق من موقعك.
   • إذا لم تتمكن من تصحيح المشكلة بسرعة أو كنت لا تثق في أن المكون الإضافي سيتم إصلاحه قريبًا، فقم بإزالة المكون الإضافي أو استبداله ببديل مدعوم. تأكد من أن لديك تصدير/نسخة احتياطية من أي بيانات مهمة يستخدمها المكون الإضافي.
8. راقب السجلات ونشاط الشبكة
   • افحص سجلات خادم الويب (سجلات الوصول وسجلات الأخطاء) للطلبات إلى نقاط نهاية الإدارة، admin-ajax.php، wp-login.php، نقاط نهاية AJAX، والصفحات التي يوفرها المكون الإضافي.
   • ابحث عن طلبات HTTP غير العادية من عناوين IP فردية أو مجموعة مركزة من عناوين IP، خاصة تلك التي تتضمن تغييرات في الكوكيز أو كوكيز معادة التشغيل.

---

أنماط الكشف المحددة وما يجب مراقبته

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

• قيم الكوكيز غير المتوقعة في الطلبات إلى wp-admin، wp-login، أو نقاط نهاية AJAX.
• الطلبات التي تضبط أو تعدل الكوكيز مباشرة قبل الوصول إلى صفحات الإدارة.
• الطلبات المتكررة التي تحاكي سلوكًا مصدقًا من نفس عنوان IP ولكن بدون جلسة صالحة معروفة (على سبيل المثال، قيمة كوكيز متطابقة عبر العديد من عناوين IP أو وكلاء مستخدمين مختلفين).
• حسابات إدارية جديدة تم إنشاؤها من عناوين IP أو وكلاء مستخدمين مشبوهين.
• أحجام عالية من الطلبات التي تحتوي على رؤوس الكوكيز ولكنها تؤدي إلى استجابات 200 لموارد محمية بالإدارة.
• طلبات POST غير العادية إلى نقاط النهاية التي يتعامل معها المكون الإضافي (التسجيل، تسجيل الدخول، إجراءات AJAX المخصصة) مصحوبة بتعديلات على الكوكيز.

عندما ترى أنماطًا مشبوهة:

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

---

تخفيف WP-Firewall والتصحيح الافتراضي (كيف نحميك)

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

ماذا يفعل WP-Firewall:

• يحظر الطلبات التي تتطابق مع أنماط التوقيع التي طورناها بالتنسيق مع تقرير الثغرات.
• يوقف الطلبات التي تحاول التصعيد إلى وظائف الإدارة من خلال استغلال تدفقات المصادقة المعتمدة على الكوكيز.
• يوفر تنبيهات وتقارير في الوقت الحقيقي حتى يرى مالكو المواقع المحاولات ويمكنهم الاستجابة.
• يمكّن تدابير تعزيز مؤقتة (قائمة رفض نقاط النهاية المحددة، فرض رؤوس أمان الكوكيز، وحظر التلاعب غير المتوقع بالكوكيز).

إذا كنت تستخدم WP-Firewall:

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

مهم: قواعد WAF هي تخفيف، وليست إصلاحًا دائمًا. يجب عليك أيضًا تصحيح الإضافة أو إزالتها بمجرد توفر إصلاح رسمي.

---

إرشادات قواعد WAF العملية (عامة وآمنة - أمثلة للمدافعين)

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

• حظر الطلبات غير المصرح بها POST إلى نقاط النهاية الخاصة بالإدارة أو الإضافات عندما تكون مصحوبة بملفات تعريف الارتباط الجديدة التي تم تعيينها/تعديلها.
• حظر الطلبات التي تحاول الوصول مباشرة إلى وظائف الإدارة عندما يفتقر الطلب إلى ملف تعريف ارتباط جلسة WordPress صالح (أو عندما لا يتطابق ملف تعريف الارتباط مع جلسة في تخزين جانب الخادم).
• تحديد معدل أو رفض مؤقت للطلبات المتكررة من عنوان IP واحد الذي يحدد الكوكيز ثم يصل إلى نقاط النهاية الإدارية.
• رفض الطلبات التي تحتوي على سلوك تعيين الكوكيز مع الوصول إلى /wp-admin/ أو نقاط نهاية AJAX الإدارية.
• فرض سمات الكوكيز الآمنة (HttpOnly، Secure، SameSite) للكوكيز التي أنشأتها الإضافة (حيثما كان ذلك ممكنًا).

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

---

كيفية التحقق مما إذا كان موقعك قد تم استغلاله

إذا كنت تشك في وجود اختراق، قم بإجراء الفحوصات التالية على الفور:

1. حسابات المستخدمين
   • قم بمراجعة جميع حسابات المستخدمين. ابحث عن الحسابات التي لها دور المسؤول ولم تقم بإنشائها.
   • تحقق من توقيتات الإنشاء وعناوين IP لحسابات المسؤولين.
2. الملفات والرموز
   • قارن الملفات الحالية بنسخة احتياطية معروفة جيدة أو ملفات نواة/ثيم/إضافات ووردبريس نظيفة.
   • ابحث عن ملفات PHP غير متوقعة في wp-content/uploads أو wp-includes.
   • تحقق من توقيتات التعديل التي لا تتماشى مع التحديثات العادية.
3. المهام المجدولة
   • قم بإدراج مهام cron (مدخلات wp-cron). ابحث عن المهام المجدولة التي أنشأتها إضافات أو مستخدمون غير معروفين.
4. اتصالات صادرة
   • تحقق من الاتصالات HTTP الصادرة غير المتوقعة أو استعلامات DNS من الخادم التي قد تشير إلى تسرب البيانات.
5. تغييرات قاعدة البيانات
   • راجع wp_options و wp_users و جدول الإضافات للمدخلات غير المتوقعة. ابحث عن تعديلات البيانات المتسلسلة التي تتيح الأبواب الخلفية.
6. مؤشرات الأبواب الخلفية
   • ابحث عن أنماط الشيفرة المشوشة، eval()، base64_decode()، أو استدعاءات لوظائف system/exec في ملفات الإضافات/الثيمات.

إذا وجدت دليلًا على الاختراق:

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

---

توصيات تعزيز الأمان لتقليل المخاطر الناتجة عن مشاكل تتعلق بالكوكيز

حتى بعد التخفيف الفوري، فإن تعزيز بيئة ووردبريس الخاصة بك يقلل من خطر حدوث مشاكل مماثلة:

• فرض MFA لجميع حسابات المسؤولين (استخدم تطبيق مصادقة أو رموز الأجهزة).
• تحديد وصول المسؤولين حسب IP حيثما كان ذلك ممكنًا (على سبيل المثال، قيود جدار الحماية أو القيود المستندة إلى المضيف).
• استخدم التحكم في الوصول القائم على الدور وأقل الامتيازات - تجنب منح صلاحيات المسؤول لعدة أشخاص دون داعٍ.
• حافظ على تحديث نواة WordPress والسمات والإضافات واشترك في خدمة إشعارات الثغرات/التصحيحات.
• قم بتمكين علامات ملفات تعريف الارتباط الآمنة (HttpOnly، Secure، SameSite) لملفات تعريف الارتباط الخاصة بالجلسة والمصادقة حيث تدعمها بنيتك.
• نفذ تسجيلًا قويًا ومراقبة (سجلات التدقيق، اكتشاف تغيير الملفات، تنبيهات تسجيل الدخول الفاشلة).
• استخدم WAF مُدارًا مع القدرة على التصحيح الافتراضي حتى تتمكن من حظر أنماط الاستغلال المعروفة بسرعة.
• قم بعمل نسخ احتياطية لموقعك بانتظام وتحقق من أن النسخ الاحتياطية قابلة للاستعادة.

---

إرشادات الاتصال للوكالات والمضيفين الذين يديرون مواقع العملاء.

إذا كنت تدير مواقع عملاء متعددة أو تستضيف تثبيتات WordPress للعملاء:

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

---

لمطوري الإضافات: الدروس المستفادة ونصائح البرمجة الآمنة.

تؤكد هذه الثغرة على الأخطاء الشائعة عند تنفيذ المصادقة باستخدام ملفات تعريف الارتباط المخصصة.

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

---

كيف تم حماية عملاء WP-Firewall (ما فعلناه)

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

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

---

قائمة التحقق من التعافي والتخفيف على المدى الطويل

بمجرد الانتهاء من التخفيف الفوري، اتبع هذه القائمة لاستعادة وتقوية موقعك:

1. تأكد من أن المكون الإضافي تم تصحيحه أو استبداله
   • إذا كان هناك إصلاح متاح من البائع، قم بتطبيقه والتحقق من الوظائف.
   • إذا لم يكن هناك إصلاح متاح، قم بإزالة المكون الإضافي ونقل الميزات إلى بديل آمن.
2. تحقق من سلامة الموقع
   • قم بتشغيل فحوصات سلامة الملفات مقابل نسخ نظيفة من ووردبريس والقوالب.
   • أعد فحص البرمجيات الخبيثة ومؤشرات الاختراق.
3. نظافة بيانات الاعتماد
   • قم بتدوير جميع بيانات الاعتماد: قاعدة البيانات، الاستضافة، FTP/SFTP، لوحات التحكم، مفاتيح API، وبيانات اعتماد SMTP.
   • تطلب MFA للحسابات المميزة.
4. المراقبة والتنبيهات
   • تمكين مراقبة الموقع وإشعارات تسجيل الدخول.
   • تنفيذ التنبيهات للتغييرات الإدارية وتعديلات الملفات.
5. وثق وأبلغ.
   • توثيق جدول زمني للحادث، وما تأثر، وخطوات التخفيف المتخذة، وخطوات التحقق.
   • إذا كانت مؤسستك تتطلب تقارير تنظيمية أو إشعارات للعملاء، اتبع الإرشادات القانونية والامتثال.
6. ما بعد الحادث والوقاية
   • إجراء تحليل بعد الحادث لتحديد السبب الجذري وتحسين الضوابط.
   • تحديث سياسات إدارة التغيير وشراء البائعين/الإضافات لتشمل مراجعات الأمان.

---

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

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

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

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

س: متى يجب أن أتصرف؟
ج: على الفور. لأن الثغرة قابلة للاستغلال بدون مصادقة ولها تصنيف شدة مرتفع، قم بتطبيق التخفيفات الآن.

---

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

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

• حماية أساسية: جدار ناري مُدار، عرض نطاق غير محدود، WAF، ماسح للبرامج الضارة، وتخفيف مخاطر OWASP Top 10.
• لا حاجة لبطاقة ائتمان — قم بالتسجيل وتمكين الحماية في دقائق.
• الرابط: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

---

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

هذه الثغرة تذكير صارخ: المصادقة هي حدود حاسمة، وأي ضعف هناك قد يكون كارثيًا. تعامل مع كود مصادقة الإضافة بنفس الصرامة التي تتعامل بها مع نواة ووردبريس. إذا كنت تستخدم الإضافة المتأثرة (JAY Login & Register <= 2.4.01)، تصرف الآن — إما تعطيل الإضافة، أو تطبيق التخفيفات، أو إزالتها حتى يتوفر إصدار مصحح ويتم التحقق منه.

إذا كنت تستخدم WP‑Firewall، تأكد من أن موقعك متصل وأن قواعد التهديدات محدثة. بالنسبة للوكالات والمضيفين، أعطِ الأولوية لتحديثاتك والتواصل: عملاؤك يعتمدون عليك.

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

— فريق أمان جدار الحماية WP