XSS المخزنة غير الموثقة في ملحق ‘تكامل لـ Freshsales’ (≤ 1.0.15): المخاطر، الاستجابة وكيف يحميك WP-Firewall

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

ملخص

تم تعيين ثغرة XSS المخزنة الحرجة التي تؤثر على ملحق ووردبريس “تكامل لـ Freshsales - نموذج الاتصال 7، WPForms، Elementor، Gravity Forms والمزيد” (الإصدارات <= 1.0.15) كـ CVE-2026-8901. على الرغم من أن الإرسال الأولي للمحتوى الضار يمكن أن يتم دون مصادقة، إلا أن الحمولة تُخزن وتنفذ في سياق مستخدم متميز عندما يقومون بعرض أو معالجة ذلك المحتوى المخزن - مما يجعل الثغرة خطيرة بشكل خاص للمواقع التي يتعامل فيها المسؤولون أو المحررون مع تقديمات النماذج الواردة أو إدخالات مزامنة CRM.

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

ملاحظة: أطلق مؤلف الملحق إصدارًا ثابتًا 1.0.16. التحديث إلى هذا الإصدار هو أفضل إجراء تصحيحي واحد.

حقائق سريعة

• الملحق المتأثر: تكامل لـ Freshsales - نموذج الاتصال 7، WPForms، Elementor، Gravity Forms والمزيد
• الإصدارات المتأثرة: <= 1.0.15
• تم تصحيحه في: 1.0.16
• نوع الثغرة: البرمجة النصية عبر المواقع المخزنة (XSS)
• CVE: CVE-2026-8901
• متجه الهجوم: إرسال غير موثق → حمولة مخزنة → تنفيذها عندما يقوم مستخدم متميز بعرض البيانات
• CVSS (المبلغ عنه): 7.1 (مرتفع) - انتبه للسياق: XSS المخزنة التي تنفذ في سياق المسؤول يمكن أن تؤدي إلى الاستيلاء الكامل على الموقع
• المخاطر الرئيسية: اختراق جلسة إدارية، التلاعب بالإعدادات، تسريب البيانات، زرع البرمجيات الخبيثة

لماذا يجب أن تهتم

تختلف XSS المخزنة عن XSS المنعكسة في أن الحمولة الضارة تُحتفظ على جانب الخادم (في قاعدة البيانات، الخيارات، postmeta، أو جداول الملحقات) وستنفذ كلما زار المستخدم الصفحة أو شاشة الإدارة التي تعرض ذلك المحتوى. عندما يتم تنفيذ ذلك المحتوى في متصفح مستخدم إداري، يمكن للمهاجمين تنفيذ إجراءات متميزة باستخدام جلسة ذلك المستخدم - بما في ذلك إنشاء مستخدمين إداريين جدد، تغيير إعدادات الملحق أو القالب، تثبيت أبواب خلفية، أو تصدير بيانات حساسة ومفاتيح API (بما في ذلك رموز تكامل CRM).

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

سيناريو الاستغلال (مستوى عالٍ)

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

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

التأثير المحتمل

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

الإجراءات الفورية لمالكي المواقع (مرتبة)

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

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

• غير متوقع، ، أو سمات معالج الأحداث المخزنة في المشاركات، postmeta، أو جداول الإضافات المخصصة.
• حسابات المسؤولين التي تم إنشاؤها أو تعديلها بدون تفويض.
• تغييرات مفاجئة في إعدادات المكونات الإضافية أو السمات، أو تثبيت مكونات إضافية/سمات ضارة.
• طلبات صادرة إلى مضيفين بعيدين غير متوقعين من خادم الويب (تحقق من سجلات خادم الويب ونشاط الشبكة الصادر).
• تسجيلات دخول غير عادية للمسؤول (عناوين IP مشبوهة، أوقات غير عادية).
• نوافذ منبثقة أو JavaScript في شاشات المسؤول، أو إعادة توجيه غريبة في لوحة تحكم المسؤول.
• تحقق من جدول خيارات WP والجداول الخاصة بالمكونات الإضافية للمدخلات التي تحتوي على “javascript:”, “<script”، “onerror=”، “onload=”، “eval(“، “document.cookie”، “window.location”، أو المعادلات المشفرة.

استعلامات MySQL مثال للعثور على الشيفرات المخزنة المشبوهة:

-- البحث في wp_posts و wp_postmeta;

استخدم WP‑CLI للبحث الخفيف:

# البحث في الدلائل الخاصة بالمكونات الإضافية عن الحمولة المشبوهة

احتواء فوري باستخدام WAF / تصحيح افتراضي

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

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

# حظر حمولات XSS الشائعة في جسم الطلب (POST)"

يمكن أن تستخدم Nginx + Lua أو مرشحات WAF مخصصة نهجًا مشابهًا: فحص جسم POST ومعلمات الطلب لهذه الأنماط وحظر أو التحقق من الطلبات.

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

قاعدة مقترحة تستهدف نقاط نهاية المكون الإضافي (أسماء المسارات المثال - تأكد من نقاط نهاية المكون الإضافي الدقيقة في نشراتك):

# مثال: تحقق فقط من الطلبات التي تطابق نقاط نهاية المكون الإضافي"

إذا كنت تدير WP‑Firewall، استخدم محرك التصحيح الافتراضي/الحماية التلقائية لدفع توقيع مستهدف للنماذج ونقاط نهاية المكونات الإضافية التي تتحقق من التسلسلات أعلاه وتمنع أو تتحدى المرسل.

كيفية إزالة الحمولات المخزنة بأمان

إذا وجدت نصوصًا مخزنة مشبوهة، قم بتنظيفها بعناية:

1. ضع الموقع في وضع الصيانة.
2. قم بتصدير نسخة احتياطية من قاعدة البيانات للتحقيق (احتفظ بنسخة للتحليل الجنائي).
3. افحص يدويًا كل إدخال مشبوه - لا تشغل الموقع مع وجود الحمولة النشطة أثناء تصفح شاشات الإدارة بدون حماية كافية.
4. استبدل أو قم بتنظيف الحقول الضارة باستخدام أدوات من جانب الخادم أو تحديثات SQL. مثال على التنظيف:

-- إزالة تكرارات "<script" من post_content (مثال، اختبر أولاً);

5. استخدم واجهة برمجة تطبيقات WP REST أو WP‑CLI مع روتين PHP مُنظف لإعادة حفظ المحتوى باستخدام دوال إخراج آمنة إذا كنت بحاجة إلى الحفاظ على تقديمات المستخدم.

تخفيف المطورين / إصلاحات الترميز الآمن

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

• الهروب عند الإخراج، وليس الإدخال. دائمًا قم بتنظيف وهروب البيانات عند عرضها على HTML.
  • للنص العادي: استخدم esc_html( $value )
  • بالنسبة لـ HTML المسموح به ولكن المصفى: استخدم wp_kses( $value, $allowed_html )
  • للسمات: استخدم esc_attr( $value )
  • لروابط URL: استخدم esc_url_raw() و esc_url()
• استخدم فحوصات القدرة وnonces لأي إجراء يؤثر على إعدادات الإدارة أو المكون الإضافي:
  • تحقق current_user_can( 'manage_options' ) أو القدرة ذات الصلة قبل عرض أو معالجة البيانات الحساسة.
  • يستخدم حقل wp_nonce() على النماذج وتحقق مع check_admin_referer().
• تجنب تخزين HTML الخام من المستخدمين غير الموثقين في أماكن سيتم عرضها لاحقًا في مشاهد الإدارة. إذا كان من المتوقع أن يتضمن محتوى المستخدم تنسيقًا، فطبق صارمًا wp_kses القائمة البيضاء.
• عند قبول المحتوى الذي سيتم إرساله إلى أنظمة خارجية (رموز CRM، مفاتيح API)، قم بتخزينها في الخيارات مع تنظيف مناسب وحد من العرض في واجهة المستخدم (قم بإخفاء المفاتيح في شاشات الإدارة).

مثال على هروب الإخراج:

<?php

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

توصيات تعزيز الأمان للمسؤولين

• قم بتحديث المكونات الإضافية، والسمات، ونواة WordPress بسرعة، ويفضل في بيئة اختبار أولاً.
• حد من استخدام الإضافات: قم بإلغاء تثبيت أو تعطيل الإضافات التي لا تحتاجها.
• قيد الوصول إلى عناوين URL الإدارية باستخدام قيود IP أو مصادقة HTTP إذا كانت فريقك يعمل من عناوين IP ثابتة.
• أضف سياسة أمان المحتوى (CSP) التي تمنع السكربتات المضمنة وتقييد مصادر السكربتات - هذا يقلل من تأثير حمولات XSS. ملاحظة: CSP هو طبقة دفاعية عميقة، وليس بديلاً عن الهروب الصحيح.
• فرض كلمات مرور قوية وتنفيذ المصادقة الثنائية لجميع الحسابات ذات القدرات المميزة.
• قم بتدوير مفاتيح API ورموز CRMs بعد تنظيف الحادث - افترض أن المفاتيح قد تكون تعرضت إذا كان لديك XSS في سياق الإدارة.
• راقب سلامة الملفات (تشفير) وقارن الملفات الحالية مع النسخ الأصلية المعروفة من البائعين (مستودعات القوالب/الإضافات).
• نفذ تسجيل الدخول والتنبيه على الأنشطة الإدارية الشاذة.

قائمة التحقق للاستجابة للحوادث والتعافي

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

مثال على قاعدة WAF/تصحيح افتراضي معقول (نمط أبسط)

إذا كانت WAF الخاصة بك تدعم حظر regex في أجسام الطلبات والمعلمات، فقد تبدو القاعدة المؤقتة مثل هذا من الناحية المفاهيمية:

• حظر إذا كان جسم POST يحتوي على:
  • “<script” (غير حساسة لحالة الأحرف)
  • “onerror=” أو “onload=” (سمات معالج الأحداث)
  • “javascript:” بروتوكول زائف
  • “document.cookie”، “eval(“، “window.location”، “document.write(“

كود زائف:

إذا كانت الطريقة == POST و (الجسم يحتوي على أي من الأنماط المذكورة أعلاه) و request_uri يتطابق مع plugin_endpoint:

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

المراقبة والوقاية على المدى الطويل

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

How WP‑Firewall helps protect your site

كمزود خدمة جدار حماية وأمان لـ WordPress، يوفر WP‑Firewall حماية متعددة الطبقات تتصدى بشكل خاص لـ XSS المخزنة وطرق استغلال المكونات الإضافية المماثلة:

• جدار حماية مُدار مع قواعد WAF مستهدفة يمكن نشرها بسرعة، بما في ذلك تصحيحات افتراضية طارئة لمشكلات المكونات الإضافية التي تم الكشف عنها حديثًا.
• محرك WAF الذي يفحص معلمات الطلب وأجسام POST بحثًا عن أنماط XSS ويمنع الطلبات المشبوهة قبل أن تصل إلى WordPress.
• ماسح للبرمجيات الضارة لاكتشاف JS المُحقن والأبواب الخلفية، وميزات للحجر الصحي أو إزالة البرمجيات الضارة المعروفة.
• القدرة على حظر أو تقليل سرعة IPs المشبوهة إذا لاحظت محاولات فحص أو حقن جماعي.
• مراقبة مستمرة وتنبيهات مصممة لنشاط إدارة WordPress ونقاط نهاية المكونات الإضافية.

إذا كنت تدير موقعًا يدمج مكونات إضافية من طرف ثالث للتعامل مع محتوى المستخدم الوارد ومزامنة CRM، فإن وجود جدار حماية مُدار أمام WordPress يقلل من سطح الهجوم أثناء تحديثك وإصلاح الثغرات.

جديد: ابدأ مع WP‑Firewall (الخطة المجانية) — احمِ الآن، قم بالترقية مع نموك

عنوان: احمِ موقعك على الفور مع جدار حماية مُدار مجاني

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

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

أبرز النقاط في لمحة:

• الأساسي (مجاني): جدار حماية مُدار، عرض نطاق غير محدود، WAF، ماسح للبرمجيات الضارة، تخفيف OWASP Top 10
• القياسي ($50/سنة): يضيف إزالة البرامج الضارة تلقائيًا وقائمة حظر/قائمة بيضاء لعناوين IP تصل إلى 20 عنوان IP
• برو ($299/سنة): يضيف تقارير أمان شهرية، وتصحيح افتراضي تلقائي للثغرات، وإضافات مميزة (مدير حساب مخصص، تحسين الأمان، خدمات مدارة)

قائمة مرجعية عملية - ماذا تفعل الآن (ملخص)

• قم بتحديث المكون الإضافي إلى 1.0.16 على الفور.
• إذا لم تتمكن من التحديث الآن، قم بتعطيل المكون الإضافي أو تطبيق قواعد WAF لحماية نقاط نهاية المكون الإضافي.
• قم بفحص قاعدة بياناتك بحثًا عن علامات نصية مخزنة أو محتوى مشبوه؛ قم بإزالة أو تطهير الحمولة المكتشفة.
• قم بتدوير مفاتيح API والبيانات المرتبطة بالمكون الإضافي (رموز Freshsales/CRM).
• فرض أقل امتياز وتمكين 2FA لجميع مستخدمي الإدارة.
• راقب السجلات وقم بتمكين التحقق من سلامة الملفات.
• ضع في اعتبارك استخدام خطة WP‑Firewall المجانية الأساسية للحماية المدارة الفورية أثناء تنفيذ الإصلاحات.

إرشادات المطور: أنماط الإخراج الآمنة (أمثلة)

قم بتخزين المدخلات الخام فقط حيثما كان ذلك ضروريًا، ولكن دائمًا قم بالهروب عند وقت العرض:

• إخراج النص:

<?php

• إخراج السمة:

<?php

• السماح بـ HTML محدود:

<?php

• تحقق من nonce للنماذج:

<?php

الأفكار النهائية

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

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

إذا كنت بحاجة إلى مساعدة في تقييم موقعك، أو نشر توقيعات WAF مؤقتة، أو البحث عن علامات الاختراق، يمكن لفريق الأمان لدينا المساعدة في خدمات الاستجابة الطارئة والتعافي المصممة لبيئات WordPress.

المراجع

• CVE‑2026‑8901 — XSS المخزنة في تكامل مكون Freshsales الإضافي (تم تصحيحه في الإصدار 1.0.16)
• دليل مطوري WordPress: وظائف الهروب والتنظيف
• OWASP العشرة الأوائل (إرشادات الحقن وXSS)

(نهاية التقرير)