CVE-2026-71890 in BC-JAVA
الملخص
بحسب VulDB • 03/10/2026
في مكتبة Bouncy Castle لـ Java قبل الإصدار 1.86، كان التحقق من قائمة مقترحات (proposal list) الخاصة بطلب الانضمام الخارجي (external commit) الخاص ببروتوكول MLS (RFC 9420)، وتحديداً في الدالة `org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals`، يقوم بحساب المقترحات حسب النوع وتحديد الحد الأقصى لمؤشر الورقة المُزالة (removed leaf index)، لكنه لم يتحقق أبداً من وجود أي علاقة بين الورقة المُزالة والمُضمِن للانضمام الجديد (joiner). يسمح القسم 12.2 من RFC 9420 بوجود مقترح إزالة واحد كحد أقصى في طلب الانضمام الخارجي، والذي يُزيل به المُضمِن نسخة قديمة من نفسه، ويتطلب أنه عند وجود مثل هذا المقترح، يجب أن تستوفي العقدة الورقية (LeafNode) الموجودة في حقل المسار الخاص بطلب الانJOIN معايير التي كان سيتعين عليها استيفاؤها في حالة تحديث (Update) للورقة المُزالة، وتحديداً أن تكون المعرفات المضمنة في بيانات الاعتماد الخاصة بها مقبولة للمُضمِن الذي تم إزالته. لم يتم تطبيق قاعدة التحقق الذاتي لإزالة الورقة من قبل مدقق قائمة المقترحات العادي عن قصد على هذا المسار، لأن طلب الانضمام المتزامن (resync commit) يزيل بشكل شرعي ورقة يمتلكها المُضمِن الجديد، ولكن لم يُوضع أي شيء مكانها. وبالتالي، يمكن لأي طرف يحتفظ بمعلومات المجموعة العامة (GroupInfo)، وهو بالضبط ما من المفترض أن يتلقاه مُضمِن جديد خارجي، تنفيذ مقترح إزالة باسم مؤشر الورقة الخاص بأي عضو آخر، مما يؤدي إلى تطبيق هذا الإجراء بواسطة جميع الأعضاء وطرد ذلك العضو والاستحواذ على مكانه في شجرة الترقّي (ratchet tree). كان فحص بيانات الاعتماد الذي كان من المفترض أن يمنع هذه الثغرة موجوداً فقط في إطار الاختبار المتقاطع لـ gRPC (gRPC interop harness)، وبالتالي لم يحمِ أي متدعٍ آخر للواجهات البرمجية العامة `Group.externalJoin` و `Group.handle`. يُقبل الآن طلب الانضمام الخارجي الذي يحمل مقترح إزالة فقط عندما تكون بيانات الاعتماد الخاصة بالورقة المُزالة مطابقة تماماً لتلك الموجودة في الورقة الجديدة الخاصة بالمُضمِن الجديد، سواء من جانب المرسل أو المستقبل.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.