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

عاجل: ثغرة XSS المخزنة غير الموثقة في مكون Name Directory (≤ 1.32.1) — ما يجب على مالكي مواقع WordPress القيام به الآن

تاريخ: 12 مارس، 2026
CVE: CVE-2026-3178
خطورة: متوسط (CVSS 7.1)
الإصدارات المتأثرة: مكون Name Directory ≤ 1.32.1
تم تصحيحه في: 1.33.0

كخبير أمان WordPress يعمل مع فريق WP-Firewall، أريد أن أكون مباشرًا: يجب التعامل مع هذه الثغرة على أنها عاجلة. يحتوي مكون Name Directory قبل الإصدار 1.33.0 على ثغرة XSS مخزنة غير موثقة تسمح لمستخدم غير موثق بإدخال بيانات ضارة في المكون (تحديدًا حقل الاسم)، والتي يتم حفظها وعرضها لاحقًا دون هروب أو تصفية كافية للإخراج. في الممارسة العملية، يمكن أن يؤدي ذلك إلى تنفيذ XSS المخزنة في سياق مسؤول أو مستخدم آخر ذو امتيازات عند عرض الإدخال الضار، مما يمكّن مجموعة من إجراءات ما بعد الاستغلال من سرقة الجلسات إلى تعديل الموقع.

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

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

---

ملخص تنفيذي — إجراءات فورية

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

---

ما هي الثغرة بالضبط؟

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

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

---

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

1. استهداف المسؤولين بشكل خفي
   يقوم المهاجم بتقديم اسم يبدو غير ضار يحتوي على نص مشفر أو سمات أحداث HTML. عندما يفتح المسؤول لاحقًا إدخال الدليل أو قائمة تتضمن ذلك الاسم، يتم تفعيل الحمولة في متصفح المسؤول وتنفيذ JavaScript في جلسة المسؤول. يمكن للمهاجم بعد ذلك تنفيذ إجراءات (تغيير الإعدادات، إنشاء مستخدمين إداريين، تثبيت المكونات الإضافية) عبر متصفح المسؤول.
2. اختراق جماعي عبر تفاعل مستخدم منخفض الامتيازات
   تستهدف الحمولة المخزنة أي مستخدم متميز (ليس فقط مالكي الموقع). إذا قام أي محرر أو مشرف بعرض العنصر، يمكن أن يتم اختطاف جلستهم أو تنفيذ عمليات مشابهة لـ CSRF، مما يمكّن من التصعيد.
3. تشويه دائم أو إعادة توجيه
   يمكن أن تعيد الحمولة توجيه الزوار أو حقن محتوى في الصفحات التي تعيد استخدام الاسم المخزن على الصفحات العامة، مما يؤثر على سمعة الموقع ونتائج محركات البحث.
4. نقرة مسؤول بالصدفة
   في بعض سير العمل، تقوم بعض المكونات الإضافية أو صفحات المسؤول تلقائيًا بعرض إدخالات الدليل (مثل معاينات الأدوات). يمكن أن يسمح هذا بالاستغلال دون الحاجة إلى اتخاذ المسؤول إجراءً متعمدًا بخلاف زيارة الصفحة.

---

مؤشرات الاختراق (IoC) - ما الذي يجب البحث عنه

قم بفحص موقعك بحثًا عن العلامات التالية:

• إدخالات في مجموعة بيانات دليل الأسماء تحتوي على تسلسلات مشبوهة: 6., عند حدوث خطأ=, تحميل=, جافا سكريبت:, iframe, svg/onload, ، أو كيانات HTML غير عادية مثل < التي تفكك إلى <.
• إدخالات جديدة غير متوقعة تم إنشاؤها في الدليل بواسطة مستخدمين أو روبوتات غير معروفة.
• سجلات نشاط المسؤول غير العادية: حسابات مستخدمين جديدة بامتيازات مسؤول أو محرر، تغييرات مفاجئة في المكونات الإضافية/القوالب، مهام مجدولة غير معروفة (WP-Cron)، أو كتابات ملفات غير متوقعة إلى wp-content.
• تنبيهات المتصفح عندما يقوم المسؤولون بعرض صفحات الدليل (نوافذ منبثقة، إعادة توجيه).
• سجلات خادم الويب تظهر طلبات POST إلى نقاط النهاية التي تقبل الإرسال مع حمولات غير عادية.
• اتصالات صادرة أو استعلامات DNS تم Initiated من الخادم في أوقات غريبة.

مهم: لأن المهاجمين غالبًا ما يقومون بتعتيم حمولات XSS (مثل، الأحرف الهاربة، سلاسل مقسمة، ترميز base64)، استخدم أساليب كشف متعددة (بحث عن السلاسل الخام، فك/تطبيع، وأنماط regex) عند الفحص.

---

خطوات التخفيف الفورية (قصيرة المدى / طارئة)

إذا لم تتمكن من التحديث على الفور، نفذ هذه الإجراءات بهذا الترتيب:

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

---

أمثلة على قواعد التصحيح الافتراضية لـ WP-Firewall

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

مهم: أنماط الحظر هذه محافظة - قم بضبط regex والاستثناءات لبيئتك لتقليل الإيجابيات الكاذبة.

مثال على قاعدة ModSecurity (بناء جملة ModSecurity v2/v3):

# حظر علامات السكربت الواضحة و URIs الخاصة بـ javascript في حقول الإرسال"

إذا كان المكون الإضافي ينشر إلى مسار معروف (على سبيل المثال /wp-admin/admin-ajax.php مع إجراء محدد)، يمكنك إضافة قاعدة مستهدفة:

# حظر الحمولة المشبوهة لإجراء المكون الإضافي المعروف"

مثال على Nginx + Lua أو OpenResty (كود زائف):

-- فحص جسم POST لحقل الاسم

ملحوظات:

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

---

إرشادات مطور المكون الإضافي - كيف يجب إصلاح ذلك

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

1. معالجة الإدخال بشكل صحيح عند نقطة الإرسال:
   • استخدم وظائف التطهير المناسبة عند حفظ الإدخال:
     • للنص العادي: تطهير حقل النص أو تطهير حقل منطقة النص قبل الحفظ.
     • لـ HTML المحدود: استخدم wp_kses() مع قائمة بيضاء صريحة من العلامات والسمات المسموح بها.

   مثال (من جانب الخادم):

   <?php
   

2. الهروب المناسب الواعي للسياق عند إخراج القيم المخزنة:
   • يستخدم esc_html() عند الإخراج في عقد نص HTML.
   • يستخدم esc_attr() إذا كان الإخراج في السمات.
   • يستخدم wp_kses_post() أو wp_kses() لجزء آمن من HTML إذا لزم الأمر.

   مثال (الرسم):

   <?php;
   

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

---

كيفية اكتشاف محاولات الاستغلال في السجلات وقاعدة البيانات

• استعلام عن قاعدة البيانات للسجلات المضافة حول وقت POSTs المشبوهة. ابحث عن علامات HTML أو تسلسلات مشفرة. مثال SQL (تشغيله من واجهة إدارة آمنة أو عبر WP-CLI):

SELECT ID, post_title, post_content;

• افحص سجلات خادم الويب لطلبات POST ذات الحمولة عالية الانتروبيا أو العديد من الأحرف غير الأبجدية الرقمية.
• استخدم بحثًا شاملًا للموقع عن سلاسل مثل عند حدوث خطأ=, جافا سكريبت:, <svg, <iframe, ، أو مقاطع مشفرة غير عادية (%3C, <).

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

---

قائمة مراجعة استجابة الحوادث (إذا كنت تشك في وجود استغلال)

1. ضع الموقع في وضع الصيانة (قم بإيقافه عن العمل إذا كان ذلك ممكنًا).
2. قم بعمل نسخة احتياطية كاملة (ملفات + قاعدة بيانات) قبل إجراء التغييرات.
3. قم بتحديث المكون الإضافي على الفور إلى الإصدار 1.33.0 (أو قم بإزالة المكون الإضافي).
4. قم بتدوير جميع كلمات مرور المسؤولين وأي مفاتيح API أو رموز مخزنة على الموقع.
5. راجع وأزل أي مستخدمين غير معروفين كمسؤولين.
6. قم بفحص الموقع باستخدام عدة ماسحات للبرامج الضارة وتغذيات معلومات التهديد (بما في ذلك فحص سلامة الملفات وفحوصات cron/task).
7. التحقق من آليات الاستمرارية:
   • مهام مجدولة غير معروفة (WP-Cron).
   • ملفات معدلة في دلائل السمات/الإضافات.
   • // السماح فقط للمستخدمين الذين لديهم صلاحية موثوقة (مثل manage_options) mu-plugins.
   • ملفات جديدة أو معدلة .php ملفات تحت دلائل التحميل أو التخزين المؤقت.
8. أعد تثبيت نواة ووردبريس، والسمات، والإضافات من مصادر رسمية إذا كنت تشك في التلاعب بالملفات.
9. راقب السجلات عن كثب لمحاولات متكررة؛ نفذ قواعد WAF وتحديد المعدل.
10. اعتبر إجراء تحليل جنائي كامل إذا كانت البيانات ذات قيمة عالية متورطة أو إذا كنت تشك في الحركة الجانبية.

---

تعزيز الأمان على المدى الطويل للمواقع التي تعمل بإضافات الدليل/التقديم.

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

---

أمثلة عملية — تصفية وعرض أكثر أمانًا.

مثال: حفظ آمن (من جانب الخادم):

$name_raw = isset($_POST['name_directory_name']) ? wp_unslash( $_POST['name_directory_name'] ) : '';

مثال: عرض آمن (عرض):

$name = get_post_meta( $entry_id, '_name_directory_name', true );

إذا كنت بحاجة إلى السماح بـ HTML محدود، قم بإدراج علامات محددة:

$allowed = array(;

---

لماذا يعتبر WAF مهمًا للثغرات مثل هذه

يوفر WAF (جدار حماية تطبيق الويب) حماية فورية وقابلة للتكوين أمام موقعك. يمكنه:

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

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

---

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

• تمكين تسجيل طلبات مفصل (مع مراعاة الخصوصية) لفترة بعد الكشف عن الثغرة.
• قم بتكوين التنبيهات لـ:
  • طلبات POST تحتوي على <script أو أنماط XSS الشائعة.
  • ارتفاعات مفاجئة في التقديمات إلى نقاط نهاية الدليل.
  • تغييرات في ملفات المكونات الإضافية أو كتابة ملفات غير معروفة.
• تصدير وتدقيق التقديمات الأخيرة بانتظام للأنماط غير العادية.
• استخدم بيئة اختبار لإعادة إنتاج والتحقق من الهجمات بأمان (لا تختبر حمولات ضارة على الإنتاج).

---

متى يجب عليك الاستعانة بمحترف أمان؟

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

يمكن لمستجيب الحوادث المؤهل في WordPress أو خدمة الأمان إجراء تنظيف عميق، واستعادة النزاهة، والمساعدة في تقوية الموقع ضد المشكلات المستقبلية.

---

حماية الزوار والمسؤولين - تجربة المستخدم والتعليم

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

---

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

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

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

---

ملاحظات ختامية - قائمة مراجعة ذات أولوية

1. قم بتحديث مكون اسم الدليل إلى 1.33.0 على الفور (إصلاح دائم).
2. إذا لم تتمكن من التحديث الآن، قم بتعطيل الإرسال المجهول وطبق قواعد WAF التي تحظر الحمولة الشبيهة بـ XSS لـ الاسم الحقل.
3. راجع ونظف الإرساليات الأخيرة؛ أزل الإدخالات المشبوهة.
4. قم بتدوير بيانات اعتماد المسؤول وتمكين المصادقة الثنائية.
5. قم بإجراء فحوصات كاملة للبرمجيات الضارة ومراقبة السجلات لمحاولات متكررة.
6. قم بتقوية تدفقات الإرسال (CAPTCHA، حدود المعدل، التطهير).
7. فكر في الاشتراك في خدمة WAF/تصحيح افتراضي مُدار لشراء الوقت أثناء إجراء الفرز والاختبار.

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

ابق آمناً — وقم بتحديث الإضافة الآن.