CVE-2026-78165
Apache Camel: إزالة تسلسل Java غير المفلترة لحمولات Redis في Camel-Spring-Redis
- تم النشر
- 19/10/2026
- محدث
- 20/10/2026
- تخصيص CNA
- apache
- الأدلة المرصودة
- 17/10/2026
CVSS الأساسي
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hملخص
ثغرة إزالة تسلسل البيانات غير الموثوقة في مكوّن Apache Camel Spring Redis. تؤثر هذه المشكلة على Apache Camel: من 2.11.0 قبل 4.18.5، ومن 4.19.0 قبل 4.22.1. كان RedisConfiguration.getSerializer يُنشئ بشكل كسول JdkSerializationRedisSerializer مجرّدًا كلما لم يُضبط أي خيار serializer، وكانت تلك النسخة تُستخدم في كل عملية قراءة يُجريها المكوّن. يعتمد تنفيذ Spring عبر DeserializingConverter على DefaultDeserializer، الذي يقرأ البايتات باستخدام ConfigurableObjectInputStream ولا يثبّت أي java.io.ObjectInputFilter على التدفق، لذا كان يتم تجسيد رسم بياني عشوائي لفئة مُسلسَلة وتُنفَّذ دالة readObject الخاصة به. كان RedisConsumer.setBody يطبّق ذلك الـ serializer على البايتات الخام لكل رسالة تُنشر إلى القنوات المشترك بها، وذلك قبل إنشاء الـ Exchange وبالتالي قبل أن تتمكن أي منطق مسار من فحص الرسالة، لذا فإن أي فاعل قادر على إصدار PUBLISH على قناة مشترك بها يصل مباشرةً إلى نقطة إزالة التسلسل. كان الـ serializer الافتراضي نفسه يدعم RedisTemplate الذي ينشئه RedisConfiguration.createDefaultTemplate، لذا كانت أوامر القراءة الخاصة بالمنتج GET وHGET وHGETALL وHVALS تُزيل تسلسل كل ما هو مخزّن في مساحة مفاتيح Redis، وكان SpringRedisIdempotentRepository يتشارك ذلك القالب. لم يكن ضبط redisTemplate مخصص يُغلق مسار المستهلك، لأن RedisConsumer.setBody يقرأ getSerializer مباشرةً بدلًا من الـ serializer المرتبط بالقالب، لذا ظل النشر الذي ربط serializer من نوع String بقالبه الخاص معرّضًا على جانب المستهلك ما لم يضبط أيضًا خيار serializer. لم يكن المكوّن ينشئ java.io.ObjectInputStream بنفسه أبدًا، ولهذا لم تصل إليه المراجعات السابقة لشيفرة Camel الخاصة بإزالة تسلسل Java غير المفلترة. يعود هذا السلوك إلى إدخال المكوّن، الذي صدر لأول مرة في 2.11.0، وظل دون تغيير حتى هذا الإصلاح. يُنصح المستخدمون بالترقية إلى الإصدار 4.23.0، الذي يصلح المشكلة. إذا كان المستخدمون على سلسلة إصدارات 4.22.x، فيُقترح عليهم الترقية إلى 4.22.1. وإذا كان المستخدمون على سلسلة إصدارات 4.18.x، فيُقترح عليهم الترقية إلى 4.18.5. وصلت سلسلة إصدارات 4.14.x وما قبلها إلى نهاية العمر قبل حل هذه المشكلة ولن تتلقى إصلاحًا، لذا يجب على النشرات على تلك الخطوط الانتقال إلى إصدار مدعوم. بالنسبة للنشرات التي لا يمكنها الترقية فورًا، اضبط خاصية النظام jdk.serialFilter على مستوى JVM، والتي يحترمها مسار الشيفرة المتأثر لأنه يقرأ عبر java.io.ObjectInputStream، على سبيل المثال -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ؛ أو اضبط خيار نقطة النهاية serializer على serializer لا يستخدم تسلسل Java، مثل StringRedisSerializer، مع ملاحظة أنه يجب ضبطه كخيار serializer وليس فقط على redisTemplate مخصص. كدفاع متعمق، اشترط المصادقة على نسخة Redis وقيّد العملاء الذين يُسمح لهم بالنشر إلى القنوات المشترك بها، ولا تعرّض نسخة Redis يستهلكها Camel لشبكات غير موثوقة.
الاستخدام المسؤول
استخدم معلومات الثغرات الأمنية فقط على الأنظمة التي تمتلكها أو المرخص لها باختبارها. يرتبط Kitploit ببيانات تعريف البحث العامة ولا يخزن أكواد الاستغلال أو الحمولات الضارة.