اسم البرنامج الإضافي	منشئ نماذج الاتصال المتجاوبة في ووردبريس وملحق توليد العملاء المحتملين
نوع الضعف	البرمجة النصية عبر المواقع (XSS)
رقم CVE	CVE-2026-1454
الاستعجال	واسطة
تاريخ نشر CVE	2026-03-14
رابط المصدر	CVE-2026-1454

عاجل: ثغرة XSS المخزنة غير الموثقة في نموذج الاتصال وملحق نموذج العملاء المحتملين Elementor (CVE-2026-1454) — ما يجب على مالكي مواقع ووردبريس القيام به الآن

مؤلف: فريق أمان جدار الحماية WP
تاريخ: 2026-03-12

ملخص: تم الكشف عن ثغرة XSS المخزنة وغير الموثقة التي تؤثر على ملحق نموذج الاتصال وملحق نموذج العملاء المحتملين Elementor (الإصدارات <= 2.0.1) وتم تعيينها CVE-2026-1454. تم إصلاح المشكلة في الإصدار 2.0.2. يشرح هذا المنشور المخاطر، وكيف يستغلها المهاجمون، وكيفية التأكد مما إذا كانت مواقعك متأثرة، وإرشادات الإصلاح والتعافي خطوة بخطوة — من منظور فريق أمان ووردبريس.

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

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

---

ما حدث (باختصار)

تم الكشف عن ثغرة XSS المخزنة لملحق ووردبريس “نموذج الاتصال ونموذج العملاء المحتملين Elementor” التي تؤثر على الإصدارات حتى 2.0.1 بما في ذلك. يسمح ذلك لمهاجم غير موثق بحقن JavaScript في البيانات المخزنة التي سيتم تنفيذها لاحقًا في متصفح المسؤول أو زائر الموقع. تم تصحيح الملحق في الإصدار 2.0.2. يتم تتبع الثغرة كـ CVE-2026-1454 ولها شدة مشابهة لـ CVSS التي قيمها العديد من المراقبين على أنها متوسطة (7.1).

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

لماذا هذا الأمر خطير (أثره في العالم الحقيقي)

XSS المخزنة خطيرة لأن الحمولة المدخلة تبقى على الخادم وتنفذ كلما تم عرض الصفحة الضعيفة أو واجهة الإدارة المحتوى المخزن. تشمل العواقب:

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

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

التفاصيل الفنية (كيف يمكن استغلال ذلك)

على مستوى عالٍ: فشل المكون الإضافي في تنظيف أو ترميز بعض البيانات المقدمة من المستخدم بشكل صحيح قبل تخزينها أو عرضها. يمكن لمهاجم غير مصادق عليه تقديم بيانات نموذج تحتوي على JavaScript (على سبيل المثال، 6. علامة أو سمة مثل onerror="..."). نظرًا لأن البيانات مخزنة وتظهر لاحقًا على صفحة أو واجهة إدارية دون هروب المخرجات، يقوم المتصفح بتنفيذ النص البرمجي كلما تم تحميل ذلك العرض.

المتجهات الشائعة لـ XSS المخزنة في مكونات نماذج الاتصال:

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

تبدأ الحمولة النموذجية صغيرة (على سبيل المثال،, <img src="x" onerror="">) وتتوسع إلى كود سرقة الجلسات أو استدعاءات AJAX إلى بنية المهاجم التحتية.

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

كيفية التحقق مما إذا كنت متأثرًا (فحوصات سريعة واكتشاف)

1. إصدار المكون
   – قم بتسجيل الدخول إلى إدارة WordPress الخاصة بك → الإضافات وتحقق من اسم الإضافة والإصدار.
   – WP‑CLI: قم بتشغيل

   wp plugin get lead-form-builder --field=version

   (استبدل اسم الإضافة بالاسم الفعلي إذا كان مختلفًا في تثبيتك.)
   – إذا كان الإصدار <= 2.0.1، فأنت متأثر. قم بالتحديث إلى 2.0.2 على الفور.

2. ابحث عن محتوى مشبوه في الإدخالات الأخيرة
   – ابحث في الطلبات وإدخالات العملاء عن آثار XSS النموذجية:
     – سلاسل مثل "<script", "onerror=", "عند التحميل=", "جافا سكريبت:", "<img", "<svg":

   SELECT * FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%onerror=%' OR post_content LIKE '%javascript:%' ORDER BY post_date DESC LIMIT 50;

   العديد من إضافات نماذج الاتصال تخزن البيانات في جداول مخصصة أو في wp_posts/أنواع المنشورات المخصصة — تحقق من وثائق الإضافة الخاصة بك لمعرفة مكان تخزين الإدخالات.
   – بحث سريع باستخدام WP‑CLI (بدائي):

   wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%onerror=%' LIMIT 50;"

3. تحقق من شاشات الإدارة التي تعرض الإدخالات
   – افتح قوائم إدخالات العملاء، إدخالات نماذج الاتصال، وأي شاشات معاينة في الإدارة (يفضل من متصفح محصن أو حساب معزول).
   – إذا رأيت سكربتات غير متوقعة تنفذ (إعادة توجيه، نوافذ منبثقة) أو إذا تصرفت واجهة الإدارة بشكل غريب، افترض وجود اختراق.
4. قم بفحص موقعك
   – قم بتشغيل فحص كامل للبرمجيات الضارة وXSS (WP‑Firewall أو ماسحات أخرى). ابحث عن السكربتات المدخلة في ملفات القالب، التحميلات، وجداول قاعدة البيانات.

خطوات التخفيف الفورية (سريعة، عندما لا يمكنك التحديث)

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

1. قم بتمكين قاعدة WAF لمنع محاولات XSS المخزنة
   – قم بحظر POSTs الصادرة إلى نقاط النهاية الضعيفة التي تحتوي على علامات سكربت أو سمات خطيرة.
   – مثال على تعبير عادي عام لاكتشاف الحمولة الشبيهة بالسكريبت:
     – حظر عندما يتطابق جسم الطلب مع:

   ()|(\bon\w+\s*=)|javascript:|data:text/html
      

   – تنفيذ كجزء من قواعد WAF/edge الخاصة بك. ضبطها لتقليل الإيجابيات الكاذبة.

2. تعطيل الإضافة حتى تتمكن من التحديث
   – إذا كان ذلك عمليًا، قم بإلغاء تنشيط الإضافة من الإضافات > الإضافات المثبتة أو:

   wp إضافة تعطيل lead-form-builder

   – هذا يمنع تقديمات جديدة عبر مسار الكود المعرض للخطر.

3. تقييد الوصول إلى نقاط نهاية المكون الإضافي
   – إذا كانت نقطة نهاية التقديم تحت نمط URL معروف، قم بحظرها عبر قواعد خادم الويب (nginx/Apache) أو WAF بحيث يتم رفض POSTs غير المصرح بها.
4. إزالة التعرض العام مؤقتًا
   – استبدل نموذج الاتصال العام بصفحة اتصال ثابتة بسيطة أو نموذج Google حتى تقوم بالتحديث.
5. تعزيز وصول المسؤول
   – قيد الوصول إلى wp-admin عن طريق قائمة بيضاء لعناوين IP أو فرض الوصول عبر LDAP/VPN للمسؤولين حيثما كان ذلك ممكنًا.

قائمة مراجعة كاملة للإصلاح والتعافي (تسلسل موصى به)

1. تحديث الإضافة إلى النسخة المصححة (2.0.2)
   – أصدرت الشركة النسخة 2.0.2 مع إصلاح لهذا XSS المخزن. التحديث هو العلاج الأساسي.
   - WP-CLI:

   wp إضافة تحديث lead-form-builder --version=2.0.2

   (أو ببساطة wp إضافة تحديث lead-form-builder)

2. إذا كان لديك بالفعل إدخالات خبيثة مؤكدة، قم بإزالتها أو تطهيرها
   – تحديد الإدخالات المتأثرة (انظر استعلامات الكشف أعلاه).
   – تصدير السجلات المتأثرة للتحليل الجنائي، ثم إما تطهيرها أو الهروب من الأحرف المسيئة.
   – مثال على تطهير البيانات عبر SQL يعتبر محفوفًا بالمخاطر — يفضل استخدام سكربت يعمل wp_kses() أو تحديث_معلومات_المنشور() مع سلاسل مطهرة.
3. تحقق من علامات الاختراق المستمر
   – راجع دليل التحميلات (wp-content/uploads) بحثًا عن ملفات PHP غير متوقعة، أو JS مشوش.
   – افحص ملفات القالب والإضافات بحثًا عن تعديلات غير معروفة (طوابع زمنية، كود غير متوقع).

   التحقق من صحة مجموعات التحقق الأساسية في wp

   ملاحظة: هذا يتحقق فقط من النواة. بالنسبة للإضافات/القوالب، قارن مع نسخ نظيفة.

4. تدوير الأسرار والاعتمادات
   – غير جميع كلمات مرور المسؤول، خاصة إذا كنت تشك في أن XSS في لوحة الإدارة قد نفذ JS عشوائي.
   – أعد تعيين مفاتيح API، رموز OAuth، أسرار webhook التي قد تكون تعرضت.
   – قم بتدوير أملاح WordPress في wp-config.php — هذا يجبر على إبطال ملفات تعريف الارتباط للجلسات المسجلة.
5. راجع حسابات المستخدمين
   – ابحث عن مستخدمين جدد كمسؤولين أو حسابات بقدرات غير مصرح بها.

   wp user list --role=administrator

   – قم بإلغاء أو قفل الحسابات المشبوهة.

6. نظف واستعد إذا لزم الأمر
   – إذا وجدت تعديلات على الملفات أو أدلة على اختراق أعمق، استعد من نسخة احتياطية نظيفة تم إنشاؤها قبل الحادث.
   – عند الاستعادة، تأكد من تطبيق إصدار الإضافة المرقعة فورًا بعد الاستعادة.
7. عزز وراقب بعد الإصلاح
   – قم بتمكين التسجيل: سجلات الوصول، سجلات أخطاء PHP، وسجلات تدقيق على مستوى WordPress.
   – راقب تكرار POSTs المشبوهة أو ظهور نفس الحمولة مرة أخرى.
8. قم بإجراء تحليل بعد الحادث
   – قم بالتقاط وحفظ السجلات وتصديرات قاعدة البيانات.
   – وثق الجدول الزمني، مؤشرات الاختراق، والخطوات التي اتخذتها.
   – طبق الدروس المستفادة وقم بتحديث كتيبات الأمان.

تعزيز المراقبة لمنع تكرار الحوادث

تحسين الوضع على المدى الطويل لتقليل مخاطر XSS والمخاطر المماثلة:

• مبدأ الحد الأدنى من الامتياز
  تأكد من أن المستخدمين الضروريين فقط لديهم صلاحيات المسؤول. استخدم الأدوار بحذر.
• التحقق من المدخلات وترميز المخرجات
  يجب على المطورين التحقق من المدخلات ودائمًا الهروب من المخرجات عند عرض بيانات المستخدم (استخدم esc_html(), esc_attr(), wp_kses() حسب الاقتضاء).
• تطبيق سياسة أمان المحتوى (CSP)
  يقلل CSP الجيد من تأثير XSS من خلال منع السكربتات المضمنة والنطاقات الخارجية ما لم يتم السماح بها صراحة.
• حافظ على تحديث الإضافات والسمات
  استخدم التحديثات التلقائية للإصدارات الثانوية وإصدارات التصحيح حيثما أمكن. اختبر التحديثات الرئيسية في بيئة الاختبار.
• استخدم جدار حماية تطبيقات الويب (WAF)
  يمكن لجدار حماية التطبيقات (WAF) حظر أحمال XSS الشائعة ومنع محاولات الاستغلال من الوصول إلى تطبيقك.
• قم بتمكين المصادقة الثنائية (2FA) وإدارة الجلسات
  تقلل 2FA لجميع المسؤولين من خطر الاستيلاء على الحساب حتى لو تم كشف بيانات الاعتماد.
• فحص الأمان واكتشاف التغييرات
  قم بفحص البرامج الضارة، والثغرات، وتغييرات سلامة الملفات بانتظام.

استعلامات الكشف النموذجية وأفكار قواعد WAF

ملاحظة: قم بضبط القواعد لبيئتك لتجنب الإيجابيات الكاذبة.

أمثلة MySQL/SQL (ابحث في الجداول الشائعة)

• ابحث في محتوى wp_posts:

  SELECT ID, post_title, post_date;
  

• ابحث في جداول الإضافات المخصصة (استبدل اسم الجدول):

  SELECT * FROM wp_lead_entries WHERE message LIKE '%<script%' OR message LIKE '%onerror=%' LIMIT 200;
  

أمثلة WP‑CLI

• تصدير إدخالات المكون الإضافي للتفتيش:

  wp db query "SELECT * FROM wp_lead_entries WHERE 1" > lead-entries.sql
  

• قائمة إصدار الإضافة:

  wp plugin list --status=active --format=table
  

فكرة قاعدة WAF (تعبير منتظم مفاهيمي)

• حظر الطلبات التي تحتوي على أنماط XSS الشائعة في جسم الطلب أو المعامل:

  القاعدة: حظر إذا كان جسم الطلب أو المعامل يحتوي على: ()|(\bon\w+\s*=)|javascript:|<svg\b|]*onerror\s*=|data:text/html
  

• بالنسبة لـ nginx مع ModSecurity أو ما شابه، تنفيذها كمجموعة قواعد مناسبة مع شدة وتسجيل مناسبين.

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

كيف يساعد WP‑Firewall (ما نقدمه وكيف نوصي باستخدامه)

من منظور فريق WP‑Firewall، إليك كيف نساعد العملاء على الاستجابة بشكل أسرع وتقليل المخاطر المتعلقة بالثغرات مثل CVE‑2026‑1454:

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

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

ابدأ في الحماية مع WP‑Firewall Free (جربه اليوم)

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

• حماية أساسية: جدار ناري مُدار، عرض نطاق غير محدود، WAF، ماسح للبرامج الضارة، وتخفيف مخاطر OWASP Top 10.
• سهل التثبيت والتكوين — احصل على الحماية في دقائق، وليس أيام.

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

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

استجابة الحوادث — خطوات الاسترداد العملية (مفصلة)

إذا اكتشفت استغلالًا ناجحًا، اتبع هذه الخطوات بالترتيب:

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

منع هجمات تفاعل المستخدم

تتطلب بعض سيناريوهات XSS أن يقوم مستخدم مميز (مثل، مسؤول) بالنقر على رابط مصمم خصيصًا أو عرض صفحة إدارة معينة. احمِ المستخدمين المميزين عن طريق:

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

بعض التوصيات النهائية للمطورين ومالكي المواقع

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

الإغلاق - تصرف الآن، ثم حسّن الوضع

هذه الثغرة تذكير في الوقت المناسب: XSS المخزنة غير المصرح بها تمكن المهاجمين من الحفاظ على الشيفرة الخبيثة على موقعك واستهداف المسؤولين والزوار. الخطوة الفورية هي تحديث الإضافة إلى الإصدار 2.0.2. إذا لم تتمكن من التحديث على الفور، قم بنشر تدابير التخفيف: تعطيل الإضافة، حظر أنماط الاستغلال باستخدام WAF، تقييد wp-admin، وفحص الحمولة المدخلة.

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

الملحق: ملخص الأوامر والاستعلامات السريعة

• تحقق من إصدار المكون الإضافي (WP‑CLI):

  wp plugin get lead-form-builder --field=version
  

• تعطيل المكون الإضافي:

  wp إضافة تعطيل lead-form-builder
  

• تحديث المكون الإضافي:

  wp إضافة تحديث lead-form-builder
  

• البحث عن علامات السكربت في wp_posts:

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content RLIKE '<(script|img|svg|iframe|object)\\b' LIMIT 100;"
  

• قائمة مستخدمي المسؤولين:

  wp user list --role=administrator --fields=ID,user_login,user_email
  

• تدوير الأملاح (تحديث يدوي في wp-config.php ثم فرض تسجيل الخروج لجميع المستخدمين):
  - إنشاء أملاح جديدة في https://api.wordpress.org/secret-key/1.1/salt/ والصقها في wp-config.php.

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

ابقى آمنًا
فريق أمان WP‑Firewall