اسم البرنامج الإضافي	جدول على
نوع الضعف	حقن SQL
رقم CVE	CVE-2026-42755
الاستعجال	عالي
تاريخ نشر CVE	2026-06-01
رابط المصدر	CVE-2026-42755

عاجل: ثغرة حقن SQL في TableOn (<= 1.0.5.1) — ما يجب على مالكي مواقع WordPress القيام به الآن

مؤلف: فريق أمان WP‑Firewall

نُشر في: 2026-06-01

ملخص: تؤثر ثغرة حقن SQL عالية الخطورة (CVE-2026-42755، CVSS 9.3) على إصدارات مكون WordPress الإضافي TableOn <= 1.0.5.1. يمكن للمهاجمين غير المصرح لهم تشغيل SQL عشوائي ضد قاعدة بيانات موقعك. قم بتحديث المكون الإضافي إلى 1.0.6 على الفور. إذا لم تتمكن من التحديث على الفور، قم بتطبيق التصحيح الافتراضي / تدابير التخفيف من WAF واتبع خطوات الاستجابة للحوادث أدناه.

---

لماذا هذا مهم (إجابة قصيرة)

تحتوي إصدارات TableOn (posts-table / posts-table-filterable) حتى 1.0.5.1 بما في ذلك على ثغرة حقن SQL غير مصرح بها تسمح للمهاجمين بحقن SQL عشوائي في استعلامات قاعدة البيانات. هذه مخاطرة حرجة لأنها يمكن أن تؤدي إلى سرقة البيانات (سجلات المستخدم، طلبات التجارة الإلكترونية)، تصعيد الامتيازات (إنشاء مستخدمين إداريين)، تعديل المحتوى، أو اختراق كامل للموقع.

تم تعيين الثغرة CVE-2026-42755 وتحمل درجة CVSS تبلغ 9.3 — مما يعني أنها عالية الخطورة ومن المحتمل أن يتم تضمينها في حملات استغلال جماعية. إذا كنت تستضيف مواقع WordPress التي تستخدم TableOn، اعتبر ذلك حالة طوارئ.

---

من يجب أن يقرأ هذا؟

• مالكو المواقع والمديرون الذين يقومون بتشغيل WordPress مع مكون TableOn (posts-table-filterable)
• مضيفو WordPress المدارة والوكالات
• المطورون ومهندسو الأمن الذين يدعمون مواقع WordPress
• فرق أمان الموقع المسؤولة عن الكشف والتخفيف والاستجابة للحوادث

---

ماذا حدث (السياق والجدول الزمني)

• الإصدارات المعرضة للخطر: مكون TableOn <= 1.0.5.1
• الإصدار المصحح: 1.0.6 (قم بالتحديث على الفور)
• CVE: CVE-2026-42755 (عالية الخطورة — CVSS 9.3)
• الجدول الزمني للإفصاح: تم توثيق الثغرة علنًا ونشر التفاصيل في أواخر مايو 2026.

السبب الجذري هو بناء SQL غير آمن حيث يصل الإدخال المقدم من المستخدم إلى استعلام قاعدة البيانات دون التحقق الصحيح والمعايرة. في العديد من حالات حقن SQL في WordPress، يكون مسار الكود المعرض للخطر هو نقطة نهاية AJAX، أو نقطة نهاية REST، أو سمة shortcode تتم معالجتها دون استخدام استعلامات معلمة.

---

التأثير المحتمل (عواقب الاستغلال)

يمكن للمهاجم الذي يستغل هذه الثغرة في SQL:

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

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

---

إجراءات فورية (قائمة الأولويات - قم بذلك الآن)

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

---

كيفية معرفة ما إذا كنت قد تعرضت لهجوم (مؤشرات الاختراق)

ابحث عن واحد أو أكثر من ما يلي:

• حسابات المسؤول الجديدة أو غير المعروفة:
  • في إدارة ووردبريس → المستخدمون، ابحث عن الحسابات التي لم تقم بإنشائها.
• استعلامات قاعدة البيانات المشبوهة في السجلات:
  • استعلامات متكررة تحتوي على كلمات SQL الرئيسية (UNION، SELECT، INTO OUTFILE، SLEEP) عبر نقاط نهاية المكونات الإضافية.
• تغييرات غير متوقعة في المحتوى:
  • منشورات جديدة تم حقنها، روابط، إعلانات، أو خيارات معدلة.
• وجود ملفات ويب شل أو ملفات PHP مشوشة:
  • ملفات بأسماء مشبوهة، استدعاءات eval/base64_decode.
• زيادة في حركة المرور الصادرة أو ارتفاعات غير عادية في استخدام الموارد.
• ملفات مكونات إضافية/ثيمات معدلة مع طوابع زمنية لا تتطابق مع تغييراتك.
• مهام cron أو مهام مجدولة لم تقم بإنشائها.

أوامر الكشف السريع (للمضيفين/المستخدمين الفنيين):

• ابحث في الملفات عن ويب شل المحتمل:
  grep -R --line-number --color -E "eval\(|base64_decode\(|gzinflate\(" /path/to/wordpress
• تحقق من مستخدمي قاعدة البيانات/الخيارات المشبوهة:
  SELECT user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%cron%' OR option_name LIKE '%malware%' LIMIT 50;
• افحص السجلات بحثًا عن URIs مشبوهة:
  grep -E "posts-table|posts-table-filterable|tableon" /var/log/nginx/access.log | grep -E "UNION|SELECT|SLEEP|benchmark|information_schema|into outfile" -i

---

التخفيف المؤقت عبر WAF / التصحيح الافتراضي

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

• حظر طلبات HTTP إلى نقاط النهاية المعروفة للإضافة التي تتضمن معلمات استعلام أو أجسام طلب مستخدمة من قبل الإضافة (مثل، عناوين URL لـ AJAX). مفاهيم القواعد كمثال:
  • رفض الطلبات التي تحتوي على كلمات SQL الرئيسية في معلمات سلسلة الاستعلام: UNION SELECT، information_schema، INTO OUTFILE، SLEEP(، BENCHMARK(.
  • رفض الطلبات التي تحتوي على أنماط التكرار أو علامات التعليق المستخدمة في SQLi: ‘ OR ‘1’=’1، –، /*، */.
  • حظر الطلبات حيث يوجد مسار الإضافة ويتضمن الطلب أحرف SQL مريبة: --, ;, ' أو 1=1, UNION SELECT.
• تحديد معدل أو حظر الطلبات المريبة المتكررة من نفس عنوان IP.
• إضافة عناوين IP الإدارية الشرعية إلى القائمة البيضاء لنقاط النهاية الإدارية إذا كان ذلك ممكنًا.
• مراقبة وتسجيل الأحداث المحظورة للتحقيق.

أنماط مثال ModSecurity (مفاهيمي، تكيف مع جدار الحماية الخاص بك):

• حظر إذا كانت URI الطلب تحتوي على مسار الإضافة وَ تحتوي الاستعلام/الجسم على (غير حساسة لحالة الأحرف):
  • (union.*select|information_schema|into.?outfile|sleep\(|benchmark\(|\bor\b.+=?\b1\b)
• حظر علامات التعليق SQL المريبة عند العثور عليها في POST/GET بالقرب من معلمة الإضافة: --, /*, */

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

---

كيف يحميك WP‑Firewall (إذا كنت مستخدمًا لـ WP‑Firewall)

كمزود خدمة/جدار حماية ووردبريس مُدار يركز على الحمايات السريعة والعملية، نقدم:

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

إذا كنت تستخدم WP‑Firewall وموقعك متصل بخدمتنا، سنقوم بدفع تدابير للحد من توقيعات هجوم SQLi الخاص بـ TableOn ومراقبة أي محاولات استغلال ضد مواقعك.

---

كيفية إصلاح الكود (إرشادات لمطوري الإضافات)

إذا كنت مطورًا للإضافات أو تحافظ على كود مخصص يقوم بإنشاء عبارات SQL، اتبع هذه القواعد لمنع حقن SQL:

1. استخدم استعلامات معلمة / بيانات معدة
   • في WordPress، استخدم $wpdb->تحضير() للاستعلامات التي تتضمن إدخال المستخدم:

     $sql = $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}posts WHERE post_title = %s", $user_input );

   • تجنب دمج السلاسل مباشرة في SQL.
2. تحقق من المدخلات وتنظيفها
   • تأكد من أن القيم لها النوع والتنسيق المتوقع (عدد صحيح، شريحة، تعداد).
   • للأعداد الصحيحة استخدم (int) التحويل أو intval(); للشريحة استخدم sanitize_title(); للبريد الإلكتروني استخدم تعقيم البريد الإلكتروني.
3. الهروب حيثما كان ذلك مناسبًا
   • بالنسبة لمعرفات SQL الخام (أسماء الجداول أو أسماء الأعمدة) تجنب قبول إدخال المستخدم. إذا كان يجب عليك، تحقق من قائمة بيضاء للقيم المسموح بها ولا تستخدم الإدراج المباشر أبدًا.
4. تنفيذ فحوصات القدرة المناسبة وnonces
   • السماح فقط بالإجراءات الحساسة للقدرة الصحيحة (يمكن للمستخدم الحالي) وحماية نقاط النهاية التي تغير الحالة باستخدام nonces.
5. تفضل واجهات برمجة التطبيقات عالية المستوى في WordPress
   • استخدم WP_Query وواجهات برمجة التطبيقات الأخرى في ووردبريس عند الإمكان بدلاً من SQL الخام. هذه الواجهات تتعامل مع الهروب والمعلمات.
6. قم بتدقيق جميع نقاط الدخول
   • يجب مراجعة نقاط نهاية REST وadmin-ajax وسمات الشورت كود ومدخلات النماذج - جميعها يجب مراجعتها لاستخدام قاعدة البيانات المباشر.

مثال على الضعف مقابل الأمان (مفاهيمي):

ضعيف (لا تستخدم):

$search = $_GET['search'];

أكثر أمانًا:

$search = isset($_GET['search']) ? wp_unslash( $_GET['search'] ) : '';

---

دليل استجابة الحوادث (خطوة بخطوة)

إذا كنت تشك في الاستغلال، اتبع هذا الاستجابة المنظمة:

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

---

الكشف: ماذا تبحث عنه في السجلات والمعايير

• سجلات الوصول مع الحمولة التي تحتوي على كلمات SQL الرئيسية بالقرب من URI المكونات الإضافية.
• تكرار عالي لطلبات POST/GET إلى نقاط النهاية مثل admin-ajax.php أو مسارات REST مع شفرات المكونات الإضافية.
• استجابات 500 أو 200 مع حمولة كبيرة بشكل غير عادي تعيد محتوى قاعدة البيانات.
• زيادة في الاستعلامات التي تحتوي على information_schema أو عبارات select في سياقات غير متوقعة.
• أحداث محجوبة متكررة في جدار الحماية الخاص بك مع أنماط SQLi.

تأكد من أن سجلاتك تشمل جسم الطلب الكامل لفترة من الوقت بعد الحادث (كن واعيًا للخصوصية/الامتثال).

---

المراقبة الموصى بها وفحوصات ما بعد التصحيح

بعد تحديثك إلى 1.0.6:

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

---

الوقاية: تعزيز طويل الأمد لمواقع ووردبريس

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

---

للمضيفين والوكالات: توسيع أفضل ممارسات التخفيف

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

---

قائمة التحقق للمطورين (مراجعة الأمان قبل الإصدار)

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

---

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

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

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

س: هل يمكن للمهاجمين استغلال ذلك عبر عمليات المسح الآلي؟
ج: نعم - تعتبر ثغرات SQLi غير المصرح بها أهدافًا شائعة لماسحات البرمجيات الآلية والروبوتات. التخفيف السريع أمر ضروري.

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

---

مثال: أنماط الاستعلام الآمنة مقابل غير الآمنة (للمطورين)

غير آمن:

<?php

آمن:

<?php

---

ما توصي به WP‑Firewall الآن

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

---

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

العنوان: احمِ موقع WordPress الخاص بك في دقائق — جرب خطة WP‑Firewall المجانية

هل تريد حماية سريعة ومدارة بينما تتعامل مع التحديثات واستجابة الحوادث؟ يوفر خطة WP‑Firewall الأساسية (مجانية) الحمايات الأساسية التي تحتاجها كل موقع ووردبريس:

• جدار حماية مُدار وجدار حماية تطبيقات الويب (WAF)
• حماية النطاق الترددي غير المحدود
• فحص تلقائي للبرمجيات الضارة
• تدابير للتخفيف من مخاطر OWASP Top 10

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

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

---

أفكار ختامية

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

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

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

---

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