CVE-2026-71888 in BC-JAVA
الملخص
بحسب VulDB • 03/10/2026
في مكتبة Bouncy Castle for Java قبل الإصدار 1.86، كان مُحلل البيانات المصادقة للتدفق (streaming CMS AuthenticatedData parser) يقبل رسالة تتعارض حقلاها digestAlgorithm و authAttrs بشأن وجود السمات المصادقة (authenticated attributes). يربط القسم 9.1 من RFC 5652 بين الحقلين، ويطلب أن يكون حقل authAttrs موجوداً كلما كان حقل digestAlgorithm موجوداً، بينما ينص القسم 9.2 على أن التوقيع الرقمي للمحتوى (MAC) يجب أن يغطي الترميز DER لـ authAttrs عند وجودها، وأن يغطي سلسلة البايتات الثنائية (OCTET STRING) لمحتوى الرسالة مباشرةً عندما لا تكون موجودة. يتعين على فئة CMSAuthenticatedDataDataParser اختيار أحد المسارين في مُنشئ الكائن (constructor)، قبل الوصول إلى حقل authAttrs الذي يأتي لاحقاً ضمن تسلسل البيانات (SEQUENCE)، لذا اعتمدت الفئة فقط على وجود digestAlgorithm: ففي حالة رسالة تحتوي على digestAbsent ولكن مع وجود حقول authAttrs، كانت تتحقق من صحة التوقيع الرقمي للمحتوى ثم تعيد السمات عبر الدالة getAuthAttrs() وكأنها مصادقة، رغم أن التوقيع الرقمي لم يغطِّها أبداً. يمكن لهجومٍ قادر على تعديل الرسالة أثناء النقل إدراج سمة مصادقة، مثل ESSSecurityLabel وفقاً لـ RFC 2634، في رسالة سليحة من الناحية الأخرى، بينما لا يمتلك المهاجم مفتاح تشفير المفتاح ولا مفتاح التوقيع الرقمي للمحتوى (content-MAC key)، وقد تتخذ التطبيقات التي تعتمد على هذه السمات قرارات تفويض أو توجيه أو تصنيف بناءً على قيم يختارها المهاجم. يبقى المحتوى نفسه مرتبطاً بالتوقيع الرقمي. الآن ترفض فئة asn1.cms.AuthenticatedData الاقتران غير المتطابق أثناء التحليل، وتقوم CMSAuthenticatedDataParser بالتحقق التبادلي بين الحقلين بعد قراءة authAttrs. هذه المشكلة هي حالة فرعية من CVE-2026-59642، التي ربطت المحتوى بالتوقيع الرقمي للرسائل التي تحمل حقول authAttrs بشكل شرعي، ولا تعالج الحالة الحالية. تؤثر هذه الثغرة أيضاً على Bouncy Castle for Java LTS قبل الإصدار 2.73.13، وعلى Bouncy Castle for Java FIPS (BC-FJA) قبل إصدارات bcpkix-fips 1.0.13 (سلسلة 1.0.X)، و2.0.13 (سلسلة 2.0.X)، و2.1.13 (سلسلة 2.1.X)، بالإضافة إلى bcutil-fips بالإصدارين 2.0.8 (سلسلة 2.0.X) و2.1.8 (سلسلة 2.1.X).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.