
تحليل تقني لـ CVE-2025-0924، وهي ثغرة تخزين XSS (Stored XSS) في إضافة WP Activity Log لمنصة ووردبريس. يشمل تحليل السبب الجذري، وعرض الاستغلال، وتوجيهات المعالجة.
XSS المخزن (Stored XSS) هو ثغرة أمنية يتم فيها تخزين script ضار على الخادم، ويتم تنفيذه تلقائيًا عندما يفتح مستخدمون آخرون الصفحة. يُصنف ضمن CWE-79 (ضعف التعقيم المناسب للإدخال أثناء إنشاء صفحة الويب - Cross-site Scripting).
WordPress هو أشهر نظام إدارة محتوى (CMS) مفتوح المصدر في العالم، يتيح إنشاء وإدارة المواقع والمدونات بسهولة. يمكن للمستخدمين توسيع وتخصيص الموقع باستخدام العديد من الإضافات والسمات دون الحاجة إلى معرفة برمجية.
WP Activity Log هو إضافة لتتبع وتسجيل النشاط الإداري في موقع WordPress. تُساعد المسؤولين على مراقبة الأحداث المختلفة التي تحدث على الموقع في الوقت الفعلي، وتوفير سجلات للتدقيق الأمني وحل المشكلات.
CVE-2025-0924 في إضافة WP Activity Log (الإصدارات 5.2.2 وما دون) تنشأ بسبب عدم كفاية التحقق من الإدخال وضعف الهروب في المخرجات في معامل "message". سنستعرض كيفية حدوث هذه الثغرة ونبحث عن طرق معالجتها.
عندما ينسخ المستخدم script ضار ويلصقه في عنوان الموقع، ويتم تسجيل هذا التغيير عبر WP Activity Log 5.2.2، يحدث هجوم XSS مخزن. سنستعرض مثالاً لفهم كيف يتسبب WP Activity Log في ظهور XSS مخزن.
[الشكل 1] إنشاء مقال في WordPress، إدراج script في قاعدة البيانات
بعد إنشاء المقال، عند فحص قاعدة البيانات، نلاحظ أن قيمة حقل post_title للمقال المنسوخ والملصوق لم يتم تعقيمها sanitize (تنظيف وترشيح الإدخال) بشكل مناسب وتم تخزينها كما هي.
يشير هذا إلى إمكانية معالجة البيانات بشكل مختلف اعتمادًا على طريقة الإدخال، مما قد يسبب ثغرة XSS (Cross-Site Scripting).
[الشكل 2] إنشاء سجل WP Activity Log وفحص الهجوم
[الشكل 3] class-list-events.php - إرجاع More details...
[الشكل 4] AuditLog.php -> AjaxInspector() - غير مُعَقَّم
[الشكل 4] نموذج metadata
لقد تعرفنا على XSS المخزن من خلال إضافة سجل الأمان في WordPress WP Activity Log. نظرًا لأن هذه الحالة تحدث فقط إذا أمكن رفع محتوى script في صفحة المستخدمين والسجلات، نقترح كطريقة معالجة التحديث من إصدار WP Activity Log 5.2.2 أو أقل إلى الإصدار 5.3.0.
[الشكل 5] تغييرات AjaxInspector / إضافة esc_html()
في هذه الحالة، يبدو أن المشكلة ناتجة عن عدم استخدام esc_html() لتعقيم المخرجات بشكل مناسب عند إرجاع HTML الناتج. لكن ما زلت غير متأكد مما إذا كان هذا التحليل يتطابق تمامًا مع الثغرة الموصوفة في CVE-2025-0924.
بعد الترقية إلى الإصدار 5.3.0 وإجراء الاختبارات، تأكدت من اتخاذ الإجراءات اللازمة. ومع ذلك، الثغرة الموصوفة في CVE-2025-0924 هي Stored Cross-Site Scripting عبر معامل ##message##، ويُذكر أن المسار يشمل class-alert.php و class-alert-manager.php.
لكن في تحليلي الحالي، المشكلة تكمن في meta data وليس في معامل message، والملفات المتورطة هي class-list-events.php و AuditLog.php، لذا فإن جميع التفاصيل غير متطابقة مع وصف NIST باستثناء "Stored Cross-Site Script". لذلك، يلزم إجراء فحص إضافي لتحديد التطابق الدقيق.