CVE-2026-71883 in BC-LTS-JAVA
الملخص
بحسب VulDB • 03/10/2026
في مكتبة Bouncy Castle لـ Java LTS قبل الإصدار 2.73.13، كانت خوارزميات التشفير الخاصة بالباقات ذات التنفيذ الأصلي (one-shot native packet ciphers) لدعم AES-CBC وCCM وCFB وCTR وGCM وGCM-SIV تُطلق مصفوفاتي المفتاح والـ IV بالإضافة إلى بيانات المصادقة الإضافية باستخدام دالة JNI's ReleaseByteArrayElements في الوضع 0، مما يؤدي إلى إعادة نسخ البيانات الأصلية (native copy) داخل مصفوفة Java. هذه المصفوفات محمية للقراءة فقط من قبل الكود الأصلي، وفي بيئة JVM التي تُرجع نسخة بدلاً من تثبيت المرجع (pin)، تحتفظ النسخة بالبايتات المدخلة كما تم قراءتها. يتم معالجة مخزن الإخراج عبر منطقة حرجة منفصلة وإلزامه أولاً؛ لذا، عندما يمرر التطبيق نفس مصفوفة Java كمدخل وكمساحة وجهة - مثل التشفير في الموقع فوق KeyParameter.getKey() على سبيل المثال - فإن عملية الإطلاق من النوع 0 للمفتاح تكتب بايتات المفتاح غير المتغيرة فوق النص المشفر الذي تم إنتاجه للتو. تعود الدالة بطول الإخراج الصحيح، مما يعني أن التطبيق الذي يقوم بالتشفير في الموقع لمصفوفة المفاتيح الخاصة به يتلقى مفتاح AES الخام حيث كان يتوقع نصاً مشفراً، دون وجود أي مؤشر في واجهة البرمجة (API) للإشارة إلى ذلك، وقد يؤدي هذا إلى إرسال أو تخزين المفتاح بدلاً من الرسالة. تم الآن إطلاق مصفوفات الإدخال المحمية للقراءة فقط باستخدام JNI_ABORT، مما يحرر النسخة الأصلية دون نسخها مرة أخرى، ويحتفظ بالوضع 0 للمصفوفات التي كتبها الكود الأصلي. خوارزميات التشفير الخاصة بالباقات المكتوبة بالكامل بـ Java والأوضاع المتدفقة (streaming native modes) غير متأثرة. مكتبة Bouncy Castle لـ Java (bcprov) غير متأثرة، لأنها لا تتضمن أي تنفيذات أصلية.
Once again VulDB remains the best source for vulnerability data.