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

حرجة: تجاوز المسار + حذف دليل عشوائي في JetBackup / حارس النسخ الاحتياطي (CVE-2026-4853) — ما يحتاج مالكو مواقع ووردبريس لمعرفته وكيفية حماية أنفسهم

نُشرت: 17 أبريل، 2026
المكونات الإضافية المتأثرة: JetBackup / حارس النسخ الاحتياطي (اسم الإضافة: backup)
الإصدارات المعرضة للخطر: <= 3.1.19.8
الإصدار المصحح: 3.1.20.3
CVE: CVE-2026-4853
خطورة: منخفض (أولوية Patchstack: منخفضة، CVSS: 4.9) — لكن لا تنخدع: التأثير العملي يمكن أن يكون كبيرًا إذا حصل المهاجم على حساب مسؤول أو كان يتحكم فيه بالفعل.

كفريق خلف WP-Firewall، نتتبع ثغرات ووردبريس باستمرار وننصح مالكي المواقع والمطورين ومقدمي الاستضافة بالاستجابات العملية والأولوية. هذه الثغرة في JetBackup/حارس النسخ الاحتياطي هي تجاوز مسار مصدق يمكّن مستخدمًا بمستوى مسؤول من حذف أدلة عشوائية عبر قيمة مصممة في اسم الملف المعامل (الذي يتم إرساله عادةً إلى نقطة نهاية النسخ الاحتياطي/الحذف). تم الكشف عن العيب بشكل مسؤول وتم تصحيحه في الإصدار 3.1.20.3 — التحديث هو الحل الأبسط والأكثر فعالية. أدناه نقوم بتفصيل التفاصيل الفنية، سيناريوهات المخاطر الواقعية، استراتيجيات الكشف والتخفيف، قواعد تصحيح WAF العملية، خطوات الاستجابة للحوادث، وتوصيات تعزيز الأمان على المدى الطويل حتى تتمكن من التصرف بسرعة وثقة.

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

---

ملخص تنفيذي (قصير)

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

---

كيف تعمل الثغرة (نظرة عامة تقنية، شرح غير قابل للاستغلال)

على مستوى عالٍ، تنشأ الثغرة من عدم كفاية التحقق والتنظيف من قيمة يقدمها المستخدم اسم الملف المعامل الذي يستخدمه المكون الإضافي لبناء مسارات نظام الملفات للحذف. عندما يقوم المكون الإضافي ببناء مسار مثل:

/wp-content/plugins/backup/backup-files/

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

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

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

لأن استدعاءات الحذف يمكن أن تكون متكررة إذا استخدم كود التغليف تنفيذات rmdir المتكررة، يمكن أن يتصاعد التأثير من إزالة ملف واحد إلى مسح أدلة كاملة.

---

سيناريوهات الاستغلال والأثر العملي

بينما تتطلب الثغرة امتيازات المسؤول لتفعيلها، إليك طرق واقعية يمكن أن تصبح بها الثغرة تهديدًا عمليًا:

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

تشمل الآثار المحتملة:

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

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

---

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

إذا كانت موقعك يستخدم إضافة JetBackup / Backup Guard وتستضيف أو تحافظ على مواقع WordPress، فاتبع هذه القائمة المرجعية ذات الأولوية على الفور:

1. تحديث الإضافة إلى 3.1.20.3 أو أحدث.
   - هذا هو الإصلاح النهائي. قم بذلك أولاً على بيئة الاختبار، ثم الإنتاج. اختبر النسخ الاحتياطية/تدفقات الاستعادة بعد التحديث.
2. إذا لم تتمكن من التحديث فورًا:
   - قم بتعطيل الإضافة أو تعطيل وظيفة حذف النسخ الاحتياطية حتى يمكن تطبيق تصحيح.
   - قيد الوصول إلى /wp-admin/ ونقاط نهاية الإضافة إلى عناوين IP موثوقة حيثما أمكن.
   - تطبيق قواعد WAF مؤقتة (أمثلة وقوالب أدناه) لحظر الطلبات التي تحتوي على أنماط تجاوز المسار في اسم الملف 7. أو معلمات مشابهة.
3. تدوير بيانات اعتماد المسؤول وتمكين 2FA لجميع حسابات المسؤولين.
4. تحقق من النسخ الاحتياطية للموقع (خارج الموقع) وتأكد من أن لديك خطة استرداد مختبرة قبل إجراء التغييرات.
5. راقب السجلات بحثًا عن طلبات حذف مشبوهة وإزالة مفاجئة للملفات.
6. التواصل مع أصحاب المصلحة (مالك الموقع، المضيف، العمليات) وإعداد خطة استجابة للحوادث إذا تم اكتشاف عمليات حذف غير متوقعة.

---

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

ابحث عن العلامات التالية في سجلات الوصول، سجلات التدقيق، ونشاط نظام الملفات:

• طلبات HTTP تستهدف نقاط نهاية الإضافة التي تتعامل مع النسخ الاحتياطية أو حذف الملفات مع معلمات استعلام مثل اسم الملف, اسم الملف, ملف, الاسم أو أجسام POST تحتوي على أسماء. مثال على أنماط استعلام مشبوهة:
  • filename=../../
  • filename=....
  • fileName=wp-contentuploads
• الطلبات التي تحتوي على تسلسلات تجاوز المسار في أي معلمة:
  • ../
  • ..\\
  • المعادلات المشفرة في URL %2e%2e%2f أو %2e%2e%5c
• اختفاء مفاجئ للملفات أو الدلائل في wp-content أو uploads أو دليل النسخ الاحتياطي للإضافة.
• أحداث حذف ملفات غير متوقعة تم ملاحظتها في أدوات مراقبة نظام الملفات، أو ارتفاعات في عمليات “الحذف”.
• تسجيلات دخول المسؤول من عناوين IP / مواقع جغرافية غير عادية تليها طلبات إلى نقاط نهاية النسخ الاحتياطي.

أمثلة على قواعد الكشف (على مستوى عالٍ):

• مطابقة الطلبات حيث تكون معلمة تحمل اسمًا غير حساس لحالة الأحرف مثل اسم الملف, اسم الملف, ملف يحتوي على \.\./ أو %2e%2e%2f.
• مطابقة محتويات POST التي تحاول حذف أو إدارة النسخ الاحتياطية التي تتضمن تسلسلات تجاوز.
• تنبيه على rmdir أو unlink الأخطاء في سجلات الخادم التي تتوافق مع المسارات غير المتوقعة خارج الدليل الأساسي المسموح به.

أمر شل مفيد للعثور على العناصر المعدلة/المحذوفة مؤخرًا (تشغيل كمسؤول، بحذر):

# العثور على الملفات في الجذر الويب المعدلة في آخر 7 أيام (تعديل حسب الحاجة)

إذا كان لديك مراقبة سلامة الملفات (Tripwire، OSSEC، إلخ)، استخدم ذلك للعثور بسرعة على الحذف.

---

التصحيح الافتراضي وقواعد WAF (توقيعات عملية يمكنك تطبيقها الآن)

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

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

مثال على قاعدة نمط ModSecurity (مفاهيمي):

# Block requests where any argument named filename (case-insensitive) contains ../ or encoded variants
SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Block possible Backup plugin path traversal attempt', \
 chain"
SecRule ARGS "@rx (\.\./|\.\.\\||)" "t:none,deny,status:403"

مقتطف موقع Nginx (حظر سلاسل الاستعلام التي تحتوي على ../ في filename):

if ($arg_filename ~* "\.\./|") {
 return 403;
}
# Repeat for $arg_fileName or other param names

اقتراحات WAF/قائمة القواعد العامة:

• حظر أي طلب حيث تحتوي ARGS على أحرف تجاوز مسار مشفرة وحيث يستهدف الطلب نقطة نهاية حذف المكون الإضافي (على سبيل المثال، /wp-admin/admin-ajax.php?action=backup_delete أو مسار ajax محدد للمكون الإضافي).
• اكتشاف وحظر الحمولة ذات البايت الفارغ أو أحرف التجاوز المشفرة بـ Unicode.
• دمج اكتشاف الأنماط مع حدود المعدل وقيود الوصول إلى لوحة الإدارة.
• تسجيل الأحداث المحظورة مع رؤوس كاملة وجسم الطلب للمراجعة الجنائية.

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

---

مثال على كود تعزيز الأمان الآمن لمؤلفي المكونات الإضافية / فرق التطوير

إذا كنت تحافظ على تكامل مخصص أو تصحيح، تأكد من أن الجانب الخادم يستخدم التوحيد ويطبق بشكل صارم الدلائل الأساسية المسموح بها والقوائم البيضاء. أدناه هو نمط آمن لـ PHP في سياق WordPress (تنظيف اسم الملف والتحقق من المسار الحقيقي).

مهم: هذا هو كود عينة دفاعي لتوضيح التعامل الآمن؛ يجب على مؤلفي المكونات الإضافية التكيف والتنظيف والاختبار قبل النشر.

<?php

الفحوصات الرئيسية الموضحة:

• فحص القدرة (المستخدم الحالي)
• التحقق من nonce
• استخدام basename() أو قائمة بيضاء صارمة لمنع فواصل المسار
• استخدام realpath للتوحيد وفحص بادئة يضمن أن الهدف ضمن الدليل المسموح به

---

التخفيفات على مستوى المضيف التي يمكنك تطبيقها الآن

إذا كنت مضيفًا أو تدير الخادم، قم بتطبيق خطوات تعزيز إضافية التالية:

• قيد الوصول إلى منطقة الإدارة لعناوين IP الموثوقة عبر قواعد جدار الحماية أو قوائم وصول خادم الويب (حيثما كان ذلك عمليًا).
• يستخدم open_basedir للحد من عمليات PHP إلى الدلائل المسموح بها.
• قم بتكوين أذونات الملفات بحيث لا يمكن لمستخدم خادم الويب حذف ملفات النظام العشوائية (كن واعيًا لاحتياجات الإضافات والنسخ الاحتياطية).
• استخدم ملفات تعريف SELinux أو AppArmor لعزل عمليات WordPress والحد من الوصول إلى الملفات.
• قم بتمكين تدقيق على مستوى العمليات (auditd) لالتقاط عمليات حذف الملفات بواسطة عمليات PHP للتحليل الجنائي.
• استخدم النسخ الاحتياطية خارج الموقع (المخزنة خارج خادم الويب) لضمان استعادة آمنة حتى إذا تمت إزالة النسخ الاحتياطية على مستوى الموقع.

---

استجابة الحوادث: إذا كنت تشك في الاستغلال

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

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

---

توصيات طويلة الأجل وأفضل الممارسات

لتقليل فرصة تسبب هذا النوع من الثغرات في أضرار كبيرة في المستقبل، اتبع هذه المبادئ:

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

---

أمثلة عملية لقواعد WAF (المزيد)

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

1. حظر عام على أحرف التنقل في اسم الملف المعامل (مفاهيمي):
   • الشرط: الطلب يحتوي على اسم معلمة يتطابق مع (?i:file(Name)?) والقيمة تتطابق مع أنماط التنقل.
   • الإجراء: حظر وتسجيل.
2. تقييد إجراء AJAX المحدد للإضافة (إذا كانت الإضافة تستخدم admin-ajax):
   • حظر أي استدعاءات admin-ajax مع action=backup_delete ما لم يكن الطلب صادرًا من عناوين IP المسموح بها أو يحتوي على nonce صالح للموقع.
3. حظر التنقل المشفر:
   • اكتشاف كل من التسلسلات الخام (../) والتسلسلات المشفرة في URL (%2e%2e%2f, /) ونسخ Unicode.
4. تحديد معدل الطلبات:
   • حصر الإجراءات المدمرة (حذف نقاط النهاية) إلى عدد منخفض في الدقيقة لكل حساب إداري أو عنوان IP.

---

لماذا التحديث حتى لو كان CVSS يبدو “منخفضًا”؟

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

اعتبر أيضًا:

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

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

---

استعلامات التنبيه والمراقبة النموذجية

• تنبيه عند قيام مستخدم إداري بتنفيذ استدعاء حذف يستهدف نقاط نهاية المكونات الإضافية مع ../ في المعلمات.
• تنبيه عند إزالة أعداد كبيرة من الملفات من wp-content/uploads أو مجلدات النسخ الاحتياطي للمكونات الإضافية.
• ملخص يومي: قائمة بحذف الملفات التي بدأت بواسطة عمليات PHP-FPM في جذر الويب.

مثال على loggrep بسيط للعثور على الطلبات المشبوهة (Apache/Nginx):

# Look for traversal patterns in access logs
grep -E "(filename|fileName|file)=.*(\.\./|)" /var/log/nginx/access.log | tail -n 200

---

بعد التصحيح: تحقق وصدق

بعد تحديث المكون الإضافي إلى 3.1.20.3 (أو أحدث)، تحقق من:

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

---

الجدول الزمني والإفصاح المسؤول (باختصار)

تم تحديد هذه الثغرة الأمنية والإبلاغ عنها للبائع قبل الإفصاح العام. أصدر البائع تصحيحًا في 3.1.20.3. تم تخصيص CVE-2026-4853 لتتبع المشكلة. نوصي دائمًا بالتحديث إلى الإصدار المصحح كإجراء أساسي.

---

مثال عملي: ماذا يجب أن يفعل مسؤول الاستضافة في 15-60 دقيقة

إذا كنت مسؤول استضافة أو مالك موقع تستيقظ على هذا الإشعار، إليك “دليل أول 60 دقيقة” القصير:

0-10 دقيقة:

• تحديد المواقع المتأثرة (الإضافة مثبتة والإصدار <= 3.1.19.8).
• إبلاغ المعنيين (مالكي المواقع، العمليات).

10-30 دقيقة:

• إذا كان التحديث الفوري ممكنًا، قم بتحديث الإضافة في البيئة التجريبية ثم في الإنتاج.
• إذا لم تتمكن من التحديث، قم بتعطيل الإضافة و/أو تقييد الوصول إلى نقاط نهاية الإدارة عبر قائمة السماح IP.

30-60 دقيقة:

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

---

ملاحظات نهائية - موازنة العجلة مع السلامة

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

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

---

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

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

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

راجع تفاصيل الخطة وسجل هنا: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

الإغلاق: ما نوصي به، بالترتيب

1. تحديث JetBackup / Backup Guard إلى الإصدار 3.1.20.3 أو أحدث على الفور.
2. إذا لم تتمكن من التحديث على الفور، قم بتطبيق قواعد WAF لحظر تجاوز المسار في اسم الملف/اسم الملف المعلمات وتقييد وصول المسؤول.
3. قم بتدوير بيانات اعتماد المسؤول، وتمكين 2FA، ومراجعة قائمة مستخدمي المسؤولين للحسابات غير المعروفة.
4. تحقق من النسخ الاحتياطية خارج الموقع واختبر الاستعادة.
5. قم بتقوية إعدادات الخادم (open_basedir، SELinux/AppArmor، أذونات صارمة) واعتبر قدرات التصحيح الافتراضي للتخفيف السريع في المستقبل.
6. حافظ على تسجيل الدخول، والمراقبة، وقائمة مراجعة استجابة الحوادث حتى تتمكن من التصرف بسرعة إذا حدث أي شيء مريب.

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

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