CVE-2026-94386
Apache Camel: إعادة استخدام الرموز عبر النطاقات في Camel-OAuth عبر ذاكرة تخزين مؤقت عالمية على مستوى JVM لرموز بيانات اعتماد العميل بمفتاح غير كافٍ
- تم النشر
- 26/10/2026
- محدث
- 26/10/2026
- تخصيص CNA
- apache
- الأدلة المرصودة
- 30/10/2026
CVSS الأساسي
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:Nمنخفض · الثلاثين يومًا القادمة
- المئوية
- 28.1%
- تاريخ الموديل
- 31/10/2026
EPSS هو تقدير إحصائي، وليس يقينًا أو مقياسًا للتأثير. ادمجها مع CVSS وحالة KEV والتعرض وبيئتك.
ملخص
ثغرة استخدام ذاكرة تخزين مؤقت تحتوي على معلومات حساسة في مكوّن Apache Camel Oauth. تؤثر هذه المشكلة على Apache Camel: من 4.19.0 قبل 4.22.2. يحصل OAuthClientCredentialsTokenResolver على رموز Bearer الخاصة بـ OAuth 2.0 عبر منحة بيانات اعتماد العميل نيابةً عن المكوّنات التي تصادق على استدعاءاتها الصادرة باستخدام ملف تعريف OAuth مسمّى، مثل camel-openai وcamel-langchain4j-agent وcamel-huggingface وcamel-docling وcamel-a2a وcamel-spring-ai-chat ومكوّنات IBM watsonx، وعن التطبيقات التي تستدعي واجهة SPI الخاصة بـ OAuthClientAuthenticationFactory مباشرةً. كان يحتفظ بالرموز التي حصل عليها في ذاكرة تخزين مؤقت ساكنة مشتركة بين كل نسخة resolver وكل CamelContext في الـ JVM، وكان يفتح تلك الذاكرة على نقطة نهاية الرمز ومعرّف العميل فقط، رغم أن طلب الرمز يحمل أيضًا سرّ العميل والنطاق المطلوب. لذلك فإن ملفَّي تعريف يشتركان في نقطة نهاية رمز ومعرّف عميل لكنهما يطلبان نطاقين مختلفين، أو يصادقان بسرَّي عميل مختلفين، يُربطان إلى الإدخال نفسه في الذاكرة المؤقتة: فملف التعريف الذي حلّ الرمز أولًا هو من ملأ الإدخال، ثم يُسلَّم ذلك الرمز إلى ملف التعريف الآخر، دون إجراء أي طلب رمز وفق إعداداته الخاصة، طالما بقي الرمز صالحًا. تخزين الرموز المؤقت مفعّل افتراضيًا، وتوجيه عدة ملفات تعريف إلى عميل واحد لدى مزوّد هوية هو استخدام عادي لدعم ملفات التعريف وليس اختيارًا صريحًا لإعداد غير آمن. النتيجة هي طلب صادر يحمل رمزًا صادرًا لنطاق ملف تعريف آخر، ما قد يمنح صلاحية أوسع مما كان ملف التعريف المستدعي مُهيَّأً له، أو يصل إلى خدمة لم يُصدر الرمز من أجلها؛ ومع مزوّدي الهوية الذين يستنبطون جمهور الرمز من النطاق المطلوب، قد يعني نطاق مختلف رمزًا لخدمة مختلفة تمامًا. وبالمثل، يُقدَّم إلى ملف تعريف مُهيَّأ بسرّ عميل مختلف الرمز الذي جرى الحصول عليه بالسرّ الآخر، دون مصادقة بسرّه الخاص. تُهيَّأ ملفات التعريف بواسطة النشر، وهو موثوق، لذا لا يصل أي إدخال غير موثوق إلى الذاكرة المؤقتة: فالطرف المستفيد هو الخدمة التي تتلقى رمزًا لم يكن مقصودًا أن تتلقاه، والتي يمكنها، إن كانت معادية أو مخترقة، إعادة استخدام ذلك الرمز ضمن نطاقه. يتطلب الوصول إلى المشكلة نشرًا يعرّف أكثر من ملف تعريف واحد يشترك في نقطة نهاية رمز ومعرّف عميل مع اختلاف في النطاق أو سرّ العميل. يُنصح المستخدمون بالترقية إلى الإصدار 4.23.0، الذي يصلح المشكلة. وإذا كان المستخدمون على سلسلة إصدارات 4.22.x، فيُقترح عليهم الترقية إلى 4.22.2. بلغت خطوط الإصدارات من 4.19.x إلى 4.21.x نهاية عمرها قبل حل هذه المشكلة ولن تتلقى إصلاحًا، لذا يجب على عمليات النشر عليها الانتقال إلى إصدار مدعوم. وبالنسبة لعمليات النشر التي لا يمكنها الترقية فورًا، عطّلوا تخزين الرموز المؤقت على كل ملف تعريف OAuth يشترك في نقطة نهاية رمز ومعرّف عميل مع ملف تعريف آخر، عبر تعيين camel.oauth.NAME.cache-tokens=false لملف تعريف مسمّى أو camel.oauth.cache-tokens=false للملف الافتراضي، بحيث يطلب كل حل رمزًا بنطاق ملف التعريف نفسه وسرّ عميله، على حساب طلب رمز عند كل حل. بدلًا من ذلك، سجّلوا عميلًا منفصلًا لدى مزوّد الهوية لكل ملف تعريف يحتاج إلى نطاق أو سرّ عميل مختلف، بحيث لا يشترك أي ملفَّي تعريف من هذا القبيل في معرّف عميل.
الاستخدام المسؤول
استخدم معلومات الثغرات الأمنية فقط على الأنظمة التي تمتلكها أو المرخص لها باختبارها. يرتبط Kitploit ببيانات تعريف البحث العامة ولا يخزن أكواد الاستغلال أو الحمولات الضارة.