CVE-2026-71885 in BC-JAVA
الملخص
بحسب VulDB • 03/10/2026
في مكتبة Bouncy Castle لـ Java قبل الإصدار 1.86، لم تقم عملية تنفيذ أمان طبقة المراسلة (MLS، RFC 9420) بربط شهادة X.509 بمفتاح التوقيع الخاص بعقدة الورقة (LeafNode's signature_key). كانت دالة LeafNode.verify() تتحقق من توقيع العقدة مقابل مفتاح التوقيع الموجود داخل العقدة نفسها، بينما تم تخزين سلسلة شهادات X.509 الخاصة بالشهادة دون تحليلها أو التحقق منها أبداً؛ وبالتالي لم يكن مطلوباً مطلقاً أن يتطابق المفتاح العام الخاص بشهادة الطرف النهائي (end-entity certificate) مع مفتاح التوقيع كما يتطلب ذلك القسم 5.3 من RFC 9420. لذلك، يمكن لطرف ما تقديم شهادة طرف آخر كشهادته الخاصة أثناء توقيع العقدة والـ KeyPackage المحيط بها باستخدام مفتاح غير ذي صلة، ويتم قبوله تحت هوية الطرف الآخر عبر دالة KeyPackage.verify() ومسار التحقق من أوراق المجموعة (Group leaf-validation path). في النشر الذي يسمح بإدخالات خارجية (external commits) دون إجراء فحص مستقل لقبول الشهادات، يمكن لمهاجم غير مصادق عليه أن يُقبل تحت هوية X.509 لضحية ما، وطرد الضحية (مقارنة المزامنة من جديد تتحقق من الشهادات الكاملة بدلاً من مفاتيح التوقيع)، واستنتاج الفترة الزمنية الحالية (epoch)، وفك تشفير رسائل المجموعة اللاحقة، وإرسال رسائل تُقبل على أنها صادرة عن الضحية. تتطلب TreeKEM.LeafNode الآن أن يتطابق المفتاح العام للموضوع في شهادة الطرف النهائي، المشفر وفقاً لتشفير التوقيع الخاص بمجموعة الخوارزميات (cipher suite's signature encoding)، مع مفتاح التوقيع لشهادة X.509 وترفض العقدة خلاف ذلك، بما في ذلك السلسلة الفارغة أو الشهادة التي لا يتطابق نوع مفتاحها مع مجموعة الخوارزميات؛ ويبقى التحقق من صحة سلسلة الشهادات والهوية حتى جذر الثقة (trust anchor) مسؤولية التطبيق وفقاً للقسم 5.3.1 من RFC 9420. النشر الذي يستخدم فقط شهادات أساسية غير متأثر بهذه الثغرة.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.