CVE-2026-71892 in BC-JAVA
الملخص
بحسب VulDB • 03/10/2026
في مكتبة Bouncy Castle لـ Java قبل الإصدار 1.86، لم يكن يتم تنفيذ التحقق من حجم المفتاح الذي يتطلب موافقة صريحة (opt-in key-size validation) لمستلمي نقل المفاتيح في CMS، وتحديداً عبر `org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)`، عند استخدام اشتقاق مفتاح تشفير المحتوى وفقاً لـ RFC 9709 (`id-alg-cek-hkdf-sha256`). كانت الشفرة البرمجية التي كان من المفترض أن تختار خوارزمية تشفير المحتوى الفعلية الموجودة في معاملات `AlgorithmIdentifier` الخاصة باشتقاق المفتاح تقارن مصفوفة البايتات للمفتاح المشفر مع معرف الكائن (`object identifier`) الخاص بـ `id-alg-cek-hkdf-sha256`. وبما أن هذه مقارنة بين مصفوفة من البايتات وـ `ASN1ObjectIdentifier`، فإنها كانت تُرجع دائماً قيمة خاطئة (false) لأي مدخل ممكن. ونتيجة لذلك، كان التحقق يتجاوز الفحص وينتقل إلى البحث عن حجم المفتاح بناءً على معرف الكائن (`OID`) للغلاف الخارجي. وهذا الـ OID يحدد بنية اشتقاق مفتاح وليس خوارزمية تشفير، ولا يحتوي على حجم مفتاح مسجل، مما أدى إلى تخطي مقارنة الحجم تماماً. وبالتالي، كانت تُقبل بيانات `EnvelopedData` أو `AuthEnvelopedData` التي يكون فيها مفتاح تشفير المحتوى المشتق باستخدام HKDF غير متطابق مع حجم المفتاح لخوارزمية تشفير المحتوى المعلنة، حتى عند تمكين التحقق بشكل صريح، مما أدى إلى إبطال آلية الـ API الوحيدة المفروضة لفرض حجم المفتاح المسترد بصمت. يقوم المستقبل الآن بالتوجيه بناءً على OID الخوارزمية في `AlgorithmIdentifier` الخاص بتشفير المحتوى، بحيث يتحقق التحقق من المفتاح المسترد مقابل خوارزمية تشفير المحتوى الداخلية. الرسائل ذات أحجام المفاتيح المتطابقة، والرسائل غير المستخدمة لـ HKDF، والمستلمون الذين لا يفعّلون التحقق، لم تتأثر بهذه المشكلة. تؤثر هذه المشكلة أيضاً على Bouncy Castle for Java FIPS (BC-FJA) قبل الإصدارات `bcpkix-fips` 2.0.13 (سلسلة 2.0.X) و 2.1.13 (سلسلة 2.1.X).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.