التخفيف من التحكم في الوصول المكسور في إضافات ووردبريس//نُشر في 2026-05-12//CVE-2026-4301

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

Rate Star Review Vulnerability

اسم البرنامج الإضافي تقييم مراجعة النجوم
نوع الضعف نظام التحكم في الوصول مكسور
رقم CVE CVE-2026-4301
الاستعجال قليل
تاريخ نشر CVE 2026-05-12
رابط المصدر CVE-2026-4301

ثغرة التحكم في الوصول في “تقييم مراجعة النجوم” (<= 1.6.4): ما يجب على مالكي المواقع القيام به الآن

بواسطة فريق أمان WP‑Firewall | 2026-05-12 | العلامات: ووردبريس، WAF، ثغرة، التحكم في الوصول المكسور، أمان الإضافات


ملخص

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


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

  • نظرة عامة: ما حدث ولماذا هو مهم
  • التحليل الفني: لماذا يعتبر هذا التحكم في الوصول مكسورًا
  • سيناريو الاستغلال والأثر
  • كيفية التحقق مما إذا كان موقعك متأثرًا
  • خطوات التخفيف الفورية (لأصحاب المواقع)
  • التصحيح الافتراضي الموصى به / توقيعات WAF
  • تصحيح آمن قصير الأجل (mu-plugin)
  • إصلاحات طويلة الأجل لمؤلفي الإضافات
  • قوائم التحقق من تعزيز الأمان والمراقبة
  • WP‑Firewall: خطة حماية مجانية — ابدأ الآن (جديد)
  • الاستنتاجات والموارد

نظرة عامة: ما حدث ولماذا هو مهم

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

لماذا هذا مهم:

  • التحكم في الوصول المكسور هو مسار شائع لتصعيد الامتيازات والتلاعب بالمحتوى.
  • سطح الهجوم كبير: أي موقع يحتوي على إصدار الإضافة المتأثرة مثبتًا ومع تفعيل حسابات المستخدمين أو التسجيل يكون في خطر.
  • غالبًا ما تستهدف الماسحات الضوئية الآلية والمهاجمون الانتهازيون نقاط نهاية AJAX (admin-ajax.php / نقاط نهاية REST) لأنها سهلة الوصول وغالبًا ما تفتقر إلى التحقق الصحيح من القدرات.
  • على الرغم من أن الدور المتأثر هو “مشترك”، إلا أن النتيجة (تعديل غير مصرح به للمنشورات) يمكن أن تضر بـ SEO، وثقة المستخدم، وعمليات الأعمال، وفي بعض الحالات تؤدي إلى مزيد من الاختراقات.

يشرح هذا المقال بالضبط ما يجب البحث عنه وكيفية حماية موقعك — على الفور وعلى المدى الطويل.


التحليل الفني: لماذا يعتبر هذا التحكم في الوصول مكسورًا

على مستوى عالٍ، تنشأ الثغرة من ثلاثة أخطاء شائعة في الترميز في معالجات AJAX لإضافات ووردبريس:

  1. فحوصات القدرة المفقودة
    • المعالج يقبل الطلبات ويعالج التعديلات على محتوى المنشورات أو بيانات المنشورات ولكن لا يتحقق أبداً مما إذا كان المستخدم الذي يقدم الطلب لديه القدرة المطلوبة لتعديل المنشور المستهدف (على سبيل المثال،, تعديل المنشور القدرة).
  2. التحقق من nonce المفقود أو غير الصحيح
    • Nonces (عبر تحقق_من_المرجع_ajax أو wp_verify_nonce) تضمن أن الطلبات تأتي من صفحة صالحة أو جلسة مستخدم. إذا لم يتحقق المعالج من nonce أو استخدم تدفق nonce قابل للتنبؤ/غير صالح، يمكن للمهاجمين تزوير الطلبات من سياقات عشوائية.
  3. الثقة العمياء في المعرفات المقدمة من المستخدم
    • المعالج يثق في معلمات POST/GET مثل معرف المنشور, مفتاح_الميتا, قيمة_الميتا, ، إلخ، دون التحقق من النوع، أو التنظيف، أو تقييد نطاق التعديل.

مجتمعة، هذه القضايا تسمح لمهاجم يمكنه المصادقة كـ Subscriber بتفعيل إجراء المكون الإضافي (غالباً عبر admin-ajax.php أو نقطة نهاية REST) وتعديل المنشورات التي لا يمتلكها. المشكلة هي “تحكم وصول معطل” لأن الكود يفشل في فرض قواعد تفويض صحيحة بالنسبة للإجراء الذي يتم تنفيذه.

عناصر تحكم WordPress الهامة التي كان يجب استخدامها

  • check_ajax_referer('expected_action_nonce', 'nonce_field', true) (أو wp_verify_nonce)
  • يمكن للمستخدم الحالي ('تعديل المنشور'، $post_id) أو تحقق من القدرات بشكل أكثر تفصيلاً
  • التنظيف الصحيح والهروب من جميع المدخلات المستخدمة لعمليات قاعدة البيانات أو الملفات

سيناريو الاستغلال والأثر

مسار الاستغلال النموذجي (على مستوى عالٍ، دون كود استغلال خطوة بخطوة):

  1. المهاجم يسجل حساباً (إذا كان التسجيل مسموحاً) أو يختراق حساب Subscriber موجود.
  2. المهاجم يصنع طلب HTTP إلى admin-ajax.php (أو مسار AJAX الخاص بالمكون الإضافي)، ويحدد معلمة الإجراء الخاصة بالمكون الإضافي التي تفعّل المعالج المعرض للخطر.
  3. المعالج ينفذ، ويتلقى معلمات مثل post_id، محتوى جديد، أو بيانات وصفية، ويطبق تلك التغييرات على صفوف قاعدة بيانات المنشورات دون التحقق من حق المستخدم في القيام بذلك.
  4. المهاجم يعدل المنشورات (المحتوى، الحالة، المؤلف، البيانات الوصفية)، يحقن رسائل غير مرغوب فيها أو روابط خبيثة، أو يفسد بيانات الموقع.

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

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

تقييم الشدة

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

كيفية التحقق مما إذا كان موقعك متأثرًا

  1. تحديد المكون الإضافي والإصدار
    • من WP Admin → الإضافات، تحقق من الإصدار المثبت من إضافة “Rate Star Review”. إذا كان الإصدار ≤ 1.6.4، فإن الموقع قد يكون عرضة للخطر.
    • إذا كان لديك وصول إلى الشل، استخدم WP-CLI:
      wp plugin get rate-star-review --field=version
  2. ابحث عن أسماء إجراءات AJAX للإضافة
    • راجع مصدر الإضافة لـ add_action( 'wp_ajax_*' ) أو add_action( 'wp_ajax_nopriv_*' ) الإدخالات.
    • ابحث عن سلاسل الإجراءات المحتملة في ملفات الإضافة (مثل، “vote”، “ajax_vote”، “vote_ajax_reviews”، “rate_vote”).
  3. تدقيق سجلات الوصول للطلبات المشبوهة
    • ابحث في سجلات وصول خادم الويب عن الطلبات إلى admin-ajax.php أو نقاط نهاية REST للإضافة التي تحتوي على معلمة الإجراء أو POSTs مشبوهة:
      grep 'admin-ajax.php' /var/log/nginx/access.log | grep -i 'vote'
    • ابحث عن الطلبات المتكررة من نفس عناوين IP، أو الطلبات من حسابات مستخدمين معروفة تتوافق مع طوابع زمنية لتعديل المشاركات المشبوهة.
  4. افحص مراجعات المشاركات الأخيرة وحقوق التأليف
    • تحقق من تاريخ المراجعة وتواريخ التعديل الأخيرة للمشاركات:
      wp post list --post_type=post --format=csv --fields=ID,post_title,post_modified,post_modified_gmt
    • إذا تغير محتوى المشاركة بشكل غير متوقع، راجع المراجعات عبر محرر WP Admin.
  5. تحقق من قاعدة البيانات للبيانات الوصفية غير العادية
    • ابحث عن التغييرات المفاجئة في postmeta أو المفاتيح المخصصة التي أضافها المكون الإضافي.
  6. مراجعة الحسابات ذات دور المشترك
    • قائمة المستخدمين ذوي دور المشترك وابحث عن الحسابات أو التسجيلات المشبوهة.
  7. فحص البرمجيات الخبيثة
    • قم بتشغيل ماسح ضوئي موثوق للبرامج الضارة (مكون إضافي أو مستند إلى المضيف) للتحقق من التعليمات البرمجية المدخلة أو الملفات المشبوهة.

خطوات التخفيف الفورية (لأصحاب المواقع)

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

  1. تحديث المكون الإضافي إذا كان هناك إصدار مصحح متاح
    • إذا أصدر مؤلف المكون الإضافي إصلاحًا، قم بالتحديث على الفور. تأكد دائمًا من التحديث عبر WP Admin أو WP-CLI:
      تحديث إضافة wp rate-star-review
  2. إذا لم يكن هناك تصحيح متاح، قم بإلغاء تنشيط المكون مؤقتًا
    • قم بإلغاء تنشيط المكون الإضافي من WP Admin أو عبر WP-CLI:
      تعطيل إضافة wp rate-star-review
    • إلغاء التنشيط يزيل سطح الهجوم ولكن قد يزيل الوظائف؛ وزن احتياجات العمل.
  3. فرض قواعد تسجيل أقوى
    • تعطيل التسجيل العام مؤقتًا إذا لم تكن بحاجة إليه (الإعدادات → عام → العضوية).
    • فرض التحقق من البريد الإلكتروني أو الموافقة اليدوية على التسجيلات.
  4. فرض إعادة تعيين كلمات المرور للحسابات ذات الامتيازات المنخفضة
    • إذا كنت تشك في إساءة الاستخدام، تطلب إعادة تعيين كلمات المرور أو إزالة الحسابات المشبوهة.
  5. تصحيح افتراضي عبر WAF
    • تطبيق قاعدة WAF لحظر الطلبات إلى إجراء AJAX المعرض للخطر ما لم يكن هناك nonce صالح، أو حظر الإجراء تمامًا. انظر اقتراحات توقيع WAF أدناه.
  6. تطبيق حارس mu-plugin (إصلاح كود قصير الأجل)
    • تثبيت مكون إضافي صغير mu-plugin (مكون إضافي يجب استخدامه) يعترض طلبات AJAX لإجراء المكون الإضافي ويفرض التحقق من nonce والقدرات (مثال مرفق أدناه).
  7. راقب السجلات وارجع إذا لزم الأمر
    • إذا اكتشفت تغييرات خبيثة، استعد من نسخة احتياطية نظيفة تم إنشاؤها قبل الاختراق. احتفظ بالسجلات لأغراض الطب الشرعي.
  8. إخطار أصحاب المصلحة
    • إذا تم تعديل المحتوى، انشر بيانًا موجزًا إذا تأثرت بيانات العملاء أو المحتوى الحساس.

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


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

دلالات القاعدة عالية المستوى:

  • حظر أو تحدي الطلبات إلى admin-ajax.php متى:
    • معلمة الإجراء تساوي نقطة نهاية تصويت المكون الإضافي (على سبيل المثال،, "تصويت_ajax_reviews" أو "تقييم_نجمة_تصويت") و
    • الطلب لا يحتوي على رأس nonce صالح لـ WordPress أو ملف تعريف الارتباط (X-WP-Nonce أو X-XSRF-TOKEN) و/أو
    • الطلب ينشأ من عنوان IP بحجم غير عادي.

مثال على قاعدة مشابهة لـ ModSecurity (كود زائف - قم بتكييفه مع منصتك):

# حظر إجراء تصويت admin-ajax بدون nonce لـ WP"

بديل: حظر جميع طلبات POST إلى admin-ajax.php مع الإجراء المستهدف ما لم يكن هناك رأس مرجع محدد أو nonce موجود. كن حذرًا: حظر admin-ajax.php عالميًا يمكن أن يكسر مكونات إضافية أخرى؛ حدد نطاق القاعدة للإجراء (الإجراءات) الدقيقة.

توقيع المراقبة (سجل فقط):

  • سجل الطلبات التي تتطابق مع الإجراء وحيث current_user هو مشترك (إذا كان متاحًا) أو يفتقر إلى رأس nonce؛ تصعيد إذا حدثت أحداث متعددة من نفس IP.

تحديد المعدل:

  • تنفيذ تحديد معدل الطلبات على نقاط نهاية الإجراء المستهدف لتقليل الإساءة.

ملاحظة: يمكن أيضًا ضبط WAFs لإرجاع تحدي CAPTCHA أو 401. اختر الخيار الأقل إزعاجًا الذي لا يزال يحظر حركة المرور الآلية الخبيثة.


تصحيح آمن قصير الأجل (mu-plugin)

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

إنشاء ملف wp-content/mu-plugins/wpfw-ajax-guard.php والصق:

<?php <= 0 ) {

ملحوظات:

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

إصلاحات طويلة الأجل وإرشادات للمطورين

إذا كنت مطور مكون إضافي (أو تبلغ مؤلف المكون الإضافي)، فهذه هي التغييرات الملموسة التي يجب تطبيقها لمنع التحكم في الوصول المكسور:

  1. لا تثق أبداً في المستخدم المعتمد بشكل ضمني
    • تحقق دائمًا من القدرات لأي إجراء يعدل المنشورات أو بيانات الموقع. استخدم يمكن للمستخدم الحالي ('تعديل المنشور'، $post_id) أو قدرة أكثر تقييدًا.
  2. تحقق من nonces بشكل صحيح
    • يستخدم check_ajax_referer( 'action_nonce_name', 'nonce_field', true ) داخل معالجات AJAX.
    • لنقاط نهاية REST، استخدم إذن_استدعاء_العودة وظائف تتحقق من القدرات وnonces/التوكنات.
  3. قم بتنظيف والتحقق من جميع المدخلات
    • اعتبر معرف المنشور كعدد صحيح (absint أو intval)، قم بتنظيف السلاسل، وتحقق من مفاتيح/قيم الميتا المسموح بها لضمان تحديثات مسموح بها فقط.
  4. استخدم بيانات معدة أو واجهات برمجة التطبيقات الخاصة بـ WordPress
    • عند التفاعل مع قاعدة البيانات، يفضل استخدام وظائف WP (wp_insert_post, تحديث_post_meta) وتنظيف البيانات قبل الإدخال.
  5. مبدأ الحد الأدنى من الامتياز
    • تجنب توفير وظائف تسمح للمستخدمين ذوي الامتيازات المنخفضة بتعديل المحتوى ما لم يكن هناك حالة عمل صارمة وموثقة جيدًا والتحقق من صحة صارمة.
  6. اختبارات الوحدة واختبارات التكامل
    • أضف اختبارات تضمن أن أدوار المشترك والمساهم لا يمكنها تنفيذ إجراءات مخصصة فقط للامتيازات الأعلى.
  7. مراجعة كود الأمان
    • أضف خطوة SAST آلية أو مراجعة يدوية على الإجراءات التي تكشف عن admin-ajax أو نقاط نهاية REST.
  8. الكشف المسؤول وإصلاح الثغرات
    • بمجرد أن تكون الإصلاحات جاهزة، اتبع جدول زمني للإفصاح، وأبلغ المستخدمين، وقدم تعليمات تحديث واضحة.

قائمة التحقق من تعزيز الأمان والمراقبة

بالنسبة لجميع مواقع WordPress، ضع في اعتبارك تحسينات الوضع التالية لتقليل التعرض لهذه الثغرات وما شابهها:

تعزيز الأمان

  • حافظ على تحديث جوهر WordPress والموضوعات والمكونات الإضافية.
  • حدد تسجيلات المستخدمين؛ إذا كان يجب عليك السماح بالتسجيل المفتوح، استخدم التحقق من البريد الإلكتروني ومنع البريد العشوائي بشكل فعال (reCAPTCHA، مصائد العسل).
  • قم بتعيين أذونات الملفات إلى مستوى أمان أساسي. أزل حق الوصول للكتابة عن الأدلة غير الضرورية.
  • فرض كلمات مرور قوية واستخدام المصادقة متعددة العوامل لأي حسابات ذات امتيازات مرتفعة.
  • قيد الوصول إلى admin-ajax.php حيثما كان ذلك ممكنًا (على سبيل المثال، حظر عناوين IP المسيئة المعروفة أو تحديد معدل الطلبات).

النسخ الاحتياطية والاسترداد

  • حافظ على نسخ احتياطية منتظمة ومعزولة واختبر الاستعادة. إذا حدثت أي تعديلات على المحتوى، يمكنك الاستعادة بسرعة.

الكشف والمراقبة

  • راقب سجلات الوصول وسجلات نشاط المسؤول. انتبه للطلبات POST إلى admin-ajax.php مع إجراءات غير معروفة.
  • سجل نشاط WP REST وAJAX في SIEM مركزي أو مضيف سجلات.
  • قم بتكوين تنبيهات لتغييرات المحتوى الجماعية أو أعداد كبيرة من مراجعات المنشورات.
  • قم بفحص البرامج الضارة بانتظام والتغييرات غير المنتظمة في الملفات.

استجابة الحوادث

  • أعد خطة للحوادث: عزل، الحفاظ على السجلات، الإصلاح، إبلاغ المعنيين، واستعادة الحالة المعروفة الجيدة.

خطط حماية WP‑Firewall — ابدأ بقوة مع الحماية الأساسية

ابدأ بقوة: احصل على حماية WP‑Firewall الأساسية (مجانية) اليوم

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

قارن الخطط بإيجاز:

  • أساسي (مجاني): جدار ناري مُدار، عرض نطاق غير محدود، WAF، ماسح للبرمجيات الخبيثة، تخفيفات OWASP العشرة الأوائل.
  • القياسية ($50/سنة): كل شيء في الخطة الأساسية، بالإضافة إلى إزالة البرمجيات الخبيثة تلقائيًا وإدارة القوائم السوداء/البيضاء لعناوين IP (حتى 20 عنوان IP).
  • المحترفة ($299/سنة): جميع ميزات القياسية، بالإضافة إلى تقارير أمان شهرية، تصحيح افتراضي تلقائي للثغرات، وإضافات مميزة مثل مدير حساب مخصص وخدمة أمان مُدارة.

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


الخاتمة والتوصيات النهائية

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

  1. تحقق من إصدار المكون المثبت لديك. إذا كان عرضة للخطر، قم بالتحديث فورًا إذا كان هناك تصحيح متاح.
  2. إذا لم يكن هناك تصحيح متاح بعد، قم بإلغاء تنشيط المكون أو تطبيق تصحيح افتراضي (قاعدة WAF أو mu-plugin).
  3. قم بمراجعة منشوراتك، والتعديلات، وحسابات المستخدمين بحثًا عن علامات التلاعب.
  4. طبق توصيات المطورين على المدى الطويل إذا كنت تحافظ على المكونات أو الشيفرات المخصصة.
  5. فكر في إضافة WAF مُدار وحمايات من البرمجيات الخبيثة (خطتنا الأساسية المجانية أو ما يعادلها) لتقليل فرصة الاستغلال.

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


موارد إضافية

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


wordpress security update banner

احصل على WP Security Weekly مجانًا 👋
أفتح حساب الأن
!!

قم بالتسجيل لتلقي تحديث أمان WordPress في بريدك الوارد كل أسبوع.

نحن لا البريد المزعج! اقرأ لدينا سياسة الخصوصية لمزيد من المعلومات.