CVE-2026-78162
Apache Camel: Camel-Hazelcast Managed Instances में Java Deserialization Filter अनुपस्थित (CVE-2026-43865 के लिए अपूर्ण फ़िक्स)
- प्रकाशित
- 19 अक्टू॰ 2026
- अद्यतन
- 20 अक्टू॰ 2026
- सीएनए असाइन करना
- apache
- साक्ष्य देखे गए
- 17 अक्टू॰ 2026
प्राथमिक सीवीएसएस
cvelist · CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:Hसारांश
Apache Camel में अविश्वसनीय डेटा के डीसेरियलाइज़ेशन का भेद्यता। यह समस्या Apache Camel को प्रभावित करती है: 4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक। camel-hazelcast घटक अपने स्वयं के कॉन्फ़िगरेशन से बनाए गए इंस्टेंस पर एक डिफ़ॉल्ट Hazelcast JavaSerializationFilterConfig लागू करता है, जो CVE-2026-43865 द्वारा पेश की गई एक सुरक्षा है। वह परिवर्तन Camel द्वारा स्वयं निर्मित दो कॉन्फ़िगरेशन पथों तक नहीं पहुँचा, इसलिए वे पथ ऐसे Hazelcast इंस्टेंस बनाते रहे जिनका Java डीसेरियलाइज़ेशन अप्रतिबंधित है। ReplicatedHazelcastAggregationRepository, HazelcastAggregationRepository को विस्तारित करता है लेकिन super.doStart() को कॉल किए बिना doStart() को ओवरराइड करता है, बूटस्ट्रैप ब्लॉक की अपनी प्रति रखता है, और इसलिए कभी भी फ़िल्टर प्राप्त नहीं किया: hazelcastInstance प्रदान किए बिना इसका उपयोग करने वाला एक रूट एक Hazelcast सदस्य शुरू करता है जो बैकिंग ReplicatedMap से पढ़े गए मानों को बिना किसी क्लास प्रतिबंध के डीसेरियलाइज़ करता है। HazelcastDefaultComponent#getOrCreateHzClientInstance() अपना स्वयं का ClientConfig तब बनाता है जब hazelcastMode=client चुना जाता है और न तो कोई संदर्भित ClientConfig और न ही hazelcastConfigUri प्रदान किया जाता है, और इसी तरह कोई फ़िल्टर लागू नहीं किया, इसलिए क्लाइंट-मोड एंडपॉइंट्स अन्यथा समान कॉन्फ़िगरेशन के लिए नोड-मोड एंडपॉइंट्स से भिन्न व्यवहार करते थे। दोनों मामलों में, एक हमलावर जो उस Hazelcast क्लस्टर में प्रकाशित करने में सक्षम है जिससे प्रभावित इंस्टेंस जुड़ा है, अपनी पसंद के एक सीरियलाइज़्ड Java ऑब्जेक्ट को Hazelcast की अपनी सीरियलाइज़ेशन परत के भीतर डीसेरियलाइज़ करवा सकता है, इससे पहले कि Camel एक्सचेंज को प्रोसेस करे, जिसके परिणामस्वरूप रिमोट कोड एक्ज़ीक्यूशन होता है। Hazelcast क्लस्टर में डिफ़ॉल्ट रूप से न तो प्रमाणीकरण और न ही TLS सक्षम होता है। क्लाइंट मोड चुनना एक टोपोलॉजी विकल्प है न कि सुरक्षा विकल्प, इसलिए किसी भी पथ के लिए डिप्लॉयमेंट को असुरक्षित व्यवहार में ऑप्ट इन करने की आवश्यकता नहीं थी। उपयोगकर्ताओं को संस्करण 4.23.0 में अपग्रेड करने की सिफारिश की जाती है, जो इस समस्या को ठीक करता है। यदि उपयोगकर्ता 4.22.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.22.1 में अपग्रेड करने का सुझाव दिया जाता है। यदि उपयोगकर्ता 4.18.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.18.5 में अपग्रेड करने का सुझाव दिया जाता है। 4.14.x रिलीज़ स्ट्रीम और उससे पहले की स्ट्रीम इस समस्या के समाधान से पहले जीवन-चक्र के अंत तक पहुँच गई थीं और उन्हें कोई फ़िक्स प्राप्त नहीं होगा, इसलिए उन लाइनों पर डिप्लॉयमेंट को किसी समर्थित रिलीज़ पर स्थानांतरित होना चाहिए। उन डिप्लॉयमेंट के लिए जो तुरंत अपग्रेड नहीं कर सकते, JavaSerializationFilterConfig वाला एक स्पष्ट Hazelcast कॉन्फ़िगरेशन प्रदान करें, या एक पूर्व-निर्मित HazelcastInstance इंजेक्ट करें, क्योंकि उपयोगकर्ता-प्रदान किए गए कॉन्फ़िगरेशन को Camel कभी ओवरराइट नहीं करता। वैकल्पिक रूप से JVM-व्यापी फ़िल्टर -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* सेट करें और Hazelcast क्लस्टर प्रमाणीकरण और TLS सक्षम करें ताकि यह प्रतिबंधित किया जा सके कि कौन क्लस्टर तक पहुँच सकता है।
जिम्मेदारीपूर्ण उपयोग
भेद्यता जानकारी का उपयोग केवल उन प्रणालियों पर करें जिनके मालिक आप हैं या परीक्षण के लिए अधिकृत हैं। किटप्लॉइट सार्वजनिक अनुसंधान मेटाडेटा से लिंक करता है और शोषण कोड या दुर्भावनापूर्ण पेलोड को संग्रहीत नहीं करता है।