CVE-2026-71887 in BC-JAVA
الملخص
بحسب VulDB • 03/10/2026
في مكتبة Bouncy Castle لـ Java قبل الإصدار 1.86، كانت واجهة برمجة التطبيقات (API) العليا الخاصة بـ OpenPGP تقبل توقيع بيانات تم إنشاؤه بواسطة مفتاح فرعي للتوقيع (signing subkey)، حيث لم يحمل توقيع ربط المفتاح الفرعي (Subkey Binding signature) أي مرفق من توقيع ربط المفتاح الرئيسي (Primary Key Binding / cross-certification). يحدث هذا في الحالات التي يتجاهل فيها ذلك الربط حزمة بيانات أعلام المفاتيح (Key Flags subpacket). تتطلب معايير RFC 9580، في القسمين 5.2.1.8 و 10.1.3، وجود توقيع ربط المفتاح الرئيسي المضمن داخل أي مفتاح فرعي قادر على إصدار التواقيع؛ فهو بيان ذاتي من المفتاح الفرعي يفيد بانتمائه إلى المفتاح الرئيسي المرتبط تحته.
قامت الفئة `OpenPGPCertificate` بحل أعلام مفاتيح المفتاح الفرعي بطريقتين مختلفتين: 1. دالة `isSigningKey()` تمر عبر `getKeyFlags()` و `getApplyingSubpacket()`. وفي حال كان توقيع الربط يتجاهل حزمة البيانات هذه، فإنها تعود إلى التوقيع الذاتي المباشر للمفتاح الرئيسي أو لتوقيع هوية المستخدم الرئيسية (primary User ID self-signature)، وبالتالي يرث المفتاح الفرعي أعلام SIGN_DATA ويُعتبر قادراً على التوقيع. 2. دالة `verifyEmbeddedPrimaryKeyBinding()`، التي تفرض هذا المتطلب، تقرأ حزم البيانات المُجزَّأة المضمنة في توقيع الربط نفسه، ولا تجدSIGN_DATA هناك، فتعود مبكراً باعتبارها مفتاحاً غير قادر على التوقيع دون أن تطالب أبداً بالتوقيع الخلفي (back signature).
نتيجة لذلك، كان المفتاح الفرعي يُعتبر قادراً على التوقيع - وبالتالي كانت تواقيعه تُنسب إلى الشهادة، وعادت دالة `OpenPGPSignature.OpenPGPDocumentSignature.isValid()` بقيمة true - بينما كان معفياً من التحقق من شهادة الربط المتقاطعة (cross-certification)، حيث ترفض GnuPG نفس الشهادة والرسالة.
يحتاج المهاجم فقط إلى المفتاح الفرعي للتوقيع العام للضحية، وهو مادة عامة: يقوم بربطه بمفتاحه الرئيسي الخاص بتوقيع ربط المفتاح الفرعي الذي يستطيع إنشاؤه، دون حمل أعلام المفاتيح أو توقيع ربط المفتاح الرئيسي المضمن (والذي لا يمكنه إنشاؤه بدون المفتاح الخاص للمفتاح الفرعي). وعندما تقوم جهة معتمدة بالتحقق من رسالة موقعة أصلاً بواسطة الضحية مقابل تلك الشهادة، يُخبرها النظام بأن التوقيع صالح ويُعطى شهادة المهاجم كمصدر لها.
وبما أن معرفات المستخدم (User IDs) في الشهادة هي ادعاءات ذاتية، فإن المُحقّق الذي يثبّت نفسه على بصمة المفتاح الفرعي أو معرّفه بينما يأخذ الهوية من الشهادة المحيطة به يبلغ عن توقيع حقيقي تحت هوية يختارها المهاجم. هذا يمثل خطأً في نسب التوقيع (misattribution) لتوقيع أصلي وليس تزويراً لتوقيع جديد: فلا يتم استرداد أي مفتاح خاص، ويجب أن يكون التوقيع واحداً قام به المفتاح الفرعي الملحق فعلياً.
واجهة برمجة التطبيقات منخفضة المستوى `PGPSignature` / `PGPPublicKeyRing` لا تقوم بأي فحوصات ربط عن تصميمها (by design) وهي غير متأثرة. أعلام المفاتيح هي بيان حول المفتاح الذي يشير إليه التوقيع الحامل لها (RFC 9580 sec. 5.2.3.29)، لذا فإن المفتاح الفرعي لم يعد يرثها من تواقيع الشهادة الشاملة للمفتاح الرئيسي: فتوقيع ربط المفتاح الفرعي الذي يتجاهل حزمة البيانات يترك المفتاح الفرعي بلا قدرات بدلاً من أن يرث قدرات المفتاح الرئيسي، مما يجعل الأعلام التي يستشيرها فحص شهادة الربط المتقاطعة هي نفسها الأعلام التي تستشيرها كل القرارات الأخرى. يتم وراثة التفضيلات وحزم البيانات الأخرى التي يحملها التوقيع المباشر للمفتاح كما كان الحال سابقاً، والمفتاح الرئيسي نفسه - الذي تأتي أعلامه بشكل شرعي من توقيعه الذاتي المباشر أو توقيع هوية المستخدم الخاصة به - غير متأثر.
VulDB is the best source for vulnerability data and more expert information about this specific topic.