CVE-2026-8239

CVE-2026-8239 هي ثغرة من نوع مرجع كائن مباشر غير آمن (IDOR) تؤثر على Concrete CMS 9.5.0 والإصدارات الأقدم. توجد الثغرة في نقطة النهاية /ccm/frontend/conversations/get_rating، والتي تسمح للمهاجم بتحديد ما إذا كانت رسالة محادثة موجودة واسترداد درجة تقييمها عن طريق توفير معرّف رسالة عشوائي. لا تنفذ نقطة النهاية فحوصات تفويض مناسبة قبل إرجاع المعلومات المطلوبة.

البرمجيات المتأثرة

المنتج: Concrete CMS الإصدارات المتأثرة: 9.5.0 والإصدارات الأقدم الإصدار المُصحَّح: 9.5.1 نقطة النهاية: /ccm/frontend/conversations/get_rating نوع الثغرة الفئة: مرجع كائن مباشر غير آمن (IDOR) CWE-862: غياب التفويض

السبب الجذري

تستقبل نقطة النهاية معرّف رسالة من العميل وتُرجع معلومات حول تلك الرسالة دون التحقق من أن المستخدم الطالب مخوّل بالوصول إليها.

بدلًا من التحقق من الملكية أو الأذونات، يثق التطبيق بالمعرّف الذي يوفره المستخدم.

مفهوميًا:

المستخدم يوفّر messageId ↓ الخادم يحدد موقع الرسالة ↓ لا يوجد فحص تفويض ↓ يُرجع تقييم الرسالة

نظرًا لغياب فحص التفويض، يمكن للمهاجم تعداد معرّفات الرسائل والحصول على معلومات حول محادثات لا ينبغي أن يكون قادرًا على الوصول إليها.

سيناريو الهجوم

افترض أن التطبيق يخزّن رسائل المحادثة بمعرّفات رقمية.

قد يشير طلب شرعي إلى:

GET /ccm/frontend/conversations/get_rating?messageId=125

يمكن للمهاجم ببساطة تعديل المعرّف:

GET /ccm/frontend/conversations/get_rating?messageId=126

إذا استجاب التطبيق بدرجة التقييم بدلًا من إرجاع 403 Forbidden أو 404 Not Found، يمكن للمهاجم تأكيد أن الرسالة موجودة واسترداد معلومات تقييمها.

هذه حالة IDOR كلاسيكية لأن معرّف الكائن فقط هو الذي يتغير — لا يتطلب الأمر حمولة خبيثة أو أوامر محقونة.

التأثير

يمكن للمهاجم:

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

تؤثر الثغرة بشكل أساسي على السرية، حيث يمكن للمستخدمين غير المصرح لهم الوصول إلى معلومات ينبغي حمايتها.

الخطورة

المقياس الدرجة CVSS v3.1 (NVD) 5.3 – متوسطة CVSS v4.0 (Concrete CMS CNA) 6.3 – متوسطة

الكود الضعيف (مفاهيمي)

لم ينشر البائع الكود المصدري الضعيف الفعلي. يوضح المثال التالي نمط الثغرة فقط.

$messageId = $_GET['messageId'];

$message = $conversationRepository->findMessage($messageId);

// No authorization check
return response()->json([
    'rating' => $message->getRating()
]);

لماذا يُعد هذا الكود ضعيفًا؟

يسترد التطبيق الرسالة استنادًا إلى المعرّف الذي يوفره المستخدم فقط ويعيد تقييمها فورًا. ولا يتحقق أبدًا مما إذا كان المستخدم الحالي مخوّلًا بالوصول إلى تلك الرسالة.

الكود المصحح (مفاهيمي)

$messageId = $_GET['messageId'];

$message = $conversationRepository->findMessage($messageId);

if (!$authorizationService->canViewMessage($currentUser, $message)) {
    return response()->json([
        'error' => 'Access denied.'
    ], 403);
}

return response()->json([
    'rating' => $message->getRating()
]);

لماذا ينجح هذا الإصلاح؟

يتحقق التنفيذ المصحح من أن المستخدم المصادَق عليه لديه إذن لعرض الرسالة المطلوبة قبل إرجاع تقييمها. حتى إذا غيّر المهاجم messageId، يفرض الخادم التفويض ويرفض الطلبات غير المصرح بها باستجابة HTTP 403 Forbidden. يمنع هذا ثغرة IDOR من خلال ضمان أن المستخدمين يمكنهم الوصول فقط إلى الموارد المسموح لهم بعرضها.