اسم البرنامج الإضافي	نموذج حجز أوقات WP
نوع الضعف	هجمات مستهدفة
رقم CVE	CVE-2026-48882
الاستعجال	عالي
تاريخ نشر CVE	2026-06-04
رابط المصدر	CVE-2026-48882

عاجل: ثغرة حقن SQL في نموذج حجز أوقات WP (≤ 1.2.50) — ما يجب على مالكي مواقع ووردبريس القيام به الآن

تم الكشف عن ثغرة حقن SQL عالية الخطورة (CVE-2026-48882) في إضافة ووردبريس “نموذج حجز أوقات WP” التي تؤثر على الإصدارات حتى 1.2.50 بما في ذلك. أصدرت الشركة نسخة مصححة 1.2.51. تم تقييم الثغرة بـ CVSS 8.5 وتصنيفها تحت OWASP A3: الحقن.

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

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

---

ملخص تنفيذي (سريع وقابل للتنفيذ)

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

---

ما حدث: ثغرة بلغة بسيطة

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

تم تعيين الإشعار العام CVE-2026-48882 لهذه المشكلة. أصدرت الشركة تصحيحًا في النسخة 1.2.51؛ يتضمن هذا التحديث إصلاحات تقوم بتنظيف وتهيئة الاستعلامات المسببة للمشكلة بشكل صحيح (أو إزالة مسارات الكود الضعيفة).

حقائق رئيسية:

• الملحق المتأثر: نموذج حجز أوقات WP
• الإصدارات الضعيفة: ≤ 1.2.50
• النسخة المصححة: 1.2.51
• التصنيف: حقن SQL (OWASP A3)
• CVE: CVE-2026-48882
• CVSS: 8.5 (عالي)
• الامتياز المطلوب للاستغلال: مستوى مشترك (امتياز منخفض)

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

---

لماذا هذا خطير لمواقع WordPress

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

---

من المحتمل أن يكون المتجه ونظرة عامة تقنية (ما يحتاجه المطورون وفرق الأمان لمعرفته)

عادةً ما تحتوي إضافات الحجز والفترات الزمنية على:

• نقاط نهاية AJAX في الواجهة الأمامية تقبل المعلمات (التواريخ، معرفات الفترات، مفاتيح البحث).
• نقاط نهاية إدارية وعامة تقرأ/تكتب الحجوزات.
• استعلامات قاعدة البيانات التي تقوم بتصفية المعلمات مثل slot_id، التاريخ، provider_id، إلخ.

عندما يقوم المطورون بإنشاء استعلامات SQL بشكل غير صحيح — عن طريق دمج المعلمات غير المعالجة في سلسلة الاستعلام — فإنهم يفتحون الباب أمام حقن SQL. في ووردبريس، الأنماط الصحيحة هي:

• استخدم $wpdb->prepare() لـ SQL الديناميكي
• استخدم العبارات المعدة وربط المعلمات
• قم بتحويل القيم الرقمية (int) والتحقق من القيم المعدودة
• استخدم دوال الهروب المناسبة (esc_sql فقط لهروب أجزاء SQL، وليس بديلاً عن العبارات المحضرة)
• نفذ فحوصات nonce وفحوصات القدرة عند تعديل حالة الخادم

قد يبدو النمط الضعيف مثل هذا (مثال غير آمن — لا تستخدمه):

// غير آمن: لا تستخدم;

سيكون النمط الآمن هو:

// آمن: استخدم prepare و cast;

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

---

سيناريوهات الاستغلال

يمكن للمهاجم:

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

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

---

مؤشرات الاختراق (IoCs) - ماذا تبحث عنه الآن

إذا استغل المهاجم الثغرة، قد ترى:

• حسابات مدير جديدة لم تقم بإنشائها (تحقق من wp_users و wp_usermeta).
• منشورات أو صفحات غير متوقعة (بريد مزعج/صيدلة/مزارع روابط).
• تغييرات في خيارات الموقع (تم تعديل siteurl/home، مفاتيح خيارات غير عادية).
• ملفات PHP غير معروفة في سمات، إضافات، أو دلائل التحميل (خصوصًا الملفات ذات المحتوى المشوش).
• مهام مجدولة غير معترف بها (wp_options > إدخالات cron).
• اتصالات صادرة من الموقع (استفسارات DNS غير عادية أو طلبات HTTP).
• زيادة في استخدام وحدة المعالجة المركزية/المدخلات أو أنماط حركة مرور غير عادية (ارتفاعات إلى نقاط نهاية محددة).
• استعلامات قاعدة بيانات مشبوهة تم تسجيلها بواسطة سجلات DB/التدقيق الخاصة بك (إذا كانت مفعلة).
• سجلات الأخطاء تظهر أخطاء SQL أو سجلات استعلامات غريبة.

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

---

خطوات التخفيف الفورية (ماذا تفعل الآن)

إذا كان موقعك يستخدم إضافة WP Time Slots Booking Form ويعمل بالإصدار ≤ 1.2.50، فاتبع هذه الخطوات على الفور:

1. قم بتحديث الإضافة إلى الإصدار 1.2.51 أو أحدث.
   • هذا هو الإصلاح النهائي. يجب أن يكون التحديث هو الخطوة الأولى.
2. إذا لم تتمكن من التحديث فورًا:
   • قم بإلغاء تنشيط الإضافة حتى تتمكن من التحديث، أو
   • قم بحظر الوصول إلى نقاط النهاية المعرضة للخطر (عبر .htaccess، قواعد Nginx، أو لوحة التحكم الخاصة بالاستضافة) بحيث يمكن فقط لعناوين IP الموثوقة الوصول إليها.
   • قم بتطبيق التصحيح الافتراضي عبر جدار حماية تطبيق الويب (WAF) إذا كان متاحًا - حظر الطلبات التي تحتوي على أحرف تحكم SQL أو أنماط مشبوهة إلى نقاط نهاية الحجز وقيّد معلمات POST/GET إلى أنماط معروفة وآمنة.
3. فرض إعادة تعيين كلمات المرور للمسؤولين وحسابات الامتياز الأخرى إذا كنت تشك في الاستغلال؛ قم بتدوير مفاتيح API وبيانات اعتماد قاعدة البيانات إذا كان هناك دليل على خرق.
4. النسخ الاحتياطي: قم بأخذ نسخة احتياطية كاملة (ملفات + قاعدة بيانات) واحفظها في وضع عدم الاتصال لأغراض الطب الشرعي.
5. فحص الموقع: قم بتشغيل ماسح ضوئي للبرامج الضارة محدث ومدقق سلامة الملفات.
6. تحقق من السجلات: سجلات خادم الويب، سجلات أخطاء PHP، وسجلات قاعدة البيانات للنشاطات والاستعلامات المشبوهة.
7. إذا وجدت اختراقًا، عزل الموقع (قم بإيقافه أو وضعه في وضع الصيانة)، واستشر محترف أمان لتنظيف وتحليل الطب الشرعي.

---

كيف يمكن أن تساعد WP-Firewall (التصحيح الافتراضي والحماية)

في WP-Firewall نتبع نهجين عندما تظهر ثغرة خطيرة مثل هذه:

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

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

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

---

كيفية التأكد من أن موقعك ليس معرضًا للخطر (التحقق)

1. التحقق من إصدار البرنامج المساعد:
   • إدارة WordPress: الإضافات > الإضافات المثبتة، أو
   • تحقق من ملف README الخاص بمجلد الإضافة أو رأس الإضافة للتحقق من الإصدار.
2. إذا كان إصدار الإضافة ≤ 1.2.50، اعتبر الموقع معرضًا للخطر.
3. تأكد مما إذا كانت الإضافة تعرض نقاط نهاية يمكن الوصول إليها علنًا:
   • ابحث عن نقاط نهاية AJAX التي تقبل المعلمات (تحقق من ملفات الإضافة عن wp_ajax_، wp_ajax_nopriv_، نقاط نهاية REST، أو معالجات النماذج المباشرة).
4. البحث عن رموز الأنماط غير الآمنة:
   • ابحث عن استخدامات $wpdb->get_results() أو $wpdb->query() حيث يتم دمج المعلمات في سلسلة نصية دون استخدام $wpdb->prepare().
5. راجع سجلات الموقع الأخيرة للوصول المشبوه إلى نقاط نهاية المكونات الإضافية.
6. بالنسبة للمضيفين: قم بتشغيل ماسح آلي يتحقق من وجود مؤشرات CVE-2026-48882.

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

---

إرشادات المطور - إصلاح الكود بالطريقة الصحيحة

إذا كنت مطورًا تقوم بصيانة المواقع أو المكون الإضافي نفسه، طبق هذه الممارسات الآمنة في البرمجة:

1. استخدم $wpdb->prepare() لجميع SQL الديناميكية:
   • لا تقم أبدًا بدمج مدخلات المستخدم الخام في الاستعلامات.
   • مثال:

   
   $id = isset($_REQUEST['id']) ? (int) $_REQUEST['id'] : 0; $row = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}my_table WHERE id = %d", $id ) );
     

2. تحقق من المدخلات بدقة:
   • قم بتحويل القيم الرقمية (int)، تحقق من قيم enum باستخدام القوائم البيضاء، قم بتنظيف السلاسل النصية باستخدام sanitize_text_field()، sanitize_email()، إلخ.
3. حدد القدرات واستخدم nonces:
   • تحقق من nonces لجميع إجراءات POST/التعديل.
   • تحقق من current_user_can( ‘capability’ ) قبل تنفيذ الإجراءات.
4. أقل امتياز لمستخدمي قاعدة البيانات:
   • يجب أن يكون لمستخدم قاعدة بيانات WordPress الخاص بك الامتيازات التي يحتاجها فقط.
5. تجنب كشف نقاط النهاية الإدارية للمستخدمين غير المصرح لهم أو ذوي الامتيازات المنخفضة:
   • إذا كانت الوظيفة يجب أن تكون عامة، أعد التفكير في ما تفعله نقطة النهاية وكيف يتم استرجاع البيانات.
6. استخدم العبارات المعدة أو وظائف WP لعمليات CRUD:
   • استخدم $wpdb->insert() و $wpdb->update() و $wpdb->delete() مع التنظيف المناسب حيثما كان ذلك ممكنًا.
7. مراجعة الكود و SCA:
   • استخدم تحليل الكود الثابت وتحليل تكوين البرمجيات في CI الخاص بك للإشارة إلى الأنماط غير الآمنة مبكرًا.
8. التسجيل والمراقبة:
   • سجل الاستعلامات السلبية وسلوك المستخدم. استخدم تسجيل مركزي وتنبيهات.

هذه الخطوات تمنع SQLi وعيوب الحقن الأخرى.

---

الاسترداد: ماذا تفعل إذا كنت تعتقد أن موقعك تم استغلاله

1. قم بإيقاف الموقع على الفور أو تفعيل وضع الصيانة لوقف المزيد من الأضرار أثناء التحقيق.
2. قم بعمل نسخة احتياطية جنائية كاملة (ملفات وقاعدة بيانات) قبل إجراء أي تغييرات.
3. غير جميع كلمات المرور وقم بتدوير الأسرار:
   • حسابات wp-admin و SFTP/SSH ولوحة الاستضافة وكلمة مرور مستخدم قاعدة البيانات ومفاتيح API.
4. افحص الملفات الضارة:
   • تحقق من الثيم والإضافات ودلائل التحميل بحثًا عن ملفات PHP غير معروفة أو طوابع زمنية معدلة.
   • ابحث عن كود مشوش (base64_decode و gzinflate و eval مع دمج المتغيرات).
5. افحص قاعدة البيانات بحثًا عن إدخالات مشبوهة:
   • wp_users لحسابات غير معروفة، wp_options لتعديلات malicious siteurl/home أو cron jobs غير المرغوب فيها، wp_posts لمحتوى البريد العشوائي.
6. استعد من نسخة احتياطية نظيفة إذا كانت متاحة ومعروفة بأنها جيدة.
7. إذا لم تتمكن من الاستعادة، قم بتنظيف يدوي وأعد تثبيت النواة والثيم والإضافات من نسخ جديدة من WordPress.org أو مصادر البائعين.
8. استعن بمحترف أمان إذا كان الهجوم متقدمًا:
   • الأبواب الخلفية المعقدة أحيانًا تبقى بعد التنظيف الساذج.
9. بعد التنظيف، راقب عن كثب لإعادة العدوى وقم بتدوير جميع المفاتيح والاعتمادات مرة أخرى.
10. وثق النتائج من أجل التحليل اللاحق والوقاية المستقبلية.

---

كيف يجب أن تستجيب المضيفين والوكالات

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

---

أفضل الممارسات على المدى الطويل لتقليل مخاطر ثغرات الإضافات

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

---

قائمة مراجعة نموذجية - إجراءات فورية لحماية موقعك

1. تحقق من إصدار الإضافة. إذا كان ≤ 1.2.50، قم بالتحديث إلى 1.2.51 الآن.
2. إذا لم تتمكن من التحديث: قم بإلغاء تنشيط الإضافة أو حظر الوصول إلى نقاط نهاية الإضافة.
3. تمكين قواعد WAF لحظر محاولات حقن SQL وأنماط المعلمات المشبوهة.
4. قم بعمل نسخة احتياطية من الموقع (الملفات + قاعدة البيانات).
5. فحص الموقع بحثًا عن مؤشرات الاختراق.
6. تدوير بيانات الاعتماد وإعادة تعيين كلمات مرور المسؤول إذا تم العثور على نشاط مشبوه.
7. مراجعة حسابات المستخدمين للعثور على حسابات المسؤول الجديدة أو المعدلة.
8. إذا تم اختراقها، عزلها، احتوائها، وإجراء مراجعة جنائية.

---

مقتطف كود مفيد - استعلام قاعدة بيانات آمن في ووردبريس

global $wpdb;

تحقق دائمًا من المدخلات وصححها، ثم استخدم $wpdb->prepare() مع العناصر النائبة المناسبة.

---

فقرة العملاء الجدد - ابدأ في حماية موقعك مجانًا

قم بتأمين موقع ووردبريس الخاص بك اليوم مع خطة الحماية المجانية لدينا

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

(الترقية لاحقًا سلسة - تضيف مستوياتنا المدفوعة إزالة البرمجيات الضارة تلقائيًا، حظر/إدراج IP، تقارير شهرية، تصحيح افتراضي تلقائي، وخدمات مُدارة إذا كنت تريد المزيد من الدعم.)

---

كلمات أخيرة من WP‑Firewall (إغلاق عملي)

الحوادث الأمنية مثل CVE-2026-48882 تذكرنا بأن المكونات الإضافية المستخدمة بشكل شائع يمكن أن تحتوي على ثغرات خطيرة. نظرًا لأن هذا الحقن SQL يتطلب فقط امتيازات المشتركين، فإن نافذة التعرض واسعة ويمكن أتمتة الاستغلال. الإجراءات الأسرع والأكثر أمانًا بسيطة: قم بتحديث المكون الإضافي إلى 1.2.51، أو قم بتعطيله و/أو تطبيق تصحيح افتراضي عبر WAF الخاص بك. بعد ذلك، قم بإجراء فحص دقيق لمؤشرات الاختراق وقم بتقوية موقعك مع الضوابط التطويرية والتشغيلية الموصى بها أعلاه.

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

---

قائمة مرجعية سريعة (صفحة واحدة)

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

---

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

— فريق WP‑Firewall