اسم البرنامج الإضافي	صاروخ اجتماعي
نوع الضعف	البرمجة النصية عبر المواقع المتقاطعة
رقم CVE	CVE-2026-1923
الاستعجال	واسطة
تاريخ نشر CVE	2026-04-23
رابط المصدر	CVE-2026-1923

عاجل: CVE-2026-1923 — XSS مخزنة لمستخدم مصدق في صاروخ اجتماعي (<= 1.3.4.2) — ما يجب على مالكي مواقع ووردبريس القيام به الآن

تاريخ: 2026-04-23
مؤلف: فريق أمان WP‑Firewall

تم الكشف عن XSS مخزنة لمستخدم مصدق في صاروخ اجتماعي (<= 1.3.4.2) (CVE‑2026‑1923). تشرح هذه الإشعار المخاطر، سيناريوهات الاستغلال، خطوات الكشف وخطة تخفيف ذات أولوية — بما في ذلك التصحيح الافتراضي الفوري باستخدام WP‑Firewall — لمالكي مواقع ووردبريس والمديرين.

ملخص سريع: مشكلة XSS مخزنة تؤثر على إصدارات صاروخ اجتماعي <= 1.3.4.2 (CVE‑2026‑1923) تسمح لمستخدم مصدق لديه صلاحيات مشترك بإدخال حمولة عبر معلمة id الخاصة بالملحق، والتي يتم الاحتفاظ بها لاحقًا وتعرض بشكل غير آمن. تم تصحيح المشكلة في 1.3.5. إذا لم تتمكن من التحديث على الفور، اتبع التخفيفات أدناه لوقف الهجمات وتنظيف المواقع المتأثرة.

MD5/sha1 لهذه الإشعار: لا شيء — هذه إشعار حي من WP‑Firewall؛ يرجى اتباع الخطوات أدناه.

---

لماذا هذا مهم (بكلمات بسيطة)

XSS المخزنة هي واحدة من أخطر فئات ثغرات الويب عندما تحدث في مسارات الشيفرة حيث يتم تخزين المدخلات غير الموثوقة في قاعدة البيانات ثم تعرض في الصفحات التي يزورها مستخدمون آخرون — خاصة المديرين. في هذه الحالة:

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

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

---

ملخص تقني (ما أبلغ عنه الباحثون)

• نوع الثغرة: البرمجة النصية عبر المواقع المخزنة (XSS)
• المكون المتأثر: ملحق صاروخ اجتماعي لووردبريس
• الإصدارات المتأثرة: <= 1.3.4.2
• تم تصحيحه في: 1.3.5
• معرف CVE: CVE‑2026‑1923
• الامتياز المطلوب: مشترك (موثق)
• CVSS (كما تم الإبلاغ عنه): 6.5 (متوسط)
• تفاصيل الاستغلال: يقبل الملحق بطاقة تعريف معلمة في طلب يتم حفظها في قاعدة البيانات ثم يتم إرجاعها لاحقًا بدون هروب صحيح. يمكن لمهاجم لديه حساب مشترك تقديم حمولة تحتوي على HTML/JS والتي ستنفذ عندما يشاهد مستخدم ذو امتيازات أعلى أو أي زائر المحتوى.

ملحوظة: يختلف اسم نقطة النهاية الداخلية الدقيقة وعمود التخزين حسب بناء الملحق؛ النقطة المهمة هي أن بطاقة تعريف يتم استخدام المعامل للحفاظ على المحتوى وعرضه لاحقًا مع عدم كفاية التنظيف/الهروب.

---

سيناريوهات الاستغلال النموذجية

1. يقوم المهاجم بإنشاء حساب مشترك على الموقع المستهدف (أو اختراق واحد).
2. يحدد المهاجم ميزة مكشوفة بواسطة الإضافة تقبل بطاقة تعريف أو معامل مشابه (على سبيل المثال: تكوين زر المشاركة، إنشاء إدخال عبر واجهة الإضافة، أو استدعاء نقطة نهاية تكشفها الإضافة لـ AJAX).
3. يقوم المهاجم بحقن حمولة نصية (مثل،, <script>...</script> أو معالجات أحداث أكثر خفاءً) في ذلك المعامل. تقوم الإضافة بتخزينها في قاعدة البيانات.
4. عندما يفتح مسؤول (أو زائر عشوائي) صفحة الإدارة أو الواجهة الأمامية حيث يتم عرض ذلك المحتوى، يتم تنفيذ الحمولة في سياق متصفح ذلك المستخدم.
5. يمكن أن تشمل العواقب سرقة الكوكيز (إذا لم تكن الكوكيز HttpOnly)، تزوير الطلبات المعتمدة (CSRF)، إعادة توجيه المستخدمين، تثبيت أبواب خلفية بمستوى المسؤول عبر JS باستخدام الجلسات المعتمدة، أو إضافة محتوى ضار إلى الموقع.

لأن المهاجم يحتاج فقط أن يكون مشتركًا، فإن المواقع التي تسمح بالتسجيلات، أو لديها قوائم مستخدمين غير نشطة/غير مُدارة، تكون في خطر.

---

التأثير ولماذا يجب عليك التصرف بسرعة

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

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

---

قائمة الأولويات الفورية (60-120 دقيقة الأولى)

1. تحديد ما إذا كانت Social Rocket مثبتة وما إصدارها
   • لوحة التحكم -> الإضافات -> تحديد Social Rocket وتدوين الإصدار.
   • إذا كانت لوحة التحكم الخاصة بالاستضافة أو WP-CLI متاحة:
     • WP-CLI: قائمة إضافات ووردبريس --status=active | grep social-rocket
2. إذا تم تأكيد الضعف (<= 1.3.4.2)،, قم بالتحديث إلى 1.3.5 على الفور إذا كان متاحًا.
   • إذا لم تتمكن من التحديث على الفور (يتطلب اختبارًا)، قم بتطبيق التخفيفات المؤقتة أدناه.
3. كإجراء احترازي، قم بتعطيل الإضافة مؤقتًا:
   • المسؤول: الإضافات -> تعطيل Social Rocket.
   • أو WP‑CLI: wp إضافة تعطيل social-rocket
   • إذا كنت بحاجة إلى الميزة على الموقع ولا يمكنك تعطيلها، نفذ تصحيحًا افتراضيًا عبر قاعدة WAF على الفور (انظر تخفيفات WP‑Firewall أدناه).
4. راجع الحسابات التي تم إنشاؤها في آخر 30-90 يومًا بحثًا عن حسابات مشتركين مشبوهة؛ قم بتعليق أو إعادة تعيين كلمات المرور للمستخدمين المشبوهين.
5. قم بتشغيل فحص للبرامج الضارة (ماسح WP‑Firewall أو أي ماسح تستخدمه) وركز على البحث عن 6. أو HTML مشبوه تم إدخاله في خيارات الإضافة أو postmeta أو الجداول المخصصة.

---

الكشف: كيفية البحث عن الاستغلال النشط أو الحمولة المدخلة

ابحث في قاعدة بيانات WordPress عن أنماط محتوى مشبوهة. الأماكن الشائعة للتحقق:

• جدول wp_options (خيارات الموقع/الإضافة)
• wp_postmeta (حقول البيانات المرفقة بالمشاركات/الصفحات)
• wp_posts (محتوى_المشاركة)
• أي جداول محددة للإضافات (قد ينشئ Social Rocket خياراته أو إدخالات البيانات الخاصة به)

مقتطفات SQL مفيدة (قم بتشغيلها بحذر؛ دائمًا قم بعمل نسخة احتياطية من قاعدة البيانات أولاً):

ابحث عن علامات السكربت الشائعة:

SELECT option_name, option_value;

ابحث عن الحمولات المشفرة:

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value LIKE '%script%' OR meta_value LIKE '%<script>%';

إذا كانت الإضافات تخزن بأسماء مفاتيح تعرفها (مثل،, الاجتماعي_صاروخ_*) ابحث:

SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%sاجتماعي_صاروخ%';

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

---

تدابير قصيرة الأجل يمكنك تنفيذها على الفور

هذه مرتبة حسب السرعة + الفعالية.

1. قم بتحديث الإضافة إلى 1.3.5 (أو أحدث)
   • هذه هي الإصلاح النهائي. قم بالتحديث على جميع المواقع في أقرب وقت ممكن. اختبر على بيئة الاختبار إذا لزم الأمر، ولكن بالنسبة للمواقع الحرجة، أعط الأولوية للتحديث حتى لو كان عليك إيقاف تغييرات أخرى.
2. إذا لم تتمكن من التحديث على الفور، قم بإلغاء تنشيط الإضافة
   • أسرع وأضمن احتواء. كن على علم بفقدان الميزات.
3. تصحيح افتراضي مع قاعدة WP‑Firewall WAF (موصى به إذا كان يجب أن تظل الإضافة نشطة)
   • حظر أو تطهير الطلبات التي تحتوي على حمولة مشبوهة في بطاقة تعريف المعامل أو حظر الوصول إلى نقطة النهاية الضعيفة لأدوار المشتركين (وأقل).
   • مثال على قاعدة WAF العامة (كود زائف / نمط ModSecurity):

     # حظر الطلبات حيث تحتوي معلمة 'id' على علامات HTML أو نصوص برمجية <(script|img|iframe|svg|math|object|embed|on[a-z]+=|javascript:)"
     

   • بالنسبة لـ nginx مع ngx_lua يمكنك استخدام تعبير عادي على المعاملات وإرجاع 403 عند اكتشاف رموز HTML.
   • إذا كان WP‑Firewall يوفر واجهة مستخدم للقواعد المخصصة، أنشئ واحدة تحظر الطلبات حيث بطاقة تعريف تحتوي على علامات HTML أو أنماط JS مشبوهة.
4. تقييد نقاط نهاية المكونات الإضافية للأدوار الموثوقة (قائمة التحكم في الوصول الافتراضية)
   • إذا كانت نقطة النهاية المعرضة للخطر مخصصة فقط للمسؤولين، استخدم قواعد WAF للسماح فقط بعناوين IP الخاصة بالمسؤولين أو ملفات تعريف الارتباط الخاصة بالمسؤولين.
   • مثال (زائف):
     • إذا كانت REQUEST_URI تتطابق مع /wp-admin/admin-ajax.php و إذا كانت الإجراء يساوي الإجراء المعرض للخطر، فقم بمتطلبات التحقق من القدرة أو الحظر للدور == المشترك.
5. تنفيذ رأس سياسة أمان المحتوى (CSP) للتخفيف من تنفيذ النصوص البرمجية المضمنة
   • إضافة رأس (اختبر بدقة):

     سياسة أمان المحتوى: المصدر الافتراضي 'ذاتي'; مصدر السكربت 'ذاتي' https://trusted.cdn.com; مصدر الكائن 'لا شيء'; قاعدة URI 'ذاتي';

   • CSP مع غير آمن-مضمن تعطيل سيمنع تنفيذ النصوص البرمجية المضمنة المدخلة في العديد من المتصفحات (لكن CSP ليست بديلاً عن التصحيح).
6. تقوية ملفات تعريف الارتباط: تأكد من HttpOnly و SameSite تم تعيينها لتقليل وصول JS إلى ملفات تعريف الارتباط.
   • في wp-config.php أو عبر إعدادات الخادم، قم بتعيين علامات ملفات تعريف الارتباط للجلسة.
7. مراقبة وتنبيه
   • راقب 403s من قواعد WAF، والنشاط المفاجئ للمسؤولين، أو المستخدمين الجدد للمسؤولين.
   • تفعيل تسجيل WP‑Firewall والتنبيهات الفورية لأنماط XSS المحجوبة.

---

كيف يمكن أن يساعد WP‑Firewall (المواصفات الفنية)

كمنتج WAF وأمان مُدار، يقدم WP‑Firewall طبقات متعددة يمكن أن توقف الاستغلال حتى قبل تنفيذ الشيفرة:

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

إذا كنت تستخدم WP‑Firewall بالفعل، تأكد من تمكين التصحيح الافتراضي التلقائي وأن موقعك يحتوي على قواعد محدثة. إذا لم تكن تستخدم WP‑Firewall بعد، قم بتمكين WAF مُدار على موقعك حتى يتم تحديث المكون الإضافي.

---

إزالة الحمولات المخزنة الضارة (التنظيف)

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

خطوات التنظيف الموصى بها:

1. قم بأخذ نسخة احتياطية جديدة من قاعدة البيانات والملفات قبل إجراء التغييرات.
2. قم بتصدير الصفوف المشبوهة للفحص:

   SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%' INTO OUTFILE '/tmp/suspect_postmeta.csv';

3. استبدل أو أزل العلامات من الحقول المتأثرة باستخدام SQL أو عن طريق التصدير → التنظيف محليًا → إعادة الاستيراد. مثال على SQL لإزالة علامات السكريبت (أساسي؛ اختبر أولاً):

   UPDATE wp_postmeta;

4. ابحث في wp_options و wp_posts بنفس الطريقة ونظف.
5. إذا كنت تشك في اختراق حساب المسؤول، قم بتدوير جميع كلمات مرور المسؤول، وألغِ صلاحيات الجلسات:
   • قم بتغيير كلمات مرور المسؤول وأجبر جميع المستخدمين على تسجيل الخروج (يمكنك تغيير مفاتيح الملح في wp-config.php لإبطال جميع الجلسات).
6. تحقق من الملفات المرفوعة بحثًا عن webshells، وملفات PHP غير عادية في wp-content/uploads، وموارد القالب أو المكون الإضافي.
7. أعد الفحص باستخدام ماسح البرامج الضارة الخاص بك وتحقق يدويًا من الصفحات الحرجة.
8. إذا كان الهجوم معقدًا، احضر دعمًا جنائيًا.

---

توصيات تعزيز الأمان على المدى الطويل

1. مبدأ أقل الامتيازات للمستخدمين
   • يجب ألا يكون لدى المشتركين إمكانية التحميل أو التحرير أو القدرات المخصصة ما لم يكن ذلك ضروريًا بشكل صريح.
   • راجع التعليمات البرمجية المخصصة أو المكونات الإضافية التي تعزز امتيازات المشتركين.
2. مراجعة وتحديد قدرات الإضافات
   • بعض المكونات الإضافية تكشف عن نقاط نهاية AJAX أو إجراءات الواجهة الأمامية؛ يجب أن تتطلب هذه التحقق من القدرات التي تتناسب مع المستخدمين المقصودين.
3. تحديث تلقائي لرقع الأمان الحرجة
   • تكوين التحديثات التلقائية للإصدارات الأمنية الثانوية أو المكونات الإضافية الحرجة حيثما أمكن. بالنسبة للمكونات الإضافية الأكبر، اختبر في بيئة الاختبار.
4. الحفاظ على قائمة مسموح بها لميزات المكونات الإضافية الموثوقة / البرامج النصية الخارجية
   • تجنب البرامج النصية المضمنة من مصادر غير معروفة.
5. استخدام عملية إصدار مرحلية
   • اختبار تحديثات المكونات الإضافية في بيئة الاختبار مع فحوصات آلية قبل الدفع للعرض المباشر. ومع ذلك، يجب تطبيق إصلاحات الأمان بسرعة في الإنتاج.
6. فحوصات جدولة سلامة قاعدة البيانات
   • تشغيل فحوصات آلية بشكل دوري تبحث في قاعدة البيانات عن علامات البرامج النصية أو الأنماط المشبوهة وتنبه المسؤولين.
7. سياسة أمان المحتوى ورؤوس الاستجابة الآمنة
   • CSP و X‑Frame‑Options و X‑Content‑Type‑Options و Strict‑Transport‑Security تقلل من سطح الهجوم.
8. وجود دليل استجابة للحوادث
   • تحديد الخطوات لاحتواء وتخفيف وتنظيف والإبلاغ. تأكد من وجود شخص في الخدمة.

---

مثال: مقتطف تقوية الدور (functions.php في ووردبريس)

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

<?php

ملحوظة: كن حذرًا - أزل القدرات فقط إذا كانت موقعك لا تتطلبها حقًا لعمليات المشتركين.

---

مثال: WP‑Query للعثور على الصفحات المشبوهة (PHP)

إضافة أداة إدارية أو التشغيل من WP‑CLI لعرض المشاركات التي تحتوي على برامج نصية:

<?php
", get_the_ID(), get_the_title() );

---

الاختبار بعد التخفيف

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

---

للمطورين: كيفية البرمجة بشكل دفاعي ضد مشكلات مماثلة

1. اعتبر جميع المدخلات غير موثوقة - قم بتنظيف المدخلات وهرب المخرجات.
   • استخدم وظائف التنظيف المناسبة لنوع البيانات عند الحفظ (مثل sanitize_text_field للنص العادي).
   • دائمًا قم بالهروب عند المخرجات في قوالب WordPress: esc_html(), esc_attr(), wp_kses_post() حيثما كان ذلك ضروريًا.
2. تحقق من القدرات قبل حفظ أو عرض إعدادات المكون الإضافي الحساسة.
   • يستخدم current_user_can( 'manage_options' ) لميزات المسؤول فقط.
3. تجنب تخزين HTML الخام المقدم من المستخدمين ذوي الامتيازات المنخفضة. إذا كان يجب عليك السماح بـ HTML، استخدم قائمة مسموح بها صارمة عبر wp_kses().
4. مراجعة نقاط نهاية AJAX وREST للتحقق من القدرات وتأكد من استخدام النونز.
5. اكتب اختبارات وحدة/تكامل تتضمن محاولات حقن XSS (اختبارات أمان آلية).

---

ماذا تفعل إذا وجدت دليلًا على الاستغلال

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

---

مجموعات قواعد WAF المقترحة لحظر نمط الهجوم هذا

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

1. حظر إذا كان المعرف يحتوي على علامات HTML (صارم):
   • القاعدة: إذا كان ARGS:id يحتوي على < متبوعًا باسم علامة HTML أو يحتوي على جافا سكريبت: أو معالجات أحداث نموذجية (عند حدوث خطأ=, عند النقر=, ، إلخ.) ثم حظر.
2. حظر أسماء إجراءات AJAX المعروفة بأنها تنتمي إلى Social Rocket عندما يكون دور الطالب هو المشترك:
   • القاعدة: إذا كان مسار الطلب يحتوي على admin-ajax.php و action=sr_* (استبدل بإجراء المكون الإضافي) وكان لدى المستخدم دور مشترك, ، حظر أو تطلب 2FA.
3. حظر أنماط الحمولة المخزنة XSS في أجسام POST عبر الموقع
   • القاعدة: حظر الطلبات التي تحتوي على <script + تسلسلات في POSTs أو أجسام الطلبات.

---

قالب الاتصال لمالكي المواقع والفرق

إذا كنت بحاجة للإبلاغ داخليًا أو إلى عميل:

الموضوع: عاجل - XSS المخزنة في مكون Social Rocket الإضافي (CVE‑2026‑1923) - إجراء مطلوب

النص:

• تم الكشف عن XSS المخزنة (CVE‑2026‑1923) التي تؤثر على Social Rocket <= 1.3.4.2.
• التأثير: يمكن للمشترك أن يحتفظ بالبرامج النصية الضارة التي تنفذ عندما يقوم المسؤولون/الزوار بعرض المحتوى.
• الخطوات الفورية المتخذة: [تحديث/تعطيل/تصحيح افتراضي] (قم بإدراج ما فعلته).
• الخطوات التالية المخطط لها: تنظيف قاعدة البيانات، فحص الموقع، تدوير بيانات الاعتماد، مراقبة سجلات WAF.
• الوقت المتوقع للإصلاح: [الإطار الزمني]
• الاتصال: [جهة الاتصال/الأمن]

---

جديد: جرب WP‑Firewall Basic (مجاني) — احمِ موقعك الآن

أنشأنا خطة أساسية مجانية حتى يتمكن مالكو المواقع مثلك من الحصول على حماية أساسية فورية دون أي عوائق ميزانية. إليك ما ستحصل عليه مع خطة Basic (مجانية):

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

ابدأ في حماية موقعك اليوم (لا حاجة لبطاقة ائتمان): https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

---

التوصيات النهائية

1. قم بتحديث Social Rocket إلى الإصدار 1.3.5 (أو أحدث) على كل موقع على الفور.
2. إذا لم تتمكن من التحديث الآن، إما تعطيل المكون الإضافي أو تفعيل قاعدة WAF لحظر الحمولات الضارة في بطاقة تعريف المعامل والمدخلات ذات الأسماء المماثلة.
3. قم بمراجعة نشاط المشتركين الأخير، وفحص قاعدة البيانات للبرامج النصية المخزنة وتنظيفها.
4. تعزيز حدود أذونات المستخدم وتمكين رؤوس الأمان مثل CSP.
5. استخدم خطة WP‑Firewall المجانية للحصول على حماية أساسية وتصحيح افتراضي أثناء عملك على التحديثات والتنظيفات.

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

---

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