يُنشئ اختبار HTTP مستخدم متبرع مؤقتًا، وبيانات وصفية، وصفوف جلسات GiveWP. استخدم أمر إعادة التعيين المرفق بعد الاختبار.

بدء سريع

المتطلبات:

• Docker مع Compose v2
• Python 3.10 أو أحدث
• curl
• unzip
• sha256sum أو shasum
• وصول شبكي إلى downloads.wordpress.org لأرشيفات الإضافات الرسمية

شغّل مصفوفة الضعيف/المصحح الكاملة:

يقوم الأمر بـ:

1. تنزيل GiveWP 4.16.5.1 و 4.16.7.2 من WordPress.org.
2. التحقق من كلا تجزئتي SHA-256.
3. بناء مختبر WordPress 6.6.2/PHP 8.1 جديد للاسترجاع المحلي فقط (loopback-only) مع تعطيل تسجيل WordPress العادي صراحةً.
4. اختبار 4.16.5.1 الأصلي ويتطلب إنشاء العلامة بواسطة مستخدم الويب.
5. بناء مختبر جديد ثانٍ مع 4.16.7.2 الأصلي.
6. يتطلب بقاء علامة HTTP غائبة.
7. تجاوز الدخول في تحكم مباشر ويؤكد أن أداة ProviderForwarder الطرفية المصححة ترفض أيضًا الاستدعاء النصي.

يبقى المختبر المصحح قيد التشغيل في النهاية. أزله باستخدام:

لاستخدام منفذ loopback آخر:

الأدلة المتوقعة

يجب أن ينتهي التحكم الضعيف بأدلة طرفية ملموسة:

يجب أن يُظهر التحكم المصحح:

إن HTTP 500، أو حمولة مخزنة، أو استثناء، أو إصابة كاشف بدون العلامة لا يُقبل كدليل على RCE.

دورة حياة المختبر اليدوية

ابدأ واختبر الإصدار الضعيف:

ابدأ واختبر الإصدار المصحح:

افحص الحالة الحالية:

أزل الحاويات، ووحدات التخزين، ومستخدمي الاختبار، والجلسات، وحالة العلامة:

يتم الاحتفاظ بملفات ZIP المخزنة مؤقتًا للإضافات والأصول المستخرجة لإعادة تشغيل أسرع. أزل تلك الأصول المُولدة المحددة أيضًا باستخدام:

الإصدارات المتأثرة والمُختبرة

يحدد الاستشارة العامة الإصدارات حتى 4.16.7.1 كمتأثرة. يُثبت هذا المستودع بشكل مباشر فقط الإصدارين في مصفوفة الاختبار الإيجابي/السلبي الخاصة به.

المراجع:

• استشارة Patchstack
• CVE-2026-82222
• تعهيد GiveWP
• صفحة إضافة GiveWP الرسمية

السبب الجذري

يجمع الاستغلال بين عدة سلوكيات:

1. يكشف GiveWP 4.16.5.1 عن إجراء تسجيل يُنشئ ويُصادق متبرعًا منخفض الصلاحيات حتى عندما يكون تسجيل WordPress العادي معطلًا.
2. يمكن لهذا المستخدم تخزين بيانات مُسلسلة في بياناته الوصفية الخاصة باسم العائلة (last_name).
3. يستخدم Give\Helpers\Utils::maybeSafeUnserialize() قيمة allowed_classes => false، مما يُنتج __PHP_Incomplete_Class، لكن تسلسلًا لاحقًا يحافظ على أسماء الفئات والخصائص الأصلية.
4. يتم تخزين المخطط في جلسة شراء GiveWP.
5. يقوم maybe_unserialize() غير المقيد لاحقًا بإحياء الفئات المرفقة.
6. يدخل التدمير التلقائي في سلسلة POP كاملة إلى system().

أربعة شرطات مائلة عكسية حرفية لمساحات الأسماء مطلوبة في الناقل عبر HTTP. تمريرات التجريد الفعالة تقللها 4 -> 2 -> 1. الحمولة خالية من NUL، وتم التحقق من أن PHP 8.1.30 يرطب الاسم المُسلسل العادي لخاصية Session::$attributeName الخاصة.

سلسلة POP الكاملة

المخطط المتحكم به من قبل المهاجم:

الانتقال الحرج الخفي هو توجيه PHP الضمني لـ IteratorAggregate. TCPDF::$imagekeys غير مُنمط، لذا فإن تعيين Session من Symfony يؤدي إلى استدعاء foreach لـ Session::getIterator().

يتم تنفيذ أمر العلامة قبل أن يفرض Symfony نوع الإرجاع getAttributeBag(): AttributeBagInterface. إن TypeError الناتج و HTTP 500 هما تأثيرات لاحقة للمصرف (post-sink).

ما فاتته المحاولات السابقة

استخدم المخطط المرشح المرفوض:

لا يمكن أن يعمل هذا المخطط. TCPDF::_destroy() يقوم فقط بإلغاء تعيين objcopy؛ ولا يقوم PHP بتوجيه التدمير التلقائي عبر __call('__destruct', ...).

العملية المفقودة كانت:

راجعت المراجعة السابقة المُدمِرات واستدعاءات الطرق الصريحة ولكنها لم تفحص بشكل متكرر بروتوكول الكائن الضمني الذي يُطلق بواسطة foreach. توفر Session من Symfony الجسر المفقود:

• يستدعي foreach دالة getIterator().
• تصل getIterator() إلى getBag($attributeName).
• storage المتحكم به من قبل المهاجم هو DonationFactory.
• يستدعي getBag غير المعرّف ProviderForwarder::__call().
• يختار loadedProviders['getBag'] = 'system' الاستدعاء.
• يوفر attributeName وسيطة الأمر.

أدلة المصدر

مواقع GiveWP 4.16.5.1 ذات الصلة:

تجزئات الإصدار الرسمي:

يعيد المختبر استخراج كل إضافة من ملف ZIP المُتحقق منه قبل كل بداية جديدة، وينسخها إلى WordPress دون تعديل، ويقارن بايتًا ببايت شجرة ملفات الإضافة الكاملة المنشورة مع المصدر المُتحقق منه. كما يتم تثبيت صور Docker الأساسية الرسمية الثلاث على ملخصات بيان متعددة البنى الخاصة بها.

لماذا يحجب 4.16.7.2 السلسلة

يضيف GiveWP 4.16.7.2 دفاعات مستقلة عبر التسجيل، ومعالجة المدخلات المُسلسلة، وإحياء الجلسة، وترحيل البيانات، وتقوية الأدوات.

يتطلب التقوية الطرفية أن ينفذ الكائن المُحل العقد المزود المتوقع:

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

فحص نشر حقيقي

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

إجراءات التحقق المفضلة:

1. سجّل إصدار GiveWP المنشور ومراجعة المصدر.
2. انسخ احتياطيًا أو التقط لقطة من موقع WordPress وقاعدة البيانات.
3. استعد تلك اللقطة في بيئة تدريج معزولة.
4. عطّل الوصول الشبكي الصادر غير الضروري.
5. شغّل هذا المُتحقق من العلامة فقط ضد النسخة المستنسخة.
6. حدّث GiveWP إلى أحدث إصدار مدعوم، مع اعتبار 4.16.7.2 الحد الأدنى للإصدار الذي يحتوي على الإصلاحات المُختبرة.
7. كرر الاختبار المطابق واطلب غياب العلامة.
8. تحقق بشكل مستقل من إصدار الإضافة المثبت والمصدر المصحح.

فحص الإصدار:

المعالجة ومراجعة الحوادث

حدّث GiveWP إلى أحدث إصدار مدعوم. بعد التحديث:

• امسح مخابئ opcode الخاصة بـ PHP حيثما ينطبق ذلك.
• تأكد من عدم بقاء أي نسخة أقدم من GiveWP نشطة أو قابلة للوصول عبر الويب.
• راجع حسابات WordPress أو المتبرعين غير المتوقعة.
• ابحث في البيانات الوصفية للمستخدمين وجلسات GiveWP عن مخططات TCPDF أو Session من Symfony أو loadedProviders المُسلسلة.
• اربط التسجيل، وتغييرات الملف الشخصي، وطلبات التبرع، واستجابات HTTP 500 اللاحقة من نفس الجلسة.
• حقق في عمليات خادم الويب الفرعية غير المتوقعة أو تغييرات نظام الملفات.

إذا كان تثبيت ضعيف معرّض للإنترنت يحتوي على آثار حقن كائنات، فتعامل معه كاختراق محتمل بدلاً من مجرد تحديث الإضافة.

هيكل المستودع

غير مُلتزم به:

حدود التحقق

معيار الإثبات صارم عمدًا: فقط علامة أمر قابلة للملاحظة عبر سلسلة المخزون غير المعدلة تُسمى RCE. قبول HTTP، والتسلسل، والاستثناءات، وإصابات الكاشف هي أدلة وسيطة.