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

عاجل: ثغرة في التحكم بالوصول (CVE-2026-1934) في موتورز - إضافة وكالة سيارات وإعلانات مصنفة (<= 1.4.103)

تم النشر: 11 مايو، 2026 - إشعار أمان WP-Firewall

تم الكشف عن ثغرة في التحكم بالوصول تؤثر على إضافة موتورز - وكالة سيارات وإعلانات مصنفة في ووردبريس (جميع الإصدارات حتى 1.4.103 بما في ذلك) (CVE‑2026‑1934). يمكن أن تسمح هذه المشكلة لمستخدم موثق ذو صلاحيات منخفضة (مشترك) بتجاوز ضوابط الدفع وتنفيذ إجراءات مميزة يجب أن تكون مقيدة للأدوار الأعلى أو لردود الدفع الموثقة.

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

المحتويات

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

---

ماذا حدث - ملخص قصير

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

أصدر البائع تصحيحًا في الإصدار 1.4.104. إذا كنت تستخدم الإصدار 1.4.103 أو إصدار أقدم، قم بالتحديث على الفور.

---

لماذا هذا مهم - التأثير وسيناريوهات الإساءة

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

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

على الرغم من أن الاستغلال يتطلب حسابًا موثقًا، إلا أن العديد من مواقع ووردبريس تسمح بإنشاء حسابات. تجعل هجمات التسجيل الآلي أو إدخال بيانات الاعتماد الوصول على مستوى المشتركين سهلاً للمهاجمين. لهذا السبب يجب عدم تجاهل حتى “الحد الأدنى” من CVSS.

---

الشرح الفني (ما الذي حدث بشكل خاطئ)

عادةً ما يعني التحكم في الوصول المكسور أحد الأمور التالية على جانب الخادم:

• عدم وجود فحوصات للقدرات (لا يوجد فحص للتأكد من أن المستخدم الحالي لديه دور/قدرة مطلوبة).
• عدم وجود فحوصات nonce/CSRF للإجراءات المعرضة عبر AJAX الإدارة أو REST.
• تسجيل مسار REST غير الآمن الذي يفتقر إلى permission_callback منطقي.
• منطق يثق في الحالة المقدمة من العميل (على سبيل المثال، تحديد حالة الدفع من معلمة POST) بدلاً من التحقق من ردود بوابة الدفع.

نمط غير آمن نموذجي (مبسط، ليس بالضرورة الكود الدقيق للإضافة):

// غير آمن: لا فحوصات للقدرة أو nonce

لماذا هذا غير آمن:

• أي مستخدم مسجل يمكنه الوصول إلى admin-ajax (أو مسار REST المعرض) يمكنه تنفيذ الإجراء وتغيير علامة الدفع.
• لا يوجد تحقق من أن البوابة أكدت الدفع.
• لا يوجد فحص لقدرة أو ملكية المستخدم الحالي، ولا nonce للتخفيف من CSRF.

تشمل الطريقة الآمنة:

• فحوصات قدرة مناسبة (أو فحوصات ملكية).
• التحقق من nonce (لـ AJAX).
• بالنسبة لنقاط نهاية REST، يجب أن يكون هناك permission_callback صارم يتحقق من المستخدم الحالي والقدرة المطلوبة.
• التحقق من حالة الدفع فقط بعد تأكيدات من خادم إلى خادم مع البوابة.

نمط آمن (توضيحي):

add_action('wp_ajax_motors_mark_paid', 'motors_mark_paid_secure');

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

---

إجراء فوري (ماذا تفعل الآن)

1. قم بالتحديث على الفور إلى الإصدار المصحح: 1.4.104 أو أحدث. هذه هي الإصلاح الوحيد المضمون.
2. إذا لم تتمكن من التحديث على الفور، اتخذ تدابير مؤقتة (مدرجة أدناه).
3. تحقق من تسجيلات المستخدمين ونشاط الحسابات الأخيرة بحثًا عن حسابات مشتركين مشبوهة.
4. راجع سجلات الطلبات/المدفوعات في لوحة معلومات بوابة الدفع الخاصة بك — قم بمطابقة علامات “مدفوع” في الموقع مع تأكيدات البوابة الفعلية.
5. ضع في اعتبارك تعطيل التسجيل العام حتى يتم تصحيح الموقع (إذا كان ذلك ممكنًا).

---

إذا لم تتمكن من التحديث على الفور - تدابير التخفيف على المدى القصير

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

• تعطيل تسجيل المستخدمين العام مؤقتًا:
  • الإعدادات → عام → قم بإلغاء تحديد “يمكن لأي شخص التسجيل”.
• تقييد الوصول إلى نقاط نهاية AJAX/REST الخاصة بالمكون الإضافي عبر قواعد جدار حماية تطبيق الويب (WAF) أو قواعد الخادم.
  • مثال: حظر الطلبات إلى admin‑ajax.php التي تحتوي على اسم الإجراء المحدد ما لم تكن قادمة من عناوين IP الإدارية أو أدوار محددة.
• تنفيذ حظر على مستوى الخادم للحمولات المشبوهة (انظر أمثلة WAF أدناه).
• تقييد قدرات المشتركين:
  • استخدم مكون إدارة الأدوار أو كود مخصص لإزالة أي قدرات غير أساسية من دور المشترك.
• المراقبة والتنبيه:
  • أضف مشغلات سجل لطلبات POST إلى نقاط النهاية التي تغير حالة الدفع/الإدراج.
• قم بتعطيل أو إلغاء تنشيط المكون الإضافي مؤقتًا إذا كانت ميزاته المدفوعة حاسمة ولا يمكن للموقع التحكم في الوصول.

استعادة قاعدة البيانات مؤقتًا: إذا اكتشفت علامات “مدفوعة” غير مصرح بها، يمكنك التراجع عنها. احتفظ بنسخ جنائية من السجلات التي تم تغييرها.

---

الكشف والتحقيق - كيفية معرفة ما إذا كنت قد تعرضت للاختراق

نقاط يجب التحقق منها:

• سجلات ووردبريس / سجلات خادم الويب:
  • ابحث عن طلبات POST إلى /wp-admin/admin-ajax.php أو مسارات REST للمكون الإضافي من حسابات ذات امتيازات منخفضة.
  • افحص معلمات الطلب مثل action=*, payment_status, paid, transaction_id.
• سجلات المكون الإضافي:
  • بعض المكونات الإضافية تسجل معالجة webhook الدفع؛ قارن تلك السجلات مع تغييرات بيانات الإدراج / الدفع.
• سجلات بوابة الدفع:
  • قم بمطابقة كل علامة “مدفوعة” على الموقع مع معاملات البوابة. الإدخالات المفقودة في البوابة هي علامة حمراء.
• استعلامات قاعدة بيانات ووردبريس:
  • ابحث في postmeta عن تحديثات مشبوهة حديثة: على سبيل المثال، meta_key مثل ‘motors_payment_status’ تم تحديثه مؤخرًا بواسطة مستخدم معرفه هو مشترك.
• نشاط WP-CLI:
  • استخدم wp-cli للعثور على المشاركات التي تم تعيينها كمدفوعة خلال فترة الحادث.

استعلامات WP-CLI مثال:

افحص القوائم التي تم وضع علامة عليها كمدفوعة مؤخرًا:

# قائمة معرفات المشاركات مع meta key 'motors_payment_status' = 'paid' وتم تحديثها مؤخرًا"

ابحث عن المستخدمين الذين تم إنشاؤهم في نفس الوقت تقريبًا:

wp user list --role=subscriber --field=user_email --format=csv --registered_after=2026-05-01

ابحث عن طلبات POST إلى نقاط النهاية المشبوهة في سجل وصول خادم الويب الخاص بك:

• admin-ajax.php مع معلمة action
• مساحة اسم REST للملحق (غالبًا /wp-json/motors/ أو ما شابه)

إذا وجدت سجلات مشبوهة:

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

---

أمثلة عملية على WAF / تصحيح افتراضي يمكنك تطبيقها الآن

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

1. حظر طلبات POST التي تحاول وضع علامة مدفوعة ما لم تشير الجلسة إلى امتياز أعلى
   - مستوى عالٍ: رفض طلبات POST إلى admin-ajax.php مع إجراء يتطابق مع إجراء الدفع للملحق عندما لا يكون المستخدم المسجل كمدير.

   مثال على قاعدة بأسلوب ModSecurity (توضيحي):

   # حظر استدعاءات admin-ajax.php مع action=motors_mark_paid من المستخدمين غير الإداريين"
   

   (قم بضبط اختبار الكوكيز ليتناسب مع كوكيز المصادقة الخاصة بك أو نمط الجلسة. هذا توضيحي - اختبر على بيئة الاختبار.)

2. حظر المكالمات المباشرة لـ REST إلى مساحة اسم الملحق للمستخدمين غير المميزين
   - إذا كان الملحق يكشف عن نقاط نهاية تحت /wp-json/motors/…، قم بإنشاء قواعد WAF لرفض أو تقليل طلبات POST المشبوهة في تلك المساحة.
3. تحديد معدل التسجيلات الجديدة
   - تقليل أو حظر إنشاء حسابات جماعية من نفس نطاق IP أو مع أنماط متطابقة.
4. فرض فحوصات المصادقة على جانب الخادم
   - يمكن أن ترفض رقعة افتراضية دفاعية الطلبات التي تغير الأعلام الحساسة ما لم يكن هناك رمز تحقق من الدفع من خادم إلى خادم.
5. رفض المحيلين غير المعروفين
   - حيثما كان ذلك مناسبًا، رفض إجراءات الإدارة المقدمة بدون محيلين مناسبين أو مع رؤوس nonce مفقودة.

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

---

قائمة التحقق من الإصلاح خطوة بخطوة (عملية)

1. النسخ الاحتياطي - قم بعمل نسخة احتياطية كاملة (الملفات + قاعدة البيانات). قم بتصدير السجلات للتحقيق الجنائي.
2. التحديث - قم بترقية مكون Motors إلى 1.4.104 أو أحدث على بيئة الاختبار؛ اختبر تدفقات الدفع والتكاملات الخاصة بك.
3. النشر - قم بنشر التحديث في الإنتاج خلال نافذة الصيانة بعد اجتياز الاختبارات.
4. التسوية - قارن جميع علامات “مدفوعة” في الموقع مع معاملات بوابة الدفع. قم بإرجاع أي عدم تطابق وأبلغ المستخدمين المتأثرين إذا كان ذلك مطلوبًا بموجب السياسة.
5. تعزيز:
   • تأكد من أن كود المكون يتحقق من ردود بوابة الدفع (التحقق من الخادم إلى الخادم).
   • أضف رموز غير متكررة وفحوصات صلاحية إلى أي نقاط نهاية AJAX.
   • بالنسبة للتكاملات المخصصة، تجنب العلامات الموثوقة من جانب العميل؛ تحقق من جانب الخادم.
6. المراقبة - أضف قواعد IDS/WAF لتسجيل وتنبيه المكالمات إلى نقاط النهاية الحساسة.
7. تغيير بيانات الاعتماد - إذا كنت تشك في وجود اختراق أوسع، قم بتغيير كلمات مرور المسؤول، مفاتيح API، وأسرار webhook لبوابات الدفع.
8. تدقيق الأدوار - تأكد من أن دور المشترك ليس لديه صلاحيات مرتفعة تتجاوز ما هو مطلوب.
9. التواصل - إذا تأثرت بيانات المستخدم أو المدفوعات، اتبع خطة التواصل الخاصة بالحادثة والالتزامات القانونية/التنظيمية.

---

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

• مبدأ الحد الأدنى من الامتيازات
  امنح المستخدمين الحد الأدنى من الصلاحيات المطلوبة. يجب ألا يتمكن المشتركون من تغيير حالات الدفع.
• التحقق من جانب الخادم للمدفوعات
  قم بتحديد الطلبات/العلامات المدفوعة فقط بعد التحقق الناجح من الخادم إلى الخادم من بوابة الدفع (التحقق من webhook، فحوصات حالة المعاملة).
• حماية نقاط النهاية باستخدام رموز غير متكررة واستدعاءات صلاحية
  يجب أن يتحقق كل إجراء مكشوف لمتصفح من رمز غير متكرر أو أن يكون لديه استدعاء صلاحية صارم على مسارات REST.
• مراجعات الكود والفحص الأمني الآلي
  تضمين فحوصات الأمان لمنطق الصلاحية ووجود الرموز غير المتكررة في مراجعات كود المكون.
• الاختبار الآلي والتهيئة
  تطبيق التحديثات على بيئة التهيئة وتشغيل اختبارات آلية شاملة للمدفوعات وسير العمل الحيوية.
• التسجيل والتنبيه
  تسجيل جميع المكالمات التي تغير حالة الدفع/الطلب وإنشاء تنبيهات عن التباينات مع سجلات البوابة.
• WAF & التصحيح الافتراضي
  استخدام قواعد WAF للتخفيف من الثغرات بين الاكتشاف والتصحيح.
• خطة النسخ الاحتياطي والاسترداد
  وجود جداول نسخ احتياطي آلية وكتيبات استرداد.
• مراقبة التسجيلات وسلوك الحسابات المشبوهة
  استخدام التحقق من البريد الإلكتروني، CAPTCHA، أو التحقق بخطوتين للعمليات الحيوية.

---

كيف يساعد WP‑Firewall (وكيف تبدأ)

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

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

جديد على WP‑Firewall؟ نقدم خطة أساسية مجانية توفر حماية أساسية تشمل جدار حماية مدارة، حماية غير محدودة للنطاق الترددي، WAF الأساسي، ماسح البرمجيات الضارة، والتخفيف من مخاطر OWASP Top 10 — نقطة انطلاق عملية للمواقع الصغيرة والمتوسطة.

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

(أبرز ملامح الخطة)
- أساسي (مجاني): جدار حماية مدارة، نطاق ترددي غير محدود، WAF، ماسح البرمجيات الضارة، التخفيف من OWASP Top 10.
- قياسي ($50/سنة): يضيف إزالة البرمجيات الضارة التلقائية وإدارة قوائم الحظر/السماح لعناوين IP.
- محترف ($299/سنة): يضيف تقارير شهرية، تصحيح افتراضي تلقائي للثغرات، وخيارات دعم متميزة.

---

عنوان فقرة التسجيل

احمِ موقعك بسرعة مع خطة WP‑Firewall المجانية

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

---

مثال على الجدول الزمني الجنائي (ما يجب جمعه)

• جمع سجلات وصول خادم الويب لفترة الحادث (IP، الطابع الزمني، خط الطلب، المحيل، وكيل المستخدم).
• تصدير سجلات المكون الإضافي أو تمكين تسجيل الأخطاء في المكون الإضافي قبل التراجع عن أي دليل.
• تفريغ صفوف postmeta لـ ‘motors_payment_status’ والمفاتيح ذات الصلة.
• تصدير صفوف جدول المستخدم والطوابع الزمنية للتسجيل للمشتركين الجدد.
• حفظ ملف CSV لمعاملات بوابة الدفع لنفس الفترة.

الاحتفاظ بنسخة من جميع هذه العناصر (تخزين آمن غير متصل) في حال الحاجة إلى مزيد من التحقيق أو اتخاذ إجراءات قانونية.

---

مثال على إصلاحات المطورين (توضيحي)

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

مثال على مسار REST:

register_rest_route( 'motors/v1', '/mark-paid', array(;

نقطة نهاية AJAX مع nonce:

add_action('wp_ajax_motors_mark_paid', 'motors_mark_paid_secure');

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

---

أسئلة مكررة

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

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

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

س: هل يمكن أن يكسر WAF استدعاءات الدفع الشرعية؟
أ: نعم - يمكن أن تمنع قواعد WAF المصممة بشكل سيء استدعاءات الويب الشرعية. اختبر القواعد في وضع المراقبة/السجل فقط أولاً؛ اسمح لنطاقات IP الخاصة بالاستدعاءات أو تحقق من التحقق من توقيع الاستدعاء لتجنب الإيجابيات الكاذبة.

---

كلمات أخيرة - كيف تعطي الأولوية لذلك على موقعك

1. قم بالتحديث إلى 1.4.104 أو لاحقًا على الفور. هذه هي الحل.
2. تسوية: تأكد من أن كل علامة “مدفوعة” تتطابق مع معاملة بوابة. ارجع واستقصِ عن التباينات.
3. طبق قواعد تصحيح WAF/افتراضية مؤقتة إذا لم تتمكن من التحديث على الفور.
4. عزز دورك وحماية نقاط النهاية الخاصة بك حتى تكون لمشاكل المكون الإضافي المستقبلية تأثير أقل.

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

احمِ تثبيتات WordPress الخاصة بك الآن - اعتبر إضافة WAF أساسي وماسح للبرامج الضارة أثناء جدولة واختبار تحديث المكون الإضافي.

---

احمِ موقعك بسرعة مع خطة WP‑Firewall المجانية

ابدأ بحماية أساسية (جدار ناري مُدار، WAF، مسح البرامج الضارة وتخفيف OWASP Top 10) دون تكلفة وأضف التصحيح الافتراضي أثناء تصحيح المكونات الإضافية:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

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